Windows Phone Highlights

Table of Contents

Microsoft Windows Phone Update ...... 2

Windows Phone – Enterprise -1 ...... 3

Windows Phone – Enterprise -2 ...... 4

Windows Phone – Trusted Hardware ...... 6

Windows Phone – App Security ...... 8

Windows Phone – AppContainer ...... 10

Windows Phone – ASLR & DEP ...... 11

Windows Phone – Storage ...... 14

Windows Phone – Assigned Access ...... 16

Windows Phone – Authentication ...... 18

Windows Phone – VPN ...... 19

Windows Phone – Remote Assistant ...... 20

Notices ...... 21

Page 1 of 21 Microsoft Windows Phone Update

Microsoft Windows Phone Update

110

**110 Mark Williams: Some of the security features in Windows phone that are of note and are interesting.

Page 2 of 21 Windows Phone – Enterprise -1

Windows Phone – Enterprise -1

Ubiquitous OS • Consistent look / feel — Whether using a phone, desktop, tablet, other Common security features • Unified Extensible Firmware Interface (UEFI) • Trusted Platform Module (TPM) • Data Execution Prevention (DEP) • Address Space Layout Randomization (ASLR) • BitLocker Drive Encryption • AppContainer Sandbox • Information Rights Management (IRM)

111

**111 One is the fact that Windows has done a-- Microsoft has gone a long way to try to make a ubiquitous operating system, one that will work on the desktop system, one that will work on the tablet and even on your phone. And so, that operating system is going-- supposed to give us a seamless communication between all the devices and a seamless user interface.

Some of the common security features that we're going to discuss that Windows has-- or Microsoft has provided for us in their Windows phone is that fact that we have this unified, extensible firmware interface.

Page 3 of 21 They incorporate a trusted protection or trusted platform module into the system. We'll look at the concept of data execution prevention, as well as address space layout randomization, and a couple other neat little feature and functionality that Microsoft has added to provide this seamless enterprise experience for the phone.

Windows Phone – Enterprise -2

Mobile Device Management – Organization can easily enroll WP in MDM system • Manage and push security policies to devices Assigned Access – Organizations can create a “white list” of authorized apps Enterprise Wi-Fi – Support for enterprise level wireless access • Extensible Authentication Protocol – Transport Layer Security (EAP- TLS) • EAP-Tunneled Transport Layer Security (EAP-TTLS) • Certificate based authentication

112

**112 Some other things that they have done to make it much more of an enterprise friendly environment is they've given us the ability to tie it in with MDM systems and software, mobile device management, so that

Page 4 of 21 the enterprise can control the policies and security feature and functionality and what programs and applications are able to run on your phone. We'll talk a little bit about this concept of assigned access where we can specifically say via a whitelist of what's going to be allowed on the system. And if it's not on the whitelist, what's going to be prevented.

And also from an enterprise standpoint, it allows us to integrate into the enterprise wireless environment by natively supporting various VPN technologies such as-- and authentication such as TLS and extensible authentication protocol.

Page 5 of 21 Windows Phone – Trusted Hardware

Windows Phone – Trusted Hardware

UEFI = BIOS + Security • Creates a “chain of trust” for the boot process • Firmware digitally signed by device manufacturer • Required for “trusted boot” Trusted Platform Module • Tamper resistant security processor Trusted Boot • Stores cryptographic keys • Stores hashes used to verify firmware and critical files • Stores BitLocker keys Trusted Boot • UEFI & TPM work together to ensure integrity of boot process

113

**113 So, what are some of the more noteworthy security features that we have? One is the unified extensible firmware interface. Basically, this is a secure form of BIOS. The idea here is Microsoft has created this code that has been signed by Microsoft-- signed by the device manufacturer, actually. And when this code boots up, we know it is a trusted code. And that's going to eliminate the ability for malware manufacturers to introduce root kits and other types of malware at the lower levels of the operating system, before the operating system takes place.

Page 6 of 21 And UEFI works with this trusted platform module. And together, they provide what's referred to as trusted boot. And the idea behind trusted boot is if we think about security on any device, much of the security is provided by the operating system. And so, a simple way of bypassing security is to bypass that operating system in its entirety.

So, trusted boot simply says you're not going to be able to do that. You have to be an authorized individual to be able to boot this device, which means that when we first turn it on, we have to provide some sort of credentials to authenticate ourselves. Well, those credentials are not going to be just stored in an insecure location. They are stored in the TPM, the trusted platform module. The TPM is basically a secure chip and a secure set of code for storing all of our authentication credentials and our encryption keys.

Page 7 of 21 Windows Phone – App Security

Windows Phone – App Security

Windows Phone Store security controls combined with applications sandboxing (AppContainer) • Offers limited protection, especially when sideloading • Organizations should review sideloaded apps to ensure they meet policy Manage apps through policy • Disable access to Windows Phone Store • Disable sideloading • Allow / block specific apps

114

**114 Windows phone also has what's referred to as an AppContainer. The AppContainer, we're trying to establish trust in all the apps that we run on our phones, whether they be apps provided to us from Microsoft, or whether they be apps that we get from a third party.

So, the way Windows phone provides security of our apps, it's kind of a twofold system. First, the Windows phone store adds some security measures. So, they will, in the Windows phone store, when apps are supplied there, they will verify that they are free of malware. And then also, on the phone itself, when an

Page 8 of 21 app is ran, it is sandboxed, which is-- to remind you, it is that containment of the app where we see that app cannot have any access to any resources locally on the machine. It can only have access to resources that were downloaded along with the application.

And Microsoft increases the level of application security by allowing us to create various policies. The policies can say here are the apps that we're going to allow access. Here are the apps that we're going to block access to. We can even say you can only get apps from a certain location. So, maybe you have an enterprise app server. And that's the only place we can get apps from. And users will not be allowed to maybe go out to the Windows phone store and download apps directly from that. Or they won't be able to side load. They can only get apps that you have authorized, that you have trusted through your local enterprise environment. So, application security is what we have.

Page 9 of 21 Windows Phone – AppContainer

Windows Phone – AppContainer

Least Privilege AppContainer policy defines specific capabilities to which the app processes have access to • Location • Camera • Microphone • Networking • Sensors

115

**115 That AppContainer that I just mentioned, it's following the concept of least privilege. It basically is allowing us to set specific policies for what the different features and functionality of the phone are going to be allowed to do. So, what apps can utilize the camera? What apps can utilize location-based services? What apps can use the various sensors that are on there? So, an enterprise could set a policy that says this app, because it's a map, it needs to have access to the GPS capabilities. This app over here is a calendar. It doesn't really need access to the GPS, so we're going to limit its abilities in that way. So,

Page 10 of 21 AppContainer allows us to implement that concept of least privilege.

Windows Phone – ASLR & DEP

Apps are written by humans, therefore apps will contain vulnerabilities Windows Phone Store and AppContainer help, but are not enough ASLR – Randomizes where system code runs in memory • Makes it harder to overwrite with malicious code DEP – Blocks of memory are marked as “data only” • eXecute Never (XN) • Malicious code in these locations cannot be executed

116

**116 Some other neat little tricks that we use in Windows to provide a little security is Data Execution Protection and Address Space Layout Randomization. ASLR is the idea of we're not going to store data and resources always in the same location. If you think about this. If I have a Windows operating system on my machine, and you have a Windows operating system on your machine, chances are, by default, we're storing the same system files in the same locations. And we're

Page 11 of 21 accessing the memory in the same ways.

So, if I can learn how my system Operates, then I have insight into how your system operates. And so, if I wanted to create a buffer overflow, for example, if I knew how-- if I could manufacture that buffer overflow to work in my environment, then I'm pretty sure I'm going to be able to get it to work in your environment because they are laid out and organized and arranged in the exact same ways.

So, ASLR says: we're not going to do it that way. ASLR says we're going to store data in different locations on different machines at different time. So, that just makes it much more difficult for the bad actors to craft exploit code that works in one environment that's also going to work in another environment that is similar.

All right, then we also have Data Execution Protection. And Data Execution Protection is this concept of, again, it has to do with buffer overflows. It's the concept of when users input data into the system, that data should be data. It should not be an executable type of file. It should not be active at content. It should not be doing anything.

Unfortunately, traditionally, I could put-- let's say I was filling out a form on your device. And your form asked me for a phone number. I could put instead some assembly code or some

Page 12 of 21 shell code in there. And that's supposed to be a phone number. But the reality is, it's now an executable that you might end up running on your system.

Well, Data Execution Protection says: we have this area of memory over here that is used for executable types of stuff, programs and processes. And that's the only place the execution can happen. Over here, anything stored in this area of memory, it can-- we're not going to execute it. They use this basically a flag that says: execute never. Saying that if it's stored in this area, no execution can happen. Again, we're trying to prevent the negative impacts of a buffer overflow on the system, so Address Space Layout Randomization and Data Execution Protection.

Page 13 of 21 Windows Phone – Storage

Windows Phone – Storage

Internal • BitLocker technology • AES-128 • Keys stored on TPM • “Require Device Encryption” forces encryption External • Install apps on SD card (new with Windows 8.1) — Stored on an encrypted partition by default • Content (photos, music, other) stored in plaintext — Allows sharing • “Disable removable storage card”

117

**117 We also have protection for the storage, two different types of storage that we have on your phones. We have the internal storage. And we have the external storage. Internal storage, we're going to utilize full disk encryption utilizing Microsoft's BitLocker technology. And with BitLocker, we have AES, Advanced Encryption Standard, 128 bit, encryption that's used to protect the data on that internal storage.

The keys that are used to unlock or decrypt that disk, they're not going to be stored on the disk itself. They're going to be stored in the trusted platform module, the TPM. Again, the

Page 14 of 21 TPM is that protected repository that is a higher degree of security than just the average operating system or the average piece of hardware.

What if I was storing something externally? Well, with Windows 8.1, we have the ability to install an SD card and actually have our apps loaded onto that SD card. By default, when we load an app onto the SD card, there is a special area of the partition that is encrypted. That's where those apps are going to go by default.

The content or the data that we load onto that SD card, they go into another partition. And that other partition is unencrypted. And it allows for the data to be shared amongst multiple apps. So, I could have, again, a let's say, an appointment that I could access with my email. And I could also access that appointment with my calendar. And in order for two different apps that might have been manufactured by two different developers, in order for them to access that same content, it cannot be encrypted. So, that's on a separate area of the storage card.

In order for me to utilize the storage card-- or not to utilize it. I can say that I want the card to be disabled from removing. So, if we try to remove the card-- I mean physically, you'll be able to remove it. But by setting disable removal of the storage card, it's going to give us a warning. Our pop up, basically it says that some apps or some feature and

Page 15 of 21 functionality might not work because they are running off that storage card.

Windows Phone – Assigned Access

Enable specific apps and prevent access to other functionality “Kiosk” mode App Allow/Deny policy – configured through MDM system • Use System Center 2012 Configuration Manager or InTune to create XML file.

118

**118 We also have the concept of assigned access. Assigned access basically allows me to create a kiosk for my phone. So, let's say an enterprise is going to give a phone to some of its employees. And they don't want those employees to be playing games on their phone because it's a corporate resource for corporate purposes. We don't want them to be playing games. So, assigned access says no games are going to be allowed to run on this, or

Page 16 of 21 be installed, or even run on this phone. So, I can make basically a kiosk type of environment.

A lot of security companies-- when I say security companies, I'm talking about physical security companies, those people that provide guards. They will often times assign phones to their guards. And you don't want a guard sitting in his guard shack playing a game. So, they will limit; here are the apps that this phone can utilize.

Like everything else, since we're trying to make it much more enterprise friendly and aware, we're integrating the Windows phone with a mobile device management software that's available. And you can see that we mentioned System Center 2012 Configuration Management. It is a common MDM software in the Windows environment that this integrates nicely with. Or another MDM software that is fairly commonly used is InTune. And it uses XML to push out configurations to our Windows mobile devices.

Page 17 of 21 Windows Phone – Authentication

Windows Phone – Authentication

Virtual Smartcard • Emulate traditional smartcard • Uses TPM • Used for two-factor authentication Certificate based authentication • Secure Wi-Fi • Virtual Smartcard • S/MIME signing

119

**119 We can also use our Windows phones for authentication purposes. Now, when I think about for authentication, I think about two things, one, people authenticating to the phone to access the phone, but then also using the phone to access and authenticate into the enterprise. Well, traditionally, the way we have always done authentication is with a password or passphrase. And we know that's a weak form of authentication.

So, with Windows phone, we have the ability to basically use certificates, things that we possess and even use our phone to create a virtual smart

Page 18 of 21 card, if you will, again, something I possess that increases my level of authentication credential. We can use the Windows phone authentication in a two-factor fashion as well. So, we use the phone as a way of doing a smart card and then also requiring somebody to put in a user ID or PIN in order to be able to gain access, so two-factor authentication. All right.

Windows Phone – VPN

Built-In support for VPN providers • Microsoft • Juniper • Check Point • F5 • SonicWall VPN technologies • IKEv2 • IPSec • SSL

120

**120 VPNs, Virtual Private Networks, Microsoft has added a lot of native support for some of the most common VPN technologies that are out there. So, vendors such as Juniper, or F5, and certainly

Page 19 of 21 Microsoft's VPN technologies. They are automatically built in and compatible within the phone. And various protocols such as Internet key exchange and Internet protocol security, they are natively built into the capability of the Windows phone.

Windows Phone – Remote Assistant

Provides remote support to solve problems • Remote Lock — Locks but does not wipe — Useful when phone was misplaced or left at an unsecure location (forgot it at a restaurant) • Remote Password Reset • Remote Ring — Help users find misplaced phone

121

**121 And then finally, remote assistant, we can always assume that something is going to go wrong. And if something does go wrong, how are we going to get help? One way we can get help is using remote assistant to call our phone when we've lost it. I've misplaced my phone. I don't

Page 20 of 21 know where it is. And so, we use remote assistant to do a remote ring.

Or I've forgotten my password. I don't know how to get in. so, remote assistant will allow us to remotely-- the enterprise, I should say, to remotely reset user's passwords. And then finally, if a user puts their password in two, three, four, five times, whatever the lockout policy is, we want to be able to say okay, it's now locked out. We don't want to have to mail the phone in or go into the corporate office to have it reset. We can remotely unlock the phone.

Notices

© 2015 Carnegie Mellon University This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study. Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected]. This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide. Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding. THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT). CERT ® is a registered mark owned by Carnegie Mellon University.

Page 21 of 21