Set-Top Boxes are a growing Cybersecurity Threat
The Set-top box (STB) market is, in many ways, the perfect case study of the challenges facing IoT security today. It is a mature market valued globally at $22.6B in 2020 (by Grand View Research) and appears unlikely to see significant upheaval over the coming years. Take a step back, however, and the picture becomes less predictable, as Hybrid cable boxes now support a much broader suite of functions. And with that, a new set of security challenges.
Today, the design complexity of STBs is growing far beyond cable TV, supporting everything from video conferencing to online shopping. As set-top boxes become more affordable due to the drop in manufacturing and internet costs, this direct link to consumers in their homes continues to be essential, particularly in developing markets, such as Latin America. However, as STBs evolve from simple television decoders into miniature computers, they become vulnerable to the same attacks that other computers face. Therefore, manufacturers now need to secure their customer’s data and ensure the product doesn’t gain a reputation as an exploitable weak point on a home network.
Teaching an old product new hacks
Set-top box content providers already have an array of security concerns: authorized users stealing content, unauthorized users stealing subscriptions, not to mention hackers stealing their embedded firmware and producing counterfeit STBs. However, as STBs increase their computing capacity and can execute more complex programs, bad agents have taken notice. Hackers have begun installing malware on STBs, such as Mirai. Then once assimilated into a botnet, the STBs can do the hacker’s bidding, carrying out DDoS attacks, bitcoin mining, or other nefarious deeds. On a smaller scale, a compromised STB could gain a toehold on a home network from which to carry out attacks on the other connected nodes. While “zero-trust” networks may be more widespread on government and enterprise installations, only the most dedicated computer hobbyists would likely have such a setup at home.
With the rising complexity of set-top box systems, open-source platforms, such as Android TV, are becoming increasingly popular. This change is a mixed blessing. Traditionally, STBs used a closed, proprietary platform, making it easier for developers to handle security as they had total control. However, due to developers taking advantage of the large base of open-source and free software tools to accelerate product development, the likelihood of attack has grown. Open-source software also means open access to software tools for reverse engineering and debugging, leaving portions of the manufacturer’s design exposed (at best) to curious eyes and inquiring minds.
Where did I leave my keys?
To protect the hardware, firmware, and consumable media of STBs, manufacturers and content providers must rely on secure protocols such as digital rights management (DRM), high-bandwidth digital content protection (HDCP), secure data (firmware) encryption, and user authentication. These protocols depend on standard cryptographic algorithms for encryption/decryption, authentication, and key exchange. These algorithms are well documented and standardized by public organizations, such as the National Institute of Standards and Technology (NIST), so their strength depends on their keys. For example, a data encryption key (DEK) that is stolen or is easily guessable can lead to a breakdown in the confidentiality of an entire system. Therefore, like any other system that relies on the AES cipher to keep its secrets private, the secure foundation for STBs lies in keeping the “keys to the kingdom” safe from exfiltration, leakage, and guessing tampering.
Like any other form of confidential data, keys need to be protected at rest and during transit. While there are common techniques for keeping data safe at rest and in transit, the remainder of this article will focus on secure key (data) storage. Starting with the basic assumption that the most critical keys need to be immutable, it makes sense to use a non-volatile memory (NVM) that won’t lose data when the power is turned off. In addition, selecting a one-time programmable (OTP) type of NVM would further guarantee the permanence of the stored keys.
The Secure OTP Solution
This leads to the question of discrete versus embedded memories. While discrete memories have their place, using an embedded NVM offers the benefits of lower power, lower area, and more minor signal delays. In addition, it can take advantage of the larger SoC’s existing anti-tampering measures.
Our SecureOTP IP incorporates a physically unclonable function (PUF) and common bus interface controllers such as AHB or APB. In addition, SecureOTP stores sensitive keys as ciphertext (versus plaintext for a standard OTP) and supports memory-mapped register accesses to the OTP for easier system integration.
The built-in PUF is a source of static entropy that uses the physical variations between individual chips on the same wafer/lot/process node/fab. PUFs that can utilize more stable and completely random variations on a chip will more closely approach the “ideal” vision of a PUF, which is immune to aging effects (stable physical variations) and has a high degree of entropy (completely random variations). Using such a high-quality source of entropy, Secure OTP will completely randomize its stored values by data/address/IO so that no one key (after being written to Secure OTP) looks the same as another for the exact same source key.
For system integrators who have had to work with a traditional memory specialist’s proprietary (and often asynchronous) interface, offering a standard system bus interface such as AHB/APB is a welcome alternative. And using a familiar interface protocol becomes especially attractive when reading and writing to Secure OTP is the same as accessing any other system register (using Secure OTP’s register memory map).
...More
