MYC-LR3576: The Security Stack You Get in the SDK
2026-08-13
47
OP-TEE, FIT secure boot, dm-verity, dm-crypt, CMS-signed OTA -- all in the MYC-LR3576 SDK. Here's what each one does, and which CRA/IEC 62443 clauses they check off.
1. If You Ship to the EU, Security Just Became Mandatory
December 2027. That's when the EU Cyber Resilience Act (CRA) hits full enforcement. Every product with a digital element sold in Europe needs documented cybersecurity. Not "nice to have" -- hard requirement. Fines cap at 2.5% of global turnover or EUR 15 million. Products can get pulled from the market.
Industrial controllers, edge gateways, IoT devices -- all covered. CRA's harmonized standard EN 40000 points directly at IEC 62443. If you're already working toward IEC 62443-4-2, you've covered most of what CRA asks for at the product level.
So what do you actually need on the board? Secure boot. A crypto engine. A place to put keys that Linux can't reach. Signed firmware updates. If your SoM doesn't give you these, you're wiring them up yourself -- months of work before you ship a line of application code.
The MYC-LR3576 ships with all of it in the SDK.
2. The Stack, Top to Bottom
Seven layers. Each one makes the layer above it harder to break.
3. OTP: Burn Once, Live With Forever
OTP is exactly what it sounds like -- one-time programmable. Fuse it, and that bit is set permanently. No erase, no overwrite, no JTAG backdoor. Every security feature on this chip traces back to something burned into OTP.
OTP Storage
Your public key hash, secure boot flag, OEM keys -- all burned into fuses. Once written, the silicon enforces them. No software can override.
Crypto Engine
RSA, ECDSA, AES, SM4 -- all in hardware. No CPU cycles burned on software crypto. Latency drops by an order of magnitude vs. OpenSSL.
TRNG
Chip-level entropy source for key generation. Not a PRNG seeded from boot time. Actual physical randomness.
RPMB
eMMC's replay-protected memory block. Write counters prevent an attacker from restoring old data. Bound to the specific eMMC chip.
Two Halves, One Rule
Non-secure OTP: Linux and U-Boot can read it. Secure OTP: only OP-TEE touches it. Public key hashes, boot flags, security level, OEM hardware unique key, TA-only regions, and four write-only cipher key slots -- all in the secure half.
Burn a key in, and the only thing you can do with it afterward is call encrypt/decrypt. No read-back API exists. Linux compromised? Doesn't matter -- the key never left the hardware.
4. Secure Boot: Chain of Trust, Link by Link
FIT (Flattened Image Tree) signatures at every stage. BootROM checks Loader. Loader checks OP-TEE. OP-TEE checks U-Boot. U-Boot checks the kernel. One bad check and you don't get past it.
Boot Chain
BootROM is fused at the factory. Can't update it, can't patch it. It reads the public key hash from OTP, checks the Loader signature, and hands over -- or doesn't. Everything downstream inherits that decision.
5. OP-TEE: Keys Run in Their Own World
Two worlds, one chip. TrustZone splits them at the bus level:
Normal World: Linux, your apps. If it gets owned, it still can't read secure-world memory.
Secure World: OP-TEE OS + TAs. Keys, crypto, secure storage. Linux never sees any of it.
Crossing from Normal to Secure world goes through an SMC instruction. Hardware gate, not a software check. Normal-world code literally cannot address secure-world memory.
KeyBox: Your Keys, OP-TEE's Vault
The SDK ships with a KeyBox TA -- a trusted app inside OP-TEE that stores and manages keys. Your Linux app talks to it through a CA (client application) over the TEE driver. No key material ever appears in Linux memory.
Two storage options:
RPMB: Inside eMMC, hardware anti-replay, ~512 KB
Security partition: eMMC user partition, larger capacity (1 MB+), encrypted by TEE
Set CFG_TA_VERSION in your TA Makefile. System blocks any older binary from loading. Someone finds a vulnerability in an old TA version? Doesn't matter -- it won't boot.
What you can run inside OP-TEE:
SHA Hashing
SHA-1, SHA-256, SHA-512 for data integrity verification
AES Symmetric Encryption
AES-128/256, ECB/CBC/CTR modes, hardware-accelerated
RSA Asymmetric Encryption
RSA-2048/4096, encryption/decryption, signing/verification
TRNG Random Numbers
Hardware entropy source for key derivation
6. dm-verity + dm-crypt
Secure boot covers startup. Once the kernel is running, you need something that catches tampering at runtime.
dm-verity
Read-only system partition, block-level integrity. Slice the partition into 4 KB chunks, hash each one, build a Merkle tree, embed the root hash in boot.img. Kernel checks every read against the tree. One byte mismatch anywhere and that block never reaches userspace.
dm-crypt
Encrypts writes, decrypts reads. Your app never knows it's happening. Key lives in RPMB or Security partition, wrapped by KeyBox. Plaintext key never hits normal-world DRAM.
7. Signed OTA: Your Update Server Gets Spoofed, Nothing Happens
Without signed updates, anyone who can point your device at a malicious server owns your firmware. CRA requires a secure update path. We use CMS (RFC 5652).
How the Signature Check Works
CMS (RFC 5652) gives you three guarantees per update package:
Integrity: Data has not been tampered with
Authenticity: Data originates from the key holder
Non-repudiation: The signature cannot later be denied
Signed OTA images share the same key pair as secure boot -- one PKI to manage. The build system generates signed images with a single command.
8. Pick Your Security Level (You Only Get One Shot)
Three levels, burned into OTP. Choose carefully -- you can't change it later.
Burned into OTP. No undo. Get it right during design -- we can help with that.
9. Feature -> Standard Mapping
| Compliance Requirement | MYC-LR3576 Capability | Standards Reference |
|---|---|---|
| Secure by Design | OTP root of trust + hardware crypto engine | CRA Annex I Part A; IEC 62443-4-2 FR1 |
| Software Integrity | FIT secure boot + dm-verity verification | CRA Annex I 1.1; IEC 62443-4-2 FR3 |
| Access Control & Authentication | TrustZone / OP-TEE hardware isolation | CRA Annex I 1.2; IEC 62443-4-2 FR1/FR5 |
| Data Encryption & Confidentiality | dm-crypt partition encryption + HW AES engine | CRA Annex I 1.3; IEC 62443-4-2 FR6 |
| Secure Updates | CMS-signed OTA + TA anti-rollback | CRA Annex I Part B; IEC 62443-4-2 FR7 |
| Key Security Management | KeyBox + RPMB + write-only key storage | CRA Annex I 1.3; IEC 62443-4-2 FR6 |
| Vulnerability Management | MYIR long-term SDK maintenance + security patches | CRA Annex I Part B; IEC 62443-4-1 |
10. What Ships
What's in the SDK
| Category | Contents |
|---|---|
| Hardware | MYC-LR3576 SOM, RK3576, onboard eMMC, full HW security engine support |
| SDK | Linux SDK (Buildroot/Yocto), security features as patches, verified and functional |
| Secure Boot | FIT signing toolchain + configuration scripts, one-command signed firmware generation |
| OP-TEE | OP-TEE OS + KeyBox TA + test tools, complete CA/TA examples |
| System Security | dm-verity / dm-crypt configurations, ready to enable per requirement |
| Secure OTA | CMS signing tool + updateEngine, supporting network and local upgrade paths |
| Documentation | Security Application Notes -- from principles to hands-on implementation |
| Support | Direct engineering support for security feature integration |
Where This Gets Used
Industrial PLCs & Gateways
IEC 62443-4-2 is the procurement checkbox here. OTP + secure boot + signed OTA covers FR1 through FR7.
EV Charging Stations
OCPP + ISO 15118 need TLS keys that survive physical access. KeyBox + write-only cipher slots solve this.
Automotive T-Box / V2X
Anti-rollback matters. TA versioning + RPMB counters keep downgraded firmware from ever booting.
Medical Gateways
Patient data at rest needs encryption that survives eMMC removal. dm-crypt + OP-TEE derived keys handle this.
Payment Terminals
PCI PTS asks for tamper-resistant key storage. Write-only OTP cipher slots + RPMB are the hardware answer.
Smart Meters / DTUs
Field-deployed for 10 years. CMS-signed OTA means you can patch vulnerabilities without dispatching a technician.
MYC-LR3576
OTP | Secure Boot | OP-TEE | dm-verity | CMS OTA -- all in the SDK
Sales: sales@myir.cn | Support: support@myir.cn
2026-07-29
A Complete Secure Boot, Storage, and OTA Pipeline on MYIR's i.MX93 Platform
MYIR has released the V2.0.0 software version for its NXP i.MX93 based MYD-LMX9X Development Board.
2026-07-14
Building a Zero-Copy Dual-Vision System on RK3576 with DMA-BUF
Walk through the engineering path from working prototype to automotive-grade, production-ready latency using MYIR's RK3576 solution.
2026-05-19
When 6 TOPS Is No Longer the Limit: RK3576 + Hailo-8 Achieves True Real-Time Processing for High-Frame-Rate Cameras
Beyond 6 TOPS: RK3576 + Hailo-8 Delivers True Real-Time for High-FPS Cameras
2025-11-27
SECC GreenPHY Solution: Bridging STM32MP135 SOM to V2G Industry Advancement
Debug MSE102x G on MYC-YF13X, providing reference for V2G communication development.
2025-11-20
SECC Solution for Charging Pile Applications
MYIR's SECC solution delivers a high-standard, low-risk rapid development platform for clients, with core strengths in protocol compatibility, operational security, and a comprehensive reference design.
2025-11-02
Simultaneous Control of 4 YOLOv8 Video Streams via MYIR's RK3576 Board
In the era of rapid technological advancement, the integration of artificial intelligence and edge computing is transforming our lives at an unprecedented pace. The RK3576 processor features a quad-co
2025-09-20
Compiling OpenCV and Developing Applications on the RK3576 Board
This article introduces how to compile OpenCV on the RK3576 development board and build an application.
2025-08-30
MYIR T536 Development Board: Multi-protocol IoT Gateway Solution Test
The article details the development and testing of a multi-protocol IoT gateway solution that utilizes MYIR's MYD-LT536 development board, which is based on the Allwinner T536 SoC.
2025-08-29
MYIR RK3576 Development Board: 12-Channel 1080p HD Video Streaming
MYIR has successfully achieved efficient H.264 encoding and low-latency RTSP streaming for 12-channel HD video streams on the Rockchip RK3576 SOM.