The document outlines the secure data path (SDP) features of the i.MX8M processor designed for IPTV, emphasizing its abilities to protect video and audio content through hardware-based security measures. It describes the architecture, which isolates processing environments, and includes components such as the cryptographic acceleration and assurance module (CAAM) and resource domain controller (RDC) to manage access to sensitive data. The integration of DRM support within Android without significant modifications to existing applications is also highlighted, ensuring secure video playback and management of encrypted content.

1. MARCH2018
PRODUCTPRODUCTPRODUCTPRODUCT PRESENTATIONPRESENTATIONPRESENTATIONPRESENTATION
MICRMICRMICRMICR ADVANCEDTECHNOLOGIESADVANCEDTECHNOLOGIESADVANCEDTECHNOLOGIESADVANCEDTECHNOLOGIES
CYRILLE FLEURY
SECURE DATA PATH ON I.MX8M

2. SECURE DATA PATH
OVERVIEW

3. 3
What is a Secure Data Path in IPTV* context
IPTV SDP: Protect video and audio content, and prevent unauthorized redistribution
of digital media and restrict the ways consumers can copy content : DRM (Digital
Rights Management)
SDP provides confidence, ensuring attackers can’t intercept data:
• Isolate REE (Rich Execution Environment) Operating System from sensitive data
(video, audio , keys, credentials, provisioning …), and use TEE (Trusted
Execution Environment) Operating System to secure data.
*IPTV: Internet Protocal TeleVision : delivery of multimedia content over internet protocol
I.MX8M is adding an additional security level :
• Isolate the TEE Operating System. So Even if TEE is compromised, CPU in
secure mode can’t access the data.

4. 4
i.MX8M : New voice and video processing applications processor
•Arm based processor
•Dedicated hardware for security
•Video quality with full 4K UltraHD resolution and HDR (Dolby
Vision, HDR10, and HLG)
•Highest levels of pro audio fidelity with more than 20 audio
channels each @384KHz
•DSD512 audio capability
•Optimized for fanless operation, low thermal system cost and
long battery life
•Flexible memory options
•The newest high-speed interfaces for flexible connectivity
•Fully supported on NXP’s 10 and 15-year Longevity Program

5. 5
i.MX8M SDP (Secure Data Path) at a glance
• High Assurance Boot (On Chip ROM with tamper detection). Authenticated and Encrypted boot
• ARM TrustZone and the Central Security Unit (CSU) split the processing between non-secure world
running the rich OS, and the secure world running the trusted stack (ATF/OP-TEE from Linaro)
• Application CPU cores won’t have physical access to decrypted video memory buffers
RDC (Resource Domain Controller) to isolate CPU, VPU, GPU, DCSS(Display Controller Sub System)
and memory buffers, using dedicated hardware
• CAAM (Cryptographic Acceleration and Assurance Module) to accelerate and isolate cryptographic
operations, using dedicated hardware
• SNVS (Secure Non-Volatile Storage) and 32 KB of Secure RAM (tamper detection)
The i.MX8M security subsystem is configured in a way that only hardware components involved in the decoding and
the rendering of the stream have access to the decrypted data:

6. 6
Secure Data Path on i.MX8M
RDC: Resource Domain Controller
• Assignment of cores and bus masters to a resource domain (4 domains, 27 bus masters)
• Peripherals and memory regions assigned right accesses based on domain IDs (118 Peripherals, 52
memory regions)
• Memory read/write access controls for each resource domain and region (up to 8 regions per domains)
RDC the SDP gatekeeper
Use a configuration set at boot (within ATF)
Registers locked till next reset

7. 7
Cryptographic Acceleration and Assurance Module (CAAM):
• The chip's cryptographic acceleration and offloading hardware. It supports AES, 3DES, RSA, Elliptic curve, MD5, SHA-1, SHA-
224, SHA-256, SHA-384, SHA-512, MAC, ARC four, PKHA and more
• Random number generator NIST-Compliant
• CAAM is TrustZone aware
Secure Data Path on i.MX8M
Secure Non-Volatile Storage (SNVS):
• Secure real-time clock (RTC)
• Security sensor detection of physical attacks using temperature/voltage/frequency detection, Immediate erasure of internal memory in
event of tamper detection
• 64-bit Monotonic Counter
• Protect sensitive data, such as private keys, DRM keys, and proprietary software
On chip Secure RAM (32 KB) for CAAM:
• Bus attribute-based access controls for resource domain and TrustZone support
• Auto-Erasure and access restrictions upon tamper
• Secure access partitioning based on R/W
• Private bus with CAAM

8. 8
SECURE VIDEO PATH
OVERVIEW

9. CPU
DCSS **
Encoded and
Encrypted data
Encoded and
Encrypted video
Encoded and
decrypted
video
Decoded and
decrypted
video
RDC Domain 0
CAAM
RDC Domain 1
VPU
RDC Domain 2 RDC Domain 3
GPU *
Bitstream buffer 1 TrustZone
Bitstream buffer 2
TrustZone DPB
Buffer
Secure Video Path on i.MX8M
R/W access to registers only, not DDR memory
* GPU not mandatory, to be used
if video texturing is needed
CPU RW, CAAM R VPU RW, DCSS R, GPU RVPU R, CAAM W
** DCSS: Display Controller Sub System: to source up to three display buffers, on the fly composition (3 scalers, PIP) and drive display using HDMI 2.0a with HDCP 2.2

10. 10
ANDROID SECURE VIDEO
PATH

11. 11
i.MX8M Android – DRM
• The DRM support is integrated in the Android framework in
such a way that should require no modification for the android
application
• The Stagefright media playback application provided by
Android has access to the DRM implementation through the
media Framework as shown on the left schematic
• The i.MX8M implementation limits as much as possible
changes to minimize the API modification between the different
android software block and not break existing application
making use of those services. Only one change in Android
code, and no API change :
ACodecBufferChannel::queueInputBuffer
• Modification consists to add a shared memory to let media
meta data accessible by CPU:
- clear media data from Widevine/PlayReady servers are
managed by shared memory (ex video slice headers)
- encrypted data are managed by ION buffers
https://source.android.com/devices/drm

12. 12
i.MX8M Android - Secure video playback – Buffer allocation
• Stagefright Multimedia framework allocate Secure Video output Memory through a NativeWindow’s API set_usage() with
“GRALLOC_USAGE_PROTECTED” flag
• Gralloc HAL use ION secure Heap to allocate the Secure Video Output Memory
• Stagefright MM framework queues the secure video output memory through a native window’s API queueBuffer(), which is same as non-secure Video
• Hardware composer HAL(HWC) renders the Layer to DCSS secure output, which is with “GRALLOC_USAGE_PROTECTED” usage
https://wiki.linaro.org/BenjaminGaignard/ion
NXP is actively working with Linaro Home Group to implement and promote this strategy for
PlayReady and Widevine DRM

13. 13
i.MX8M Android SVP - OpenMaxIL Impact
• None Secure Video Path
CPU can’t access
CPU R/W
VPU
CPU configure VPU
Encrypted and Clear Video data
Decoded Video data
Decrypted
and clear
Video data
CPU Decrypt
• Secure Video Path (ION/RDC/CAAM)
VPU
CPU configure VPU
Encrypted and Clear Video data
Decoded Video dataCAAM
clear Video
data
Shared Mem
Encoded
Video data
ION
CPU Copy
CPU Copy

14. 14
i.MX8M Android SVP – Crypto PlugIn impact
Shared Memory R&W by CPU
Decrypted data ION buffer heap 4, RDC protected, CPU can’t read
VPU
CPU
Decoded data
ION buffer heap 2.
RDC protected CPU can’t access.
SubSample 1 SubSample n
Decrypted and Clear data, free CPU access
Num of
Bytes
Clear
Num of
Bytes
Crypted
Num of
Bytes
Clear
Num of
Bytes
Crypted
Num of
Bytes
Clear
Num of
Bytes
Crypted
SubSample 1
clear data
SubSample 2 …
SubSample 2
clear data
SubSample n
clear data
SubSample 1
decrypted data
SubSample 2
decrypted data
SubSample n
decrypted data
Configure VPU Driver
ssize_t PlayReadyCryptoPlugin::decrypt(
bool secure, // secure=1 use Secure Data Path
const uint8_t key[16], const uint8_t iv[16],
Mode mode, // kMode_Unencrypted or not
const Pattern &,
const void *srcPtr,
const SubSample * subSamples, size_t numSubSamples,
void *dstPtr,
AString * errorDetailMsg)
Free cpu access
SubSample 1
clear data
Image Boundary/slice header: https://yumichan.net/video-processing/video-compression/introduction-to-h264-nal-unit/
copy
decrypt

15. 15
Q & A