Inside console security: How innovations shape future hardware protection

In this Help Net Security interview, security researchers Specter and ChendoChap discuss gaming consoles’ unique security model, highlighting how it differs from other consumer devices. They also share their thoughts on how advancements in console security could shape future consumer and enterprise hardware designs.

Specter is a speaker at the Hardwear.io conference, taking place this week in Amsterdam.

Could you explain what makes the security model of consoles, such as PlayStation, fundamentally different from that of other consumer devices, such as smartphones or PCs?

Consoles have some unique security design because they’re primarily designed to lock down the system from the user rather than from other attackers. The vendor’s concerns are less about attacks against user data than enforcing DRM, and providing assurance that the code running on the system isn’t tampered with. Protection of the PlayStation Network (PSN) is included under that umbrella, and a good chunk of the security co-processors’ responsibility is safeguarding it from hacked consoles.

This is why a lot of the current secure boot technology we see on PCs first landed on consoles about ten years ago, and was refined into what it is today. Smartphones have a reasonably similar security model but aren’t locked down quite as much against customers running their code.

The closed ecosystem of consoles also allows the vendors to take liberties when securing the system. For example, where the PS5 doesn’t have to worry about supporting a bunch of custom devices and hardware like PCs do, they’re able to implement a stricter I/O Memory Management Unit (IOMMU) policy, preventing Direct Memory Access (DMA) attacks in a way that PCs currently can’t.

How do you see security mechanisms prototyped on consoles, like the PlayStation, influencing security designs in future consumer hardware or even enterprise-level security?

Such mechanisms we’ve seen in the past, such as AMD’s Platform Security Processor (PSP) and Trusted Platform Module (TPM) technology, were at least partially born from AMD’s GPU-based Secure Asset Management Unit (SAMU), which was primarily used on the Xbox One and the PlayStation 4.

On the latest console generation, we’ve seen evidence of additional security co-processors such as the ambiguously named “A53”, which seems to act as a gate-keeper to the SSD’s encrypted contents. This is something we could imagine eventually being shipped to consumer PCs and/or enterprise devices, where protecting data at rest is an important goal of the security model.

Another mitigation that could be leveraged in enterprise is eXecute-Only Memory (XOM). Preventing attackers from reading out code would be useful in mitigating the visibility an attacker has into a system, as well as protecting proprietary code and intellectual property. This probably wouldn’t be as useful on desktop devices though where the user has access to the executables that are running on their system.

On the PS4, kernel exploits were relatively simple via browser vulnerabilities. How has introducing the hypervisor on the PS5 changed the difficulty of exploitation, and what technical barriers does it introduce for researchers?

On previous console generations like the PS4, most of the system’s security model was baked into the kernel. Even the security co-processor SAMU wasn’t able to prevent reverse engineering most of the system nor prevent running custom code in the kernel. Since the kernel was responsible for talking to it, that API could simply be patched by an attacker with a kernel exploit. This has all changed in the PS5, where the integrity of the kernel code is protected by a proprietary hypervisor. Any attempts to write to the kernel code or any of the machine registers that can allow major system changes are intercepted and rejected.

What makes this particularly troublesome is the presence of a custom hardware mitigation that AMD developed called XOM. On most other devices, if you can execute code you can also read it. On the PS5 however, trying to read executable code will result in a crash. This protection is enforced at the CPU level, and we can’t simply turn it off with a kernel exploit because the hypervisor intercepts the relevant registers and prevents disabling it. No ability to dump the kernel code is a big barrier to reverse engineering the PS5’s OS.

Given the legal and ethical complexities of researching console security, particularly with respect to DRM and intellectual property, how do you balance advancing knowledge and respecting the vendor’s rights?

This is always a tricky problem when doing console research. To run custom code, we work within the existing systems to add our own keys for decrypting our own content, without breaking the licensing for pre-existing content. We keep research to what’s necessary to reverse the system and avoid licensing-related code.

Looking ahead, how do you see the security models of gaming consoles evolving? Are there specific threats or emerging technologies that will shape the future of hardware security in the console space?

I think what’s been demonstrated over the last decade is you need multiple security layers and can’t just bank your security on the kernel anymore. In the future, I imagine the security model will evolve to include more security co-processors and layers of hardware-backed mitigation.

One product that’s a great inspiration for this is the iPhone. It may be the most difficult target to exploit on the planet at this point. Their success in this regard is largely from deploying multiple security layers and co-processors that protect system integrity, even in the presence of a compromised application and kernel.