Android Security

Table of Contents

Google Android Security Model -1 ...... 2

Google Android Security Model -2 ...... 5

Google Android Security Model -3 ...... 7

Google Android Security Model -4 ...... 10

Google Android Security Model -5 ...... 14

Google Android Security Model -6 ...... 18

Google Android Security Platform -1 ...... 19

Google Android Security Platform -2 ...... 20

Notices ...... 22

Page 1 of 22 Google Android Security Model -1

Google Android Security Model -1

Android platform is responsible for securing Linux kernel. • Secures user data — Secure inter-process communications • Protects system resources — Removal of unnecessary and/or vulnerable sections of kernel — Access to storage media — Transmission of network data • Application run-time — App Sandboxing limits access to Linux kernel o Mandatory for all apps (native and third party) — Leverages Linux user-based isolation of resources

**017 The Android platform is responsible for securing the Linux kernel. So Google-- it's Google's responsibility to make sure that the Linux kernel is secure, that there's not bugs, that there's not security risks inherent with the kernel. The platform also secures user data by securing the inner process communication. It prevents-- or it's supposed to prevent-- applications from talking to one another, applications from accessing the kernel, or making changes to the kernel. Now, depending-- as we'll see, that doesn't always work.

Page 2 of 22 Protects system resources: Removal of unnecessary and/or vulnerable sections of the kernel. Again, if Google identifies a portion of the code that is a security risk, it's their job to fix it. They own the source code. Even though it's open source, they're the primary people responsible for the source code.

Access to storage media. The platform says where you can write the application to. Can I write it to this area? Can I write it to the media card? The kernel, the platform, makes that decision. And transmission of network data: Can this app transmit over the network? Can it do this? Can it-- that gets into the permission model. When I download an app on an Android phone, I have to say I can write-- or, "I need these permissions." The app has to say, "I need permission X, Y and Z." And I as the user have to say, "Do I want to give the app those permissions or not?" If I don't give those permissions, the app won't install. So I have a binary decision. Do I install it with these permissions, or do I not install it because I don't like the permissions it has? There's no middle ground. I can't say, "Well, it can access these things, but I really don't want it to access the call logs." I don't have that choice as a user. It's all or none, from my perspective.

Application run-time: App Sandboxing limits access to the Linux kernel. It's mandatory for all apps, native and third-party. It's also supposed to limit apps interacting with each other.

Page 3 of 22 So I have Angry Birds, and I have my Gmail client. Angry Birds should not be able to look at the data in my Gmail client. They're in two separate memory spaces. And it leverages the Linux user-based isolation of resources in order to do this Sandboxing. It's using-- Linux is a fairly secure platform. It has a lot of nice security features built in. It's leveraging those security features in order to help isolate it. They use different parts of RAM. They're not sharing RAM space. They're using different parts of IO. There's not supposed to be any communication between them.

Page 4 of 22 Google Android Security Model -2

Google Android Security Model -2

System Partition • Set to “read-only” • System partition contains: — Android's kernel — Operating system libraries — Default applications — Application runtime — Application framework • Safe Mode Access — Enables the device to boot with only default apps

**018 The system partition: This is set to read-only. There should not-- apps should not be able to make changes to the system partition. You don't want apps making changes to the system partition. This is equivalent to, say, the System32 folder in Windows. Except more secure. System32, the default build, most of those files shouldn't be changes unless they really have to. And as Windows has progressed, Microsoft has limited more and more what apps can make changes to the System32 folder. Before it was sort of willy-nilly, anybody could do it. Now apps or-- I say apps-- programs in Microsoft have to have explicit user

Page 5 of 22 permission to actually write there. So they're changing the security model on the desktop side to try to prevent unauthorized use on the computer side.

Well, the OS developers do the same thing on this side. They want to prevent the system kernel from changing. The first step, the easiest step, let's make it read-only. By default, there's no write permissions to the system kernel, or the system partition. The system partition contains the kernel, the operating system libraries, the default applications-- so the applications that are installed by default by the phone manufacturer or by Google-- the application runtimes, the application frameworks. So how do the applications actually work? What are the libraries for the applications? What's the underlying kernel for the phone? All those items are supposed to be read-only.

And there's also supposed to safe mode access. So the safe mode access is to allow the device to boot, even if something goes wrong with the phone. So I install some app, and for whatever reason the phone now won't boot. Most Android phones, there's a way to force it into safe mode. And it's exactly like Windows safe mode. So those of you that have used Windows for a long time, you know that when you boot, if there's been a system error, you're usually given the option to load into safe mode. When you load into safe mode, you only have access to

Page 6 of 22 certain functionality. It's the baseline functionality. So with safe mode access, if I have an application that crashed my system for whatever reason-- I boot up the phone, and every time the phone boots, that application crashes the phone-- I can boot into safe mode instead and have the ability to remove that application and then reboot into normal mode, and that should fix the crashing problems. That's why safe mode is there.

Google Android Security Model -3

Android’s secure default core applications • Google WebKit browser • Google calendar • Gmail • Google Maps • Google SMS messenger • Google e-mail client

http://www.googleappscentral.com

**019 Android's secure default core applications: Google WebKit browser, Google calendar, Gmail, Google Maps, Google SMS messenger, and

Page 7 of 22 Google email client. Now, these are the default apps that Google has defined in the operating system. However, manufacturers, depending on the definition document, are allowed to switch out some of these apps for custom apps that provide the same functionality. So if I'm a manufacturer, I don't necessarily have to install Gmail. I can install my own email client as long as it has the same functionality that Gmail does. I don't have to install Google's calendar. I can install a different calendar, as long as it meets the requirements of the definition document. This is one of the greatest strengths and one of the greatest weaknesses of Android devices. Unlike with Apple iPhones, where Apple makes the determination of exactly which apps come by default, and every single phone comes with the same default apps, Google leaves some of this up to the manufacturer.

So I, as a user, if I don't do my research, might not know that the HTC phone I just bought isn't using the secure default core applications. It's not using Gmail, or it's not using Google calendar; it's using something HTC put on the phone instead. And how do I know that the applications that HTC just loaded have the same security or secure code that the applications that Google is looking at?

Or, if a bug is found, how long is it going to take HTC to update their applications compared to how long it will take Google to update their

Page 8 of 22 applications? So it's great that it's customizable. It's great the manufacturers can make customization choices for the phones they're creating. But there's a risk inherent in that. Without using the default apps, you're now left up to the phone manufacturer to be doing the update process, to doing the patching process, making sure that these programs don't have bugs in them. It's no longer Google's responsibility to make sure that HTC's email client doesn't have a bug in it. It's HTC's requirement to make sure that their email client doesn't have a bug in it.

Page 9 of 22 Google Android Security Model -4

Google Android Security Model -4

File System Permissions Each app runs as own user Data cannot be shared or changed by other apps • Author of third-party apps can circumvent this OS rule. Android 3.x and later offers full file system encryption • Only available for devices utilizing device passwords • Does not encrypt removable media by default

**020 So, file system permissions. Again, when I download an app and install it, I get a list of what permissions the phone requires. "I require X, Y and Z in order to actually operate. Do you as the user agree to this?" You only have to agree one time, or if the permissions change on an update. So when you first install it, it needs these permissions. A couple updates come out, and eventually with this update, it needs an additional permission. You as the user then have to say, "Yes, I accept the new permissions." But the whole time, the rest of the time this program's running, you don't see what permissions it has. You don't see

Page 10 of 22 what resources it's using. Once you approved it, it's approved, it's good to go, and that includes any code that comes with it. So again, I have a free app but it has ads in it, and that's how they're actually making their money. The ads have the exact same permissions as the app itself.

And usually the ads aren't provided by the developer of, let's say, the game. Angry Birds-- the developer probably isn't making the ads. It's an add-on code that they got from some other company. Well, that add-on code is running with the same permissions that Angry Birds is running with, and if they didn't do validation, that doesn't have any security flaws, you might be opening yourself up to other attacks, without even realizing it. And the Angry Birds developers don't realize it either. They didn't realize that there was a security vulnerability with whichever ad company they're using, but by the inherent permissions of Angry Birds, you've opened your phone up, through Angry Birds' application, to do something bad. Now, I'm not saying Angry Birds is compromised in any way. It's just an app that everybody knows about.

Each app runs as own user. So, again, this is one of those ways they sandbox, by not having-- by having a unique user for each app, apps shouldn't be able to work with each other, because you have to have the right user permissions to change another application. Data cannot be shared or changed by other apps.

Page 11 of 22 However-- and this is a big however-- authors of third-party apps can circumvent this OS rule. There are ways around it. Again, Google releases the code; they make it as secure as possible; but there's always going to be either bugs or gotchas with the code. Third-party app developers have found ways to circumvent the non-sharing or changing by other apps. How long is that going to remain? I don't know. Is there a certain it's not closed? Probably, but you'd have to ask Google why they allow it.

Android 3.0, or 3.x and later, offer full file system encryption. So with Android 3, which was only released for tablets, and Android 4, which is now a tablet and phone operating system, I can fully encrypt my disk. It takes about an hour. Which isn't bad. You have to have a full battery. You have to have 100 percent battery. It has to be plugged in. And I can encrypt it. Takes about an hour. The recommendation is that should be one of the first things you do on a new device. Again, if somebody gets physical access to it, there's really two things that prevent them from getting the information from your device easily, relatively easily: having a password on the device, and having the information on the backend encrypted. In order to set encryption, you must have a password, and that password cannot be a swipe password. So it has to be alphanumeric password. It says, "Does not encrypt removable media by default." From what I've seen,

Page 12 of 22 there's not even an option on most devices to even encrypt the removable media. When we talk about BlackBerry, we'll see that BlackBerry devices, you do have the option to encrypt removable media cards. Most Android devices, I don't have that capability, and most Android devices do have removable media. So if you're storing sensitive information on your tablet, you're encrypted tablet, and you're not password-protecting or encrypting the documents themselves, you should really consider installing them or having them stored on the internal memory if you can, rather than on the memory card. Because if I take the memory card and put it into a forensic tool, such as Guidant Software's EnCase, or Access Data's FTK, it would be able to read that information if it's not encrypted. Not a problem whatsoever to read that information. Most media cards are formatted FAT32. So very easy to read the information off that media card without encryption.

Page 13 of 22 Google Android Security Model -5

Google Android Security Model -5

Passwords • User configured — Not mandatory • Helps prevent unauthorized access • Enables file system encryption • Pattern Lock — User defined graphical password — Does not allow for encryption

**021 Passwords-- user configured: Not mandatory, not set by default. Android devices, by default, have the either the swipe to unlock, or move the little guy down to unlock. Those provide absolutely no security whatsoever. So at minimum, a swipe pattern should be chosen. If any sort of sensitive information is used on that phone though, it's recommended you use an alphanumeric password. Forensic tools, at this point-- so, Cellebrite. Cellebrite's UFED is one of the preeminent forensic tools on the market. Using the UFED, about half of the Android phones that are available, the swipe pattern can be broken. It can go into physical

Page 14 of 22 memory, find out where the swipe pattern is stored, and get the swipe pattern out of memory. Can't do the same thing with complex passwords. So just be aware. And these forensic tools--

Student: Why is that? Are they stored in different places, in different ways?

Shawn Fleury: Yes. It's stored differently, and it also depends on the manufacturer of the device and how the manufacturer stores it. So it's not necessarily an issue with the operating system itself, because when Cellebrite-- Cellebrite's updates the last couple months have focused on particular device manufacturers.

So I haven't seen a single HTC phone where the swipe pattern is breakable, yet, but I've seen other manufacturers where the swipe pattern is breakable. So then the question becomes: Is it the way the phone hardware is working itself that's allowing them to get to it, or is it something with the operating system? Well, since the HTC ones don't have the swipe pattern broken yet, I'm guessing it's the way the other device manufacturers have encrypted it, or stored the encryption, or there's some weakness somewhere. I can tell with the iPhone, the encryption chip on the iPhone 3GS and the iPhone 4, there's a flaw in it, where it allows you to brute-force it. I can't tell you exactly what Cellebrite is targeting for the Android ones, because they don't

Page 15 of 22 want their competitors to know how they're breaking it. So they haven't released specifics on what exactly they're doing to get the information, but I can tell you that they have the ability to do so. So I don't know if I answered your question or sort of bypassed it.

Student: I don't know if the answer's known.

Shawn Fleury: It's known by Cellebrite, but they're not going to tell me how they're exactly doing it.

Passwords help prevent unauthorized access. It's the first layer of security. When we talk about cell phones, we talk about multiple layers of security. We want to make it as difficult as possible for somebody to get access to the phone. Once you've set a password, you can then set file system encryption. Whenever I buy an Android device-- and I've bought three so far-- the first thing I do when I get it back from the store is, after providing it with my Gmail account, which is the first thing you have to do, I set a password. Before I do anything else. And the next thing I do is if it has a full charge, I turn encryption on. If it doesn't, I plug it in until it has a full charge, and I turn encryption on. So the user data is not encrypted by default.

When we talk about Apple, their user partition is encrypted by default. It's up to the operating system whether it's encrypted by default. Android does not.

Page 16 of 22 Pattern lock: It's just a user- definable graphical password. Does not allow for encryption, and basically what you do is you draw a pattern. You can only do each dot once. You can't go through a dot twice. So you have nine points of security. And once it's set, you're good to go. Except you can't encrypt at that point, and the screens are very good at keeping fingerprints. So if you're not wiping your phone off constantly, and you just unlocked it, somebody will very easily be able to see what password you just inputted on your device. So just be careful about that.

Page 17 of 22 Google Android Security Model -6

Google Android Security Model -6

Passwords • Personal Identification Number (PIN) or by alphanumeric character password • To get to the security options — Settings> — Security> — Screen lock. • Allows pattern lock

**022 Some devices-- well, you can set a PIN or you can set an alphanumeric password. I would not set a PIN-- yes, again, four-digit password. Nice and easy. But if you just set a PIN, there's a chance that it could be easily brute-forced. There's only 10 thousand possibilities when we talk about a PIN-- 0000 to 9999. It's only a four-digit pin. If there's any sort of weakness, such as the earlier iPhones, it can password break the password, no problem whatsoever. So to get to the security options, Settings, Security, and then go to Screen Lock, and within those menus it allows for both pattern lock and/or password.

Page 18 of 22 Google Android Security Platform -1

Google Android Security Platform -1

Security Validation Certified • Certified government OS co-created by the NSA Base level OS Security • Open-source OS, subject to high scrutiny • Core operating system is isolated • Kernel partition is set to read-only Authentication • Token-based two factor authentication

**023 Security validation certified. So, this is the certified government OS co- created by the NSA. So they worked with Google and they were able to create this custom kernel for allowing their employees to use Android devices. The base level OS security-- open source operating system, subject to high scrutiny, anybody and their mother can get access to the source code, anybody can look at it.

Now, not anybody's going to probably understand it, but if you have any sort of Linux programming background, you'll probably exactly understand what the code is doing. The core operating system is

Page 19 of 22 isolated. Again, we keep the core system separate from the application space. The kernel partition is also set to read-only. So apps should not be able to write to the kernel partition.

Authentication: Token-based two- factor authentication. So you can get additional security on your phone to require two-factor authentication, but that's not by default.

Google Android Security Platform -2

Data Protection • Full file system encryption • Encrypt all data on the device • Encrypts external storage media Application Security • Applications require code signing • Uses a kernel-level Application Sandbox

**024 Data protection: Full file system encryption is possible. Only encrypts the user partition. Does not encrypt the system partition. But anybody can see the system partition anyway

Page 20 of 22 because everybody has access to the source code. So, your user data isn't stored there. So for your purposes, my purposes, we want to protect the user side of the house. Encrypts all data on the device, excluding the system kernel. Encrypts, or can encrypt, external storage if the device manufacturer enabled it. Some do, most don't. So normally the removable media card is not encryptable.

Application security: All applications require code signing. So Google has told the developers, "You must sign the code with the certificate that we provide you when you become an app developer, and if you try to run a code, or run an application that's not signed, more than likely your Android device is going to either fail on the install, or the application will crash while it's trying to run." And uses a kernel-level application sandbox. So again, the applications are away from the system kernel, and the applications are in their own memory space so they should not be able to talk with one another.

Page 21 of 22 Notices

Notices

This material has been approved for public release and unlimited distribution except as restricted below. 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 is based upon work funded and supported by the Department of Defense under Contract No. 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. NO WARRANTY. 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 of Carnegie Mellon University. .

Page 22 of 22