- [Lecturer] Google actually includes security features
and work with developers and device implementers,
to keep the Android platform and the ecosystem
in a safe environment.
So and again, it's not so much
only about the actual Android platform,
so your mobile device or your tablet or your refrigerator,
whatever the case is actually running Android,
but also as far as actually ecosystem.
How you're connecting to the app stores,
how you interact with APIs and so on and so forth.
Now, the beauty is that Android
of course is designed to be open.
One of the challenges is of course
is little bit less control than other alternatives,
like of course, Apple iOS.
Now, Google tries to maintain the Android platform
to offer an application environment
to help protect the confidentiality
and of course, integrity and availability of users,
and also of the data and the applications
and the actual device itself,
and as I mentioned before the ecosystem,
so the network.
Now, both Apple and Google have dedicated a lot of resources
to make their mobile operating systems
sort of, fairly secure.
Some of the main challenges in security
is whenever the users root their devices rather
or jailbreak their devices and leaving them open
to either malware or compromise applications.
Now, the main Android platform building blocks
are of course, the device hardware,
that runs on terms of hardware,
so that includes your smartphone, your tablet
of course watches, so smart watches, cars,
smart TVs, gaming systems, refrigerators,
you name it.
A lot of things actually run Android nowadays.
Now, the other beauty is that Android is processor-agnostic,
but it does take advantage
of some of the hardware-specific security capabilities,
especially in the ARM architecture.
So, and there's actually a security capability
called ARM eXecute-Never,
it prevents a remote execution or arbitrary execution
of any type of buffer or flows perhaps
that actually can be exploited in the system.
Now, the Android operating system of course,
is the core operating system
and it's actually built on top of the Linux Kernel,
so it's all based on Linux.
All device resources like the camera, GPS, Bluetooth,
wifi, the telephony functions, the network connectivity,
and you know, many more,
are accessed via the operating system itself,
via the core Android functionalities.
Now, you also have of course,
the Android application runtime,
so, Android applications are actually most often
written in the Java programming language
and they actually run in the Android runtime
and they refer to this as the ART.
However, many applications,
including the core Android services and other applications,
are actually native applications or include native libraries
within the operating system itself.
Now, the Android applications extend
the core Android opening system,
and there are two primary sources for these applications,
so the pre-installed applications that come with your device
or the user-installed applications
via the Google Play or any other stores,
of course, that can be accessed
mostly if you root the device,
and that's the problem with security as I mentioned before.
Now, Google provides a set of cloud based services
that are available to different compatible Android devices
and these services are not part
of the Android Open Source Project itself,
but they're included into many different Android devices,
so, but of course, you know,
we have the primary service for installing applications
or the actual store, which is Google Play,
you also have the services to actually push updates,
which is called Android Updates,
again, it's a update service that provides new features
and security updates through either the web
or through over-the-air or OTA functionality.
So now, there's also the Application Services
and basically it's a framework that allows
Android applications to use cloud capabilities,
like, backing-up your application data,
backing-up your settings.
And also, they have a Cloud-to-Device messaging,
that is called C2DM that is actually used
for pushing messaging to the cloud as well.
They also have another service called Verify Apps
and it basically, it can warn you,
or automatically block the installation
of any type of a compromise applications
or any harmful applications.
And also, it continuously scan applications on the device,
warning about or removing those applications automatically.
Another service is the SafetyNet,
so and again, I'm mentioning all this
because whenever you do security research
or whenever you're actually trying to do
"mobile device ping testing"
which by the way, is way different than let's say,
if you're trying to actually do ping testing on wifi,
in this case, you actually have to look
at many different things.
You have to look at these services
that I'm mentioning right now,
you have to look at the ecosystem
and we're gonna cover that throughout the course.
So, now going back to the services,
the other one is SafetyNet,
and it's basically a privacy preserving,
well, some people call it Intrusion Detection System
to assist Google tracking and mitigating,
known security threats
and also to identify other types of abnormalities,
by far is not an Abnormally Detection System
as you probably are familiar with,
that's why a lot of people
actually call it an Intrusion Detection System
within the Android ecosystem.
And now, part of that is actually the SafetyNet
at the station service,
basically allows for third-party APIs
to determine whether the device is CTS compatible
and also can assist identify the Android app
communicating with the app server.
So, whenever somebody actually creates an app that perhaps
is communicating to the cloud, to the app server,
let's say, I don't know,
Uber, Lyft, OpenTable,
whatever you actually use in your Android device,
that's the type of SafetyNet attestation
that in some cases actually is available
and implementers actually take advantage of,
to determine whether the device is actually CTS compatible
and also allow for the security of third-party APIs.
Now, there's also the Device Manager,
so the Android's Device Manager
and is a web app and also an Android app
that is actually used to locate lost or stolen devices,
fairly similar to what Apple has with Find My Device.
Now, the Android security model is actually based in part
on the concept of application sandboxes,
and each application runs its own sandbox.
Now, a long time ago, several years ago,
prior to Android version 4.3,
these sandboxes were defined
by the creation of a unique Linux UID,
and that UID was actually for each application
at the time of the installation.
Now from 4.3, so for quite some time,
now Android actually uses SELinux,
so the Security-Enhanced Linux.
This is actually used for defining the boundaries
of the application sandbox in Android.
Now, as part of the Android security model,
Android uses SELinux
to enforce Mandatory Access Control, MAC,
over all processes,
even processes running with a root
or super privileges or superuser privileges,
this actually helps protect the operating system.
Also SELinux enhance Android
by confining privileged processes
and automating the Security Policy creation on that device.
Now, Android also includes SELinux in Enforcing mode
and basically, a corresponding Security Policy
that works by default across those devices.
So now, in Enforcing mode,
and this is actually something you have to keep in mind
whenever you're actually doing security research
in Android platforms.
You know, in Enforcing mode,
illegitimate actions are prevented by default
and all attempted violations are actually logged
by the kernel to dmesg and also logcat.
Android devices manufacturers
should actually gather information about these errors,
so they can actually refine their software
and their own SELinux processes before enforcing them,
however, unfortunately this doesn't happen all the time.
That's one of the major differences
between Apple iOS devices and Android.
And again, I'm not by far an Apple fanboy in this case,
but unfortunately,
that's actually one of the major difference,
is that because Android of course,
Google provides the operating system
but it's up to the implementers
to actually do a few of these security implementations,
some implementations may be more secure than others.
Now by default, on Android only the kernel
and a small subset of the core applications
run with root per permissions.
Now, Android does not prevent the user
or an application with root permissions
from modifying the operating system,
can also modify the kernel or any other application.
So in general, root has full access to all applications
and all application data.
So that's whenever users that actually change
their permissions on an Android device
to grant root access to applications,
definitely increase the security exposure
to malicious applications and potential application flaws,
and that's whenever you see a lot
of impersonated applications and so on.
So again, a lot of people that actually root their devices,
I hate to say this but they're actually asking for it.
Now, some implementers may actually change that.
Another thing to actually keep in mind is that,
whenever you're doing security research on Android devices,
so in a lot of cases, actually a lot of people,
actually what they do is,
they start from just by rooting their device.
Now, the ability to modify an Android device that you own
it's important developers working with the Android platform,
so on many Android devices,
user users actually have the capability or the ability
to unlock the bootloader in order to allow the installation
of some other alternate operating system,
so some we call it custom ROMS.
And this alternate operating systems
may actually allow a user to actually gain root access
for the purpose of debugging, "debugging"
and then system components to actually access features
that are not present to applications
by the Android APIs by default.
Now, let's switch a little bit,
let's actually talk about encryption,
and specifically, encryption at rest.
Now, Android version 5.0 and later,
so for quite some time,
they actually support full-disk encryption.
And then from Android 7.0 and later,
it actually supports file-based encryption as well,
and basically, file-based encryption allows different files
of course, to be encrypted with different keys
that can be used to be decrypted
or unlocked independently.
And another thing is actually about,
another thing that I want to cover here is,
application signing.
So, what about application signing?
Application signing allows developers
to identify the author of the application,
so to making
that the user knows
that the application is actually legitimate
and to update their application
without creating complicated interfaces or permissions.
Now, every application that is run on the Android platform,
by default must be signed by the developer.
Of course, if you root it and you go to some other store,
that's definitely very different, right?
Now, applications that actually attempt
to install without being signed,
by default, again will be rejected by either Google Play
or the package installer on the Android device.
If you go to another store
and if you actually root the device,
then that's completely different again.
Now on Google Play,
developers know their application
it's actually provided by them or modified
and that the Android device and the developers
actually can be held accountable
for the behavior of their application.
But of course, if it's modified, then all bats are off.
Now, on Android application signing is the first step
to placing an application in its application sandbox.
The signed application certificates define which user ID
is actually associated with which applications
and then, different applications
run under different user IDs.
Now, application signing ensures
that one application cannot access another application
accept through a well defined IPC.
Now, when an application or APK files,
basically, applications are APK files,
whenever these are installed on an Android device,
the PackageManager is the entity that actually verifies
that the APK has been properly signed
and with the certificate included in the APK.
If the certificate or more accurately,
the actual public key certificate matches the key
that is actually used to sign any other APK on the device,
the new APK actually has the option to specify the manifest
that it will actually share a user ID
with other similarly signed APKs.
Now, applications can be signed by third-party OEMs
or any other type of marketplaces.
In a lot of cases actually,
some enterprises may actually have their own apps,
so they have a different market.
So, it's not only because a device actually has to be rooted
and you want to get a free game from some other market,
but in some cases actually are some legitimate stores
or alternate markets
that applications actually need to be signed,
and those are actually signed with a third-party
or self-signed certificate.
Now, applications do not have to be signed
by a Central Authority,
and Android currently does not perform
any Certificate Authority verification
for application certificates.
And that can be actually huge in the case of security
because it may actually lead to a security problems,
if you actually don't verify the CA verification.
Of course, it's a little bit different to scale
whenever you provide the operating system
and you have many, many different implementers
in comparison to, let's say, Apple,
that they actually control all the devices
and it's not like Apple iOS is running in other vendors,
in other vendors' hardware.