Recently we launched a newly designed product security web page for anyone to report security vulnerabilities in Qualcomm® products. The new page includes a Hall of Fame to express our gratitude to the researchers who have helped us improve the security of our products.
We are also launching this blog series to share some of the work we’ve been doing to make our products secure.
The web content may be new, but our security work stretches back decades. I’ve personally been working on product security at Qualcomm since 2001. Back then product security was mostly advanced by a handful of dedicated champions working without structured organizational support. In 2006, with the support of Qualcomm’s executive team, we formally launched the Qualcomm Product Security Initiative (QPSI). Today, QPSI is deeply integrated into the product development machinery at Qualcomm and accountability for product security is enforced at the very top.
Product security vs. security product
Security means different things in different contexts. To set the stage for further discussions of our work, I would like to make a distinction between security product and product security.
Qualcomm® Snapdragon™ processors provide a broad range of security features, including the Qualcomm® Secure Execution Environment, cryptographic accelerators, and Qualcomm® Snapdragon StudioAccess™ technology protection for premium content. These features all enable different types of security functionality, and we refer to them as security products. But the focus of this blog series is not on these features.
QPSI has a different role. Our focus is making the product as a whole robust and resilient to malicious attacks that may exploit latent vulnerabilities. Of course, that includes making the security features secure. But it also means securing access control on the SoC bus, hardening over-the-air (OTA) message parsing, adding architectural countermeasures to make reliable exploitation harder, and much more.
The Mobile Pwn2Own competition, to be held November 12-13 in Tokyo, is a good demonstration of attack surfaces we have to consider.
This distinction between product security and security product may sound pedantic, but is really fundamental. It is crucial to understand that security product does not imply product security, or vice versa. Both are important and need to be addressed in their own ways.
Pulling back the curtain
While we have been investing heavily in product security for many years now, we have not been very vocal about our work. The most common reaction I get when I talk about our work is surprise and amazement at the level of investment and commitment to security that we have made behind the scenes.
With security of mobile devices and wireless communications becoming a more regular conversation topic in the mainstream, we think it’s time to pull back the curtain.
We look forward to sharing more about our work. Stay tuned for future posts.