Other articles in this series:

Embedded security built into hardware was first applied to video content protection in the set top box around 2014. Security cores in set top chipsets started to replace separate smart cards because they offered additional features such as secure storage of cryptographic keys, as well as ability to be updated in the field in response to emerging security threats.

Such hardware security did not replace CAS (Conditional Access Systems) or DRM, but added an extra layer of security, immune not just to existing threats like card cloning, but also more exotic ones, including side channel attacks through differential power analysis (DPA). The latter attempts to read keys or other critical information by analyzing patterns of power consumption associated with operations on the associated data.

As always there were caveats, one being that not all embedded security products worked equally well, adding another level of complexity to the procurement process.

More recently, another embedded front has opened for broadcasters and content distributors with mobile viewing devices. The Trusted Execution Environment (TEE) has emerged as a critical foundational pillar of security for protecting content, software and encryption keys through hardware isolation in the device SoC (System on Chip). The TEE will increasingly underpin the content rights enforcement provided by DRMs.

The term hardware isolation is a slight misnomer because it occurs within a chip and does not necessarily ring fence a particular physical region. It is enforced by logic and memory management to ensure that data such as encryption keys cannot leak out and even be protected against attacks such as DPA through sophisticated obfuscation techniques that scramble the power consumed. It also prevents privileged secure code being corrupted by other applications running in the same chip that may themselves have been compromised.

There also needs to be a separate layer of isolation within the secure kernel itself, to protect the various secure processes running there from each other. This layer does not have to be as impregnable as the TEE as a whole, indeed cannot be because it operates only from within, but can still ensure that cryptographic processes do not interfere with each other or leak information. This second layer can at least build on the hardware isolation at the TEE level.

The idea then is that only secure processes executed from within the TEE, like a chip within a chip, have access to all the SoC’s resources such as storage. In essence it is governed by a separate secure operating system, partitioned from the standard OS, such as Apple’s iOS, underpinning other processes, including user applications.

An obvious question is how decisions are made over which processes are allowed to penetrate this security cordon and enjoy all the facilities of the TEE. The answer is trust. A TEE requires a Chain of Trust, or CoT, built on an underlying Root of Trust (RoT) that may be embedded in a device SoC at manufacture. If the RoT can be trusted, and each link of the CoT is secure, then the TEE can be trusted. The security of each link, or software layer, is guaranteed by its predecessor along the chain.

TEEs are now supported by leading chip makers or semiconductor design platforms. Intel has implemented the concept in its Software Guard Extensions (SGX), which incorporates hardware-based memory encryption that isolates specific application code and data.

Then ARM laid the ground for widespread commercial deployment of TEE implementations in mobile devices such as smartphones, with its TrustZone technology. This was significant because mobile SoCs from chip makers such as Qualcomm and MediaTek are based on ARM’s architectural design.

The TEE concept will eventually form the bedrock of mobile device security with continuing evolution of the SIM that is the basis of authentication, over cellular networks. SIMs enable consumer smartphones to provide a second security factor on top of credentials such as PINs and passwords, for making payments and other transactions.

This usually works by sending one-time passkeys as SMS texts which users then have to enter, relying on possession of the smartphone as a secure token, something the user has, in addition to something known. Biometrics such as facial or fingerprint recognition can then add a third factor, again via the smartphone, something the user has.

The SIM card is now in its fifth iteration, the first being the original full size macro SIM adopted at the dawn of the mobile era almost four decades ago. As handsets came down in size pressure to cut down the SIM followed, leading to the micro-SIM and then the nano SIM as the smallest of the removable SIM cards.

Even the nano SIM occupied too much space on the board for smaller IoT devices, and even became a constraint in smartphone design. It also still required allocation and management of physical SIM cads, and did not enable remote provisioning over the internet.

This led to the development of SIMs incorporated into devices at manufacture rather than being slotted in afterwards. First came the embedded SIM (eSIM) as a dedicated component on the board, separate from the SoC. This retained the SIM as a discrete device while enabling remote provisioning and is now an option with some high-end smartphones. Apple introduced eSIM support in September 2017 on the Apple Watch Series 3 and followed with the iPhone XS, iPhone XS Max and iPhone XR, in September 2018. But these were still dual-SIM devices retaining a physical SIM slot, and so did not benefit from the footprint reduction. Apple finally announced its first eSIM-only phone in September 2022, dispensing altogether with physical SIMs for the first time in a consumer handset.

Even the eSIM occupies too much space for some smaller IoT (Internet of Things) devices such as wearables, and this helped motivate development of the integrated SIM (iSIM). This is a special case of the eSIM, supporting the same functions such as remote provisioning, but now incorporated in a secure zone of the SoC instead of being a separate component. The iSIM then comes to resemble a TEE, even though at this stage it retains its distinct identity as a SIM, confined just to those authentication tasks.

The iSIM does though raise the issue of trust during device manufacture. With all SIM versions, security begins at the point of manufacture, so that factories must protect against breaches and have the SIMs certified. This was more straightforward for physical SIMs and eSIM, because these were manufactured in one factory and then shipped straight to device makers for incorporation in their circuit boards.

But with iSIM, there is a division between the SoC that also houses other functions with no hardware separation between them. Even though it now runs on the same chip, the iSIM logic, or operating system, will typically be developed as a separate package by a specialist vendor. This makes it more difficult to install credentials into the chip in a tamper-resistant way, given that this would be part of a larger design and fabrication process.

Concern over this process has slowed down the iSIM advance, but the issue has now been resolved through a two-step personalization process based on standards approved by the GSMA, the body promoting standards on behalf of mobile operators.

Under this protocol, the SoC maker and iSIM unit provider establish a trusted relationship through which they prepare the SoC and internal iSIM in separate steps. The ultimate device maker then incorporates the SoC knowing that the iSIM inside will be activated with the required credentials at the point the SoC firmware is loaded. The iSIM provider then activates the iSIM securely to make it a fully functional SIM, from then on operating exactly like an eSIM, even though it is inside the SoC.

Over time even iSIM might evolve further into a stage where SIM converges completely with other aspects of device and service security under the TEE banner. In that case the SoC would still incorporate a protected secure core, but no longer one dedicated to SIM authentication.

Meanwhile, from the video perspective, the TEE is becoming entwined with DRM, whose role is to enforce individual rights within services through encryption. DRM relies for its protection on security of encryption keys on the device, and under streaming has often been implemented only at the software level. This involves various techniques to counter tampering. Inevitably though it has to rely on frequent updates to compensate for the inherent insecurity and vulnerability to various attacks.

The advantage of soft DRM lies in ease of implementation and updating, but lacks control over the hardware, exposing it to direct recording off screen for example.

The TEE potentially offers the best of both worlds, retaining flexibility and ease of upgrade, while introducing a secure path to a hardware-protected core for key storage. Now decryption is performed only in the secure kernel, avoiding exposure of clear content in the so-called rich execution environment (REE) open to all processes.

This still leaves some vulnerabilities, including the potential to attack the TEE itself via the secure path leading to it. The TEE and REE still share some hardware, which is therefore a potential point of attack.

While the TEE can never be a black box entirely closed to the computing world outside, it is possible to insulate the path to it through the device from the REE. Then that path can indeed be called secure, more immune to attacks on it mounted outside the TEE but inside the device.

The point here is that since the TEE must sit in the real world it cannot protect against content theft on its own but must have the cooperation of elements outside. It is possible to prevent any code entering the TEE, which therefore must rely entirely on pre-installed software. It can also be protected against either reads or writes from external software outside the chain of trust.

Such developments are not only desirable but will become mandatory. Rights holders or bodies representing them already insist on stringent protection of DRMs against attack. Movie Labs for example requires protection against various side channel attacks, and also support for a secure chain of trust for code that executes in some form of TEE under its Enhanced Content Protection specification, in addition to forensic watermarking to combat illicit stream redistribution.