It’s clear in Windows Phone 8 that Microsoft is going after the security minded/corporate customer big time. That’s not to say it’s the only market they are targeting, but they have made a number of significant changes under the hood to improve the overall security of the platform. During the developer preview event, Microsoft talked about Windows Phone 8 being “Enterprise Ready” with device encryption, and SafeBoot as key elements of this.
So what exactly has Microsoft done in terms device encryption? To start with, they baked it in for the entire device including the operating system and applications. Encryption is turned on from the very first moment that you power on the device. It was designed along the same lines as Microsoft’s BitLocker technology that can be found in Windows 7 desktops and laptops, with the main difference being that keys are not manageable on Windows Phone, like they are on the desktop. At this point, the on device encryption is not certified, but that is coming – Microsoft has stated that they are looking to get the encryption FIPS certified. The encryption is backed by the TPM 2.0 standard, which requires unique keys to be burned into the chip during production.
There are two exceptions to device encryption on Windows Phone 8. The first is geographic region – if you live in a location that do not allow the import of encryption technology (basically, if you’re version of Windows doesn’t support BitLocker), then device encryption will be disabled on devices sold in that region. The second exception is the SD card – due to the unknown performance of externally swappable SD cards, Microsoft will not be encrypting the removable media on the device. At first that may sound like a big security hole, but the reality is that the SD card can only be used to store pictures, music, and videos. You can’t save documents to the SD card. The end result is that your data is encrypted and safe while on the phone.
Now let’s take a look at the SafeBoot feature of Windows Phone 8. The objective here is to design a safe way to launch the OS and ensure that only trusted components get loaded. First some background; each device gets a unique key burned into a chip, along with a number of common keys from Microsoft and the OEM and then the fuse is blown on the chip, effectively making this information read-only. Now, when you press the power button the firmware will kick off a secure UEFI (Unified Extensible Firmware Interface) environment. Some functions run within the secure UEFI to validate the hash of these keys against the signatures on the initial boot loaders to ensure that it is a verified operating environment. At that point, it will compare the signatures on the Windows Phone boot manager to make sure that those are valid, if everything is good it will be allowed to start. The Windows Phone boot manager knows the order of applications to be started, and it will only start signed and trusted applications. Microsoft has required that all of their own binaries, along with any OEM binaries must have a digital signature signed by Microsoft. Because of this, it becomes very difficult to introduce a new component – like malware – to the boot process. Nobody has access to all the keys required to make the system run. As a result, it will not be possible to build custom ROMs because it won’t have the correct digital signature, and therefore the Windows Phone boot manager will not start it.
Further to this, Microsoft has reduced the base footprint of the OS, and they now require all applications, including their own applications, to run in the same sandbox as third party marketplace apps. This even extends to OEMs drivers and customizations. If any application is compromised, the malware will only have access to the contents inside that sandbox, preventing malware from gaining access to the lower system level of the device.
When you look at all the changes that Microsoft has made around device encryption and SafeBoot to improve the overall security of the platform, it becomes clear why they are not willing to update older devices to Windows Phone 8. The biggest reason would be the lack of a chip with burned in platform, OEM, and device keys. As much as I would like to see older hardware get the latest and greatest, it’s pretty hard to push a software update to devices that relies on hardware that just isn’t there. Windows Phone 8 offers a much improved security model for developers looking to monetize their applications, for OEMs looking to offer key value adds for people who have purchased their devices, and for consumers and the enterprise that want to know their data is safe from malicious applications.