TEE vs Secure Element
Comparing TEE and Secure Element architectures for mobile and IoT security: isolation models, certifiability, and use case fit.
TEE vs Secure Element
Trusted Execution Environment (TEE) and Secure Element (SE) are both hardware-backed security boundaries, but they differ fundamentally in their threat model, certification depth, and application model. Choosing between them — or combining them — is one of the most consequential decisions in mobile and embedded security architecture.
Definitions
Trusted Execution Environment (TEETEESecurityIsolated secure execution environment.Click to view →): An isolated execution environment on the application processor, implemented via ARM TrustZone (or RISC-V equivalent). Code running in the Secure World (TEE) is logically isolated from the Normal World (OS), but shares the same physical silicon as the Rich OS.
Secure ElementSecure ElementSecurityTamper-resistant hardware for secure operations.Click to view → (SE): A separate, dedicated security chip (or die partition in an iSIMiSIMApplicationSIMSIMApplicationSmart card for mobile network authentication.Click to view → integrated into device SoC.Click to view → SoC) with its own CPU, RAM, and non-volatile storage. The SE has its own power rails and communication buses; it cannot be accessed by the application processor except via a controlled API.
Security Property Comparison
| Property | TEE | Secure Element |
|---|---|---|
| Physical isolation | No — shares SoC | Yes — discrete die |
| Side-channel resistance | Limited — shared cache, power | High — dedicated hardware countermeasures |
| Fault injectionFault injectionSecurityPhysical attack inducing errors to bypass security.Click to view → resistance | Low–Medium | High (glitch detectors, shields) |
| Common CriteriaCommon CriteriaSecurityInternational IT security evaluation standard.Click to view → certification | EAL2 typical, EAL4 possible | EAL4+, EAL5+ for high-value SEs |
| Key storage | Secure World RAM / fused key | Dedicated EEPROM / flash |
| Attestation | Device Attestation (Android), Secure Enclave (iOS) | Manufacturer + GlobalPlatformGlobalPlatformSoftwareCard application management standard.Click to view → |
| Replacement / provisioning | OTAOTAPersonalizationRemote card management via mobile network.Click to view → firmware update | OTA profile management |
| Cost | $0 (SoC feature) | $2–$8 (discrete chip) |
Attack Surface Analysis
TEE Attacks: - Cache-timing attacks (Spectre-class) can leak TrustZone state on shared L1/L2 caches - Rowhammer against Secure World memory if DRAM ECCECCCryptographyEfficient public-key cryptography using elliptic curves.Click to view → is absent - Malicious Normal World hypervisor downgrading TrustZone permissions - Bootloader compromise before TEE initialisation
SE Attacks: - Side-channel analysis (SPA/DPASPA/DPASecurityPower analysis side-channel attacks.Click to view →) against power traces — mitigated by dedicated countermeasures; see SPA/DPA guide - Physical probing of bus between host SoC and SE (mitigated by SCP03SCP03SoftwareAESAESCryptographyNIST symmetric block cipher for smart card encryption.Click to view →-based secure channel protocol.Click to view → encryption) - Fault injection (laser, EM, voltage glitch) — countered by mesh shields and glitch detectors in EAL5+ SEs
Use Case Matrix
| Use Case | TEE Sufficient? | SE Required? | Rationale |
|---|---|---|---|
| DRM / media keys | Yes | No | Content protection, not payment |
| Mobile payment (EMVEMVApplicationGlobal chip payment card standard.Click to view →) | No | Yes | PCI-DSS, EMVCoEMVCoStandardBody managing EMV payment standards.Click to view → mandate SE or TEE+SE |
| FIDO2FIDO2StandardPasswordless authentication standard.Click to view → platform authenticator | Yes (Level 1) | For Level 2 | FIDO L2 requires SE or certified TEE |
| ePassportePassportApplicationPassport with embedded contactless chip.Click to view → chip | N/A — standalone card | Yes | ICAO Doc 9303 mandates dedicated chip |
| IoT device identity | TEE on capable SoC | Discrete SE for ultra-constrained | Depends on threat model |
| SIM / eSIMeSIMApplicationProgrammable embedded SIM chip.Click to view → | N/A | Yes — eUICCeUICCProvisioningReprogrammable SIM chip supporting remote profile switching.Click to view → | GSMA SESP, separate die |
| Enterprise PIVPIVIdentityUS federal identity card standard.Click to view → | No | Yes | NIST SP 800-73, FIPS 201FIPS 201ComplianceUS federal standard defining PIV smart card specifications.Click to view → |
GlobalPlatform and TEE API
GlobalPlatform defines APIs for both environments:
- GlobalPlatform TEE Client API: Rich World application calls into Trusted Application (TA) running in TEE Secure World
- GlobalPlatform TEE Internal Core API: APIs available inside a TA (crypto, storage, time)
- GlobalPlatform Card Spec: APIs for applets running on an SE
The GP TEE API uses UUIDs to identify Trusted Applications — analogous to AID on smart cards.
Hybrid Architectures
High-security mobile deployments combine both:
Mobile SoC
├── Normal World (Android / iOS)
│ └── Application (e.g., mobile banking app)
├── Secure World (TEE / TrustZone)
│ └── Trusted App: UI confirmation, secure display path
└── SE (NFC controller + discrete SE)
└── Payment applet (EMV, transit)
— Private keys physically isolated from SoC
The TEE handles UI-layer security (secure keyboard input, trusted display) while the SE holds payment credentials. FIDO2 roaming authenticators use a similar split: TEE for user verification (biometric), SE for credential storage and signing.
For the hardware backing these security boundaries, see Smart Card Lifecycle Security and HSM Integration.
자주 묻는 질문
Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.