[MUSIC PLAYING]
JON MARKOFF: Hey, everyone.
Thanks for joining us for data encryption on Android.
My name is Jon Markoff, and I'm a developer advocate
on Android security.
NICOLE BORRELLI: Hi, and I'm Nicole Borrelli,
and I'm a developer programs engineer.
JON MARKOFF: So today, we're going
to talk about three topics.
So we're going to talk about key management
and authorizing keys, encryption operations--
so that's encrypting, locking, and unlocking your data.
And finally, some more advanced topics
for things that are a little bit outside of what
Jetpack security does.
So before we jump right in--
NICOLE BORRELLI: So the first time
that I was giving this talk, I saw this
and I was thinking to myself, so what
exactly is wrong with this?
JON MARKOFF: Yeah, so--
NICOLE BORRELLI: Is there a warning-- is
the warning about the answer, or is the warning
about what the warning says?
JON MARKOFF: There's a lot of warnings on this.
So if you actually find this Stack Overflow post,
you can find it by looking up the Android encryption AES,
Android encryption symmetric--
something like that.
It's actually the top result when
you try to figure out how to encrypt data
in an app on your phone when you're building an app.
And as you can see, there's a lot of things here
that might be kind of suspect as to-- when you're
trying to build an app, securing data and things
is really important.
And here, there's several warnings, like don't do this--
this is wrong--
so it's completely unhelpful.
And the biggest issue here is this is from 2011.
So this is completely wrong at this point,
it doesn't really help you.
And the biggest issue really here
is that it doesn't use Android key store which is a safe way
to manage keys and basically prevent someone
from getting access to the data that you've encrypted.
So at Google IO this year, we launched
Jetpack security, which basically allows
you to easily encrypt your data, files, and shared preferences
without having to really understand
the ins and outs of security.
NICOLE BORRELLI: So the question I had is--
so Android is a secure operating system.
We talked about this yesterday.
We've got SE Linux, we've got user IDs
that separate things, and we've got
on modern versions of Android, we've
got file-based encryption already.
So what is it that we're using the Jetpack security
library for?
JON MARKOFF: That's a great question.
So there's a few reasons you might want to use it.
One, if you're building an app that's
been running on a rooted or compromised device in some way,
because the file system is unlocked
if the user is present on the device,
that means that even though you have full disk encryption,
the data is now available to an attacker or someone that's
getting the device.
Secondly, you might actually have data
that you don't want your user to see.
So if you have like API keys, tokens,
things like that to authorize services,
you probably don't want those leaked,
and you probably don't want anyone
to get access to that because technically, they
could start pretending to be you, and using your quota
and getting free things that you have to pay for.
So the first really big important thing
here is key management.
So if you have like a car key, house, or apartment key,
something like that, that's something you can keep on you
and kind of secure.
But with phones or with data, you
can't really just physically make sure that it's OK.
If your device is compromised in some way,
and if someone has rooted it, or if you've actually
lost your device and it's been stolen, you don't really know--
you don't have a way of protecting
that key like you do.
Because even if it's in your pocket,
technically if something's happened,
that key could be used against you in some way.
So we get around this by using something
called the "Android keystore."
It's hardware backed, so that means
that it runs in a separate memory
space on the device, which means even though your app has access
to the keys, your app actually doesn't
know what the key material is, so you can't actually
get the key yourself.
The Jetpack security, we built it
so that when you create a key, it creates sensible defaults
so you don't have to understand all the ins
and outs of security.
You can also use features like strong box
which is actually a separate piece of hardware
on the device.
And that actually is a separate chip,
so there will be a slight performance
implication from using it because it
is a little bit slower technically,
but it's also a very safe way to manage your data.
And all the operations are going to happen
in this separate memory space, which
means that if you do encrypt-decrypt signing,
things like that, you know that the key is not
leaked into your application.
So if someone is spying on what you're doing in some way,
you're going to be OK.
So in Jetpack security, to get started, out of the box,
we provide a master keys class which
basically allows you to create a key and enter a keystore.
And that-- I mean the default is using AES-256.
So that means advanced encryption standard--
256 bit.
This is the normal sized key that you'd
use for pretty much anything.
It's safe, it's well known.
You also notice it says GCM spec.
So we use the block mode GCM, and we do no padding.
So if you want to encrypt a small amount of data that's
the key size or less, you don't really need any padding
or blocking modes.
One thing that's important here is
that a lot of the attacks and challenges
happen with encryption when you have data that's
longer than the key length.
So that's where padding and block modes come in place.
And that's again something that Jetpack security
takes advantage for you.
So as far as your application as a developer,
you're concerned about-- you really
just need to make sure you either have
a key in the keystore or that it's been generated safely,
and that you have an alias.
So there's a string that's going to be the key
to look this up and use later.
If you do want to set more advanced settings--
so that you want to use some sort of key authorization--
which Nicole will talk about in a second--
to actually make sure that there's a user present,
there's other options here.
Currently, we enforce that the key must be 256 bit.
We used GCM and no padding.
The other options you see below--
like I said, user authentication,
set strong box backed, and user required
are features that are totally optional.
And some of them, as you can see, are only from Android Pie
and up.
And the same thing in this case--
you pass in a keygen parameter spec object
that can be created, and you can use the basic--
you can build on top of what we provide in Jetpack security
for this.
NICOLE BORRELLI: Thanks.
So yes-- so on the previous slide,
we looked at that we can have a key that
is where the user has to unlock the device using
the timed auth.
And so the best way to implement this
is by using biometric prompt.
And essentially, we can--
so this is-- the best way to do it
is with the AndroidX library.
And we can-- it's pretty simple to set up.
We set up a builder, set what we want our title to be,
a message.
And then we say whether we want to allow using credentials,
that sort of thing.
And then we can authenticate.
You'll notice that we're doing time based,
so we're not going to pass a crypto or a signature there.
I'm just going to do this, and we
have this authentication callback
which you can see up here.
If the authentication is successful,
of course, then you can use your key.
If it's not, then you can prompt the user with the error.
Some of the error-- the errors here
should be recoverable errors.
There's non-recoverable errors that can also pop up,
so you just want to check for those to make sure that--
like if the device doesn't have any sort of biometric prompt,
it will callback here.
And so then once you have the key,
then we can do stuff with it.
So the first thing that we can do is use an encrypted file.
And so this, what it does is it allows you to encrypt--
it allows you to use a regular--
it has an API similar to file input stream
and file output stream, but it seamlessly
encrypts and decrypts as you're going along.
And so let's see.
So we've got this.
And we just create a file, and we
say, OK, I want to have this be an encrypted file.
So we can say--
with the file, give it a context.
We can pass in an alias if we would like and build this.
And then once we get the encrypted file back,
if we want to write to it, we can use open file output.
If we want to read from it, we can use file input.
And then this works exactly the same way
that you would normally expect, and everything is encrypted
and decrypted under the hood.
JON MARKOFF: So the other feature of Jetpack security
other than files is encrypting shared preferences.
So if you have sensitive data, like API keys like
I mentioned previously, you can use
the out of the box shared preferences and shared
preferences editor interfaces which
allows you to basically understand--
most people-- well, most developers already
know how shared preferences works,
and this allows you to take advantage
of that using keys and values.
So one interesting implementation detail
that we've used is you'll notice in the code
here that we actually force you always
to set the encryption scheme even though there's only one
value.
And this is actually ubiquitous through the whole library,
and the reason for that is, what if we put default in here,
and let's say in the future, we decide to add another--
add more algorithms, add more keys sizes,
add more stuff like that.
So if you did that and you upgraded, or you had an issue.
Or let's say that there was for some reason,
someone found an issue with AE2-256
and there needed to be a patch, and we
needed to use a different algorithm, as a developer
you wouldn't really know what you
were using if it was default because defaults change
over time, things could happen.
So that's why even though there's
only one value right now, it's explicitly
in the API like this.
And that's intentional for safety.
So I've have gotten this question before,
that's why I'm saying that.
Just so-- it is intentional, it does make sense.
I promise.
So in this case, similar to shared preferences,
you create an encrypted shared preferences object.
You pass in a key alias-- this is where you would find it
from the master keys class when you either get or create
any Android keystore key context from application.
And the algorithms are going to use--
and obviously my secret preference is the file name.
So it works very similarly.
You don't have to learn anything new,
and it does all the heavy lifting for you.
One other thing to mention as well
is the keys and values are encrypted differently.
So you'll notice here that it's using a static IV
or an initialization vector, which basically means
that every time you encrypt a key,
it's going to be encrypted the same way,
and this allows us to do lookups.
So the values will-- using the same file encryption
as-- and same encryption as the file.
But for keys, you always want have this lookup,
and that allows us to also encrypt the keys safely.
So why would we encrypt keys?
I think it's like email address key and then the value
of some email address.
Well, some developers, we've found,
also put sensitive information as the key,
so you might not necessarily want to do that.
So that's why we make sure we encrypt the whole thing,
and that's why it's safe to use pretty
much for any information.
So advanced encryption.
So we know-- we talked about generating keys, authorizing
keys.
There's one thing I wanted to bring up as well.
Jetpack security uses a Google open source library
called "Tink."
Tink has cross-platform security for a lot
of different platforms, a lot of different mobile platforms,
and it's something we use because it provides
a way and a method of ensuring that-- there's
a lot of different versions of Android,
there's a lot of different OEMs out there.
There's different versions of [INAUDIBLE] SSL
that are implemented-- are actually implementations
of crypto under the covers.
And that's helpful for us because they've
a whole team behind it, and they've
been able to solve a lot of the nuances,
and a lot of the changes, and also implement things
like streaming APIs--
streaming encryption as well as authenticated encryption,
which is a concept that's not necessarily--
it's available in the Java security extensions that
are built in the OpenJDK, but not necessarily something
that anyone really understands or knows how to use because
of the terminology.
So Tink does provide a lot more features,
and it does have an Android extension
as we mentioned as well, because we actually use it.
One thing to mention is that something
called "queue rotation."
So even though that we have a master key--
and we never explained why it was a master key--
the reason is because each file or shared preferences object,
or each type of a primitive-- which a primitive could
be an algorithm or something like that-- algorithm key size
in Tink.
And we create key sets of everything.
So Tink handles this out of the box for us.
So [INAUDIBLE] create an AES-256 key to encrypt a file,
it will automatically create a shared preferences key set
under the covers.
And what this allows us to do is every time
you use Tink for some reason, if you're
using it under the covers and you
need to change or rotate a key.
Let's say for some reason, the keys that
are saved in shared preferences, you need to change them,
they've been compromised in some way,
you can rotate them which means it'll actually
add a new key to the key set that's
for that specific primitive or that specific file,
and allow you to migrate all the files or data that's
been saved into a new key set.
So that's something called "queue rotation."
Tink also supports features like message signing,
MACs, hybrid encryption.
If you don't know what hybrid encryption is,
it's using both public and--
asymmetric and symmetric encryption,
like an RSA key with an AES key to encrypt larger sets of data,
but also be able to share that by sharing a public key
with another party.
So looking forward-- I know that I've
gotten a lot of questions about this on Twitter
and a lot of questions here so far.
So I appreciate the interest in it--
it's been really great so far.
So looking to 1.0, it's coming.
I promise.
We're actually working with the Tink team
right now to add KitKat plus support.
Currently, Tink-- they're working on this,
but it doesn't support RSA key pairs.
And to support KitKat and Lollipop,
the hardware backed keystore on Android
doesn't support symmetric or AES keys until Marshmallow,
and that's the reason why it's been
taking a little bit of time.
I apologize.
I appreciate everyone's patience.
We're working on it.
We're also looking on features like key rotation,
like we've mentioned, and also adding some signing support.
And obviously beyond like--
and I appreciate the bugs that are coming in,
and the feature requests, and we'll keep working on that.
So it's definitely something we're working at.
It's coming-- don't worry.
We're looking at a beta and a release hopefully this year.
[MUSIC PLAYING]