Welcome to the third part of Android security structure, in this lecture, we will talk about encryption
and specifically encryption at rest right now.
Android version 5.0 and later.
So for quite some time, they actually supports full disk encryption and then from Android seven data
and later it actually supports Flyte based encryption as well and basically favors encryption, allows
different files to be encrypted with different keys that can be used to decrypt or decrypted or unlogged
independently.
OK, another thing that I want to cover here is the application signing.
So application signing allows developers to identify the author of the application so that the user
knows that the application is actually legitimate and also to update their application without creating
complicated interfaces or permissions.
Right now, every application that is run on the Android platform by default must be signed by the developer.
So if you wrote it and you go to some other stores, that's definitely a very different applications
that actually attempt the story without being signed by default are rejected by either Google Play or
the package installer on the Android device now on Google Play.
Developers know their application is actually provided by them or modified by them, and the developers
actually can be held accountable for the behavior of the application.
But of course, if it's modified, then all bets are off.
Right now on Android applications, I think is the first step to placing an application in its application
sandbox.
OK, the sign applications are difficult to define video that it is actually associated with video applications
and then different applications run under a different user I.D..
Now, application signing ensures that one application cannot access another application except through
a well-defined IPC.
Now, when an application or a bigger files, basically applications are a bigger file than ever.
These are installed on an Android device.
The package manager is the entity that actually verifies that the EPICA has been properly signed on
with the certificate included in the applicant.
If the certificate or more accurately, the actual publicly in a certificate matches the key that is
actually used to sign any other APJ in a device, then UAP actually has the option to specify the manifest
that it will actually share a user I.D. with other.
Similarly, sign it, because right now applications can be signed by a third party, OEM or any other
type of marketplaces.
In a lot of cases, actually, some enterprises may have their own app, so they have a different market
will get it not only because the device has been routed and you want to get a free game from some other
market.
But in some cases, actually there are some legitimate stores that are alternate markets that applications
actually need to be signed and those are actually signed with a third party or selfsame 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 compromise
if you don't verify the CEO verification.
Of course, it's a little bit different to skill whenever you provide the operating system and you have
many different implementers in comparison to, let's say, Apple, that they actually control all the
devices.
And it's not like Apple uses running in other vendors hardware.