The enormous success of the mobile phone as a "must have" consumer item has brought in its train a number of security issues, and notably the unlocking of the SIM Lock/IMEI. There's a lot of pressure on designers to devise security solutions, and that pressure is only compounded by the ability to download content, including music and video. Vendors now face the prospect of having to implement multiple DRM schemes for mobile phones and other mobile devices, with industry analysts predicting a boom market for mobile digital TV (MDTV).
ARM, of embedded RISC processor fame, is offering its TrustZone technology as one approach to the problem of security on mobile devices. DigiTimes.com recently had an opportunity to speak with Tiago Alves, product manager at ARM for TrustZone. Alves argues that TrustZone is unique in the industry, even though the aim was always "to keep it simple." Complexity is itself a security risk, argues Alves.
This is Part III of a three-part interview. Part I appeared on 13 October and Part II on 16 October.
Q: Are these mobile device attacks usually conducted by isolated individuals, or is there a more serious side to it, such as organized crime?
A: In practice, I think that there have tended to be restrictions on the type of transactions that can be made over mobile devices. Operators and service providers have tended to devise their own payment solutions, and normally the payments involved are quite small. I think you tend to see organized crime aiming more for larger scale attacks such as the SIM Lock type of attack, or set-top box cloning but also traditional payment fraud. In the credit-card market, there we are talking about the "lab" type of attack, where the attack is against a smartcard level of security. But the credit-card business is alive well, even so. A lot of money has been invested to protect against these types of attacks. While this type of attempted fraud is constantly evolving its methods, it's also constantly being brought under control.
Q: Mobile business transactions can also include downloading music and other content, including video and streamed content, such as mobile digital TV (MDTV). This is where digital rights management (DRM) now threatens to add unexpected levels of complexity. In practice, it looks as though devices such as handsets will have to be compatible with multiple DRM schemes. What are the implications for a company such as ARM?
A: There is a lot of money behind DRM, and everyone wants to implement it. It is a worldwide requirement, originating with the content providers, who are making quite sophisticated proportionate rules with which everyone has to comply. And after all, mobile devices, particularly media players, are an ideal gateway to the user, in terms of delivering these types of content services. There has to be a suitable solution for these types of devices. It's really about perfecting the business model, and we are seeing the model evolve.
ARM was probably one of the first companies in the industry to talk about multiple DRM schemes because some of our work in the personal space was inspired by the requirements of billing and payments technology, and there I'm talking about Point of Sale terminals and so on. There you have companies such as Visa and Mastercard who need to cooperate on the same device. They need to cooperate on security, but they also need to be independently certifiable, and that's very difficult to achieve. If you have one trusted environment, and you want to have multiple security stake holders co-existing in that one environment, and you want to assure them that they don't have to simply trust each other, you are going to have a security challenge. That's because if I am, let's say, a Visa card holder and I make a payment application, and I follow all the correct procedures, I still have the question of the shared platform. For example, what guarantee is there that someone else's badly written software won't cause glitches in the payment platform, and so on?
We've seen that scenario in what you might broadly call the payment industry, and we've seen that with mobile phones in particular. The problem is more prevalent with mobile phones because there you would typically have multiple payment schemes as well as multiple DRM schemes. For example, there might be multiple digital TV broadcast schemes. In that situation, vendors cannot assume that others will do a good job, when it comes to security. They have to be wary of other implementations; they have to not take other implementations on trust. To do otherwise would not be good practice.
It's for that reason that ARM's TrustZone software has an optional software layer we call the trusted interpreter. The trusted interpreter is based on an industry standard called STIP (small terminal interoperability platform). That standard basically allows multiple DRM schemes to be loaded into the platform, and if one DRM scheme does not function properly, for some reason, we can guarantee that it is not going to break the rest of the platform. We devised the trusted interpreter because, early on, we recognized the need for multiple DRM schemes, and we saw the need to isolate the internal security of the platform using something that can somehow expose APIs to the external world, and load services into the secure environment, without breaking anything. There are other ways of achieving similar results at a native level, and here the design decisions and trade-offs become quite technical.
I'll give you a better example. Let's say you are a large OEM and you have your own development team, but in addition you also have your third-party eco-system developers, and you also have a very-high-security group developing your SIM Lock solution. So you have your internal hardware environment, and you also have your own internal security software, which provides a native C-code environment, let's say. You can do whatever you want in that native C-code environment, so as an OEM you might say, "OK, this is a super-powerful environment, I'm only going to give it to special security developers. We will write SIM Lock, and after that we will lock that environment, and no one else will be able to write code to that environment and attempt to subvert the environment." But then you decide you also want to expose that security environment to others in the company, perhaps the team developing a DRM scheme, or even a partner company. To do that, the trusted interpreter allows you to create an interpreter layer where you restrict what can be done. That creates an environment that can be extended, offering a trusted execution environment to services without having to necessarily trust the services themselves
Q: Do you think it's inevitable that DRM schemes will be hacked at some point?
A: Well, from the point of view of the industry, I think the aim is not to have an unhackable DRM scheme but a profitable DRM scheme, and I think that will be achieved. This is to accept there is a probability the scheme will be hacked, at some point, but that nevertheless, the scheme is designed in such a way that at some point it can be revoked and renewed, and therefore the underlying business model can be maintained. That is also related to the idea of allowing additional production releases, so if you discover a bug in your DRM scheme, or there is a new standard you want to support, you can download a security agent and fix the bug or install support for a new standard on the platform. And that question leads nicely to the STIP concept I mentioned before, which allows multiple DRM schemes on the same platform. You want that, and you also want to have the ability to revoke things or renew things following production. Again, our framework does not rely on STIP as the only way to achieve this, but it is certainly an option we are able to offer to partners.
Q: How does ARM's security technology compare with solutions available from other companies in the embedded and mobile segments? For example, MIPS has a technique for the secure virtual partitioning of processors.
A: In the embedded consumer space, there is no other architecture that I am aware of using the virtualization-like approach we have adopted with TrustZone. There is nothing equivalent to that. There are things that could be seen as similar, but they are not really equivalent. There are other architectures, but with the ARM architecture we have two main privilege levels. With TrustZone, we don't simply add a third level of privilege and expect the software to do the rest. We add a secondary virtual processor with two additional levels. It also includes a whole new level of memory, peripheral and system level awareness of the security state, and with the TrustZone architecture, that can be exported externally to the CPU core to achieve what is necessary for a security system: system level awareness, isolation and coherency internal and external to the CPU.
Debug is a serious problem and usually a threat as well. Our architecture also addresses this issue, so you can see this not only as a CPU problem but also a system level problem, one that, yes, needs to be rooted in the CPU architecture. That proposes that we leave the mobile environment as it is, at those two levels, and create something completely isolated from that, but at the same time very closely coupled, to help communication and management of system resources.
As I mentioned other approaches might include adding a third level of privilege, but that's not the same thing as adding another virtualized CPU. The main reason is because when we do create the virtualized CPU, we don't simply achieve a CPU in hardware. The new CPU spreads its awareness across the system.
Let me explain what I mean by that statement. When we have these two worlds, these two virtual CPUs, we also add an additional bit to the accesses. All the memory addresses and so on were originally set up for 32-bit addressing, but now they effectively become a form of 33-bit addressing. That allows us to propagate an awareness of the secure world outside the CPU, and we can have peripherals that are actually aware of the situation of the platform. We can have memory areas that are aware, and we can then propagate that awareness to other masters, other slaves, other peripherals and even outside the platform itself.
It's not about trying to have a more secure operating system and promoting major time-consuming OS re-writes by adding extra levels of privilege, or adding some sort of hypervisor layers in order to manipulate the different levels and multiple OSs. Although this can be achieved with the architecture, TrustZone enables more than that, as already discussed. The differences between our approach and those of our competitors boil down to very technical arguments as well as to our own innovation potential in developing appropriate, industry-friendly and efficient solutions. But some differences can be quite superficial, and you notice them in the x86 architecture, for example, and even in mainframe architecture, where hardware enforced virtualization represented a completely new direction for the architecture, with very justifiable market needs.
This is Part III of a three-part interview. Part I appeared on 13 October and Part II on 16 October.
Tiago Alves, product manager at ARM for TrustZone. “All future application processors from ARM will incorporate TrustZone.”
Photo: Company
Article edited by Chris Hall
