SnapSafe: Security on Android From Forensic Searches

by Adam Brown

I have been quite worried about some of the news recently.  Photos on peoples' phones are being searched by authorities at border crossings and even traffic stops.  Sometimes with dire consequences.

We have apps like Signal which help us keep our private chats private, but I could not find a satisfactorily secure app for keeping our photos safe.  Not only from unwanted searches, but from auto-cloud backups, nosy friends, or a myriad of other attack vectors.

So I decided to write one myself: SnapSafe (snapsafe.org)

It's a free and open-source app (MIT License) and maybe it can help protect you.  This article will examine both the legal and technical security environment on Android and how SnapSafe aims to operate securely inside of it.

Along the way we'll learn how to protect yourselves more generally against unwanted device searches.

A Short Note About Threat Models

Understanding your own threat model is important.  State-level intelligence services that have determined interest in you in particular are nearly impossible to defeat.  The U.S. intelligence services built a replica of Iran's uranium enrichment facility so they could test their code against it.  Then a team of engineers spent years developing a worm that deployed four zero-day exploits, each one of which would have sold for hundreds of thousands of dollars on the dark web, in order to compromise Iran's systems.  This is not the threat model most of us enjoy.  You have to understand your own risk, and pick your tools and practices accordingly.  SnapSafe will not protect you against a determined state-level actor, but not much will.  It will, however, protect you against nearly anything else.

Our Case Study

You're a U.S. citizen at a border checkpoint.  Your phone is out of your control.  It has been seized, and the attacker will attempt to extract as much data as possible from it.

Here is some important legal context: thanks to the Fifth Amendment to the Constitution, you have the right to refuse to provide information that could incriminate you.

Therefore, if your phone is locked, you cannot be compelled to divulge the PIN, because it resides solely in your mind.  However, U.S. courts have upheld that biometrics are not protected in this way.  So if you have face or fingerprint unlock, these could be compelled from you and used to unlock your device.  This brings us to our first security recommendation: Disable biometric authentication.

Once unlocked, you should still be protected from "unreasonable search and seizure" thanks to the Fourth Amendment.  In 2014, the U.S. Supreme Court ruled that probable cause is not enough to search your device and seize any data found on it.  A warrant would be required for that, except at U.S. border checkpoints.

If you're a citizen, you can refuse to provide your PIN, and they cannot deny you entry.  They do have the power to hold you there for a long time and cause you trouble though.  If you are not a citizen, you can also refuse to provide your PIN, however they are then within their rights to deny you entry.

Border checkpoints are a huge legal gray area, even for U.S. citizens.  They still cannot compel you to reveal a PIN, but if the device is already unlocked, or they unlock it via biometrics, then they have broad authority to search and seize data found on it.

There are two forms of device search at the U.S. border as of today:

• Basic Search
• Advanced Forensic Search

Basic Search

This allows the agent to simply use your unlocked device.  Open apps, read text messages, thumb through photos.  This type of search has been used in recent months to discover photos that were in "Recently Deleted" in one case, and text messages in another case, that the border protection agent found objectionable and denied the person entry to the United States.  So it is definitely of concern, even if it is basic and easy to defeat.

Protect yourself:  Do not have biometrics enabled and ensure the phone is locked before it is seized.  Turning it off before entering a checkpoint is a pretty failsafe way to ensure the strongest security for your device.

SnapSafe protects against this attack vector by simply having a PIN that should be separate from the rest of the device.  No matter how the unlocked device got in the attacker's hands, they would have to compel a second PIN from you in order to access the photos stored within.  Legally, they should not be allowed to do this, but SnapSafe has further protections in case it happens, which we'll get into later.

What if you happened to be browsing SnapSafe's gallery, then switched away from the app.  Your gallery would still be visible in the task switcher even without opening the app.  SnapSafe protects against this by setting the secure flag on the application window.  This prevents screenshots, and will only show a blank screen in task switchers (a.k.a. recents).

Advanced Forensic Search

This is more concerning.  In this case the device is plugged into a computer and a forensic tool (such as (((Cellebrite's UFED))) tool or Grayshift's GrayKey) is used to extract as much data as possible from the device.  Legally, this data can be kept for a very long time.  How long?  It seems a bit ambiguous, so we should assume forever is a good possibility.  That means the data could be subject to long duration offline attacks.

With that context, let's see how Android's security model can help protect us, and when it fails, where SnapSafe plugs the gaps.

Android Security

Let's start with a primer on Android's layers of security.

Important:

• We will only be discussing Android 10 (API 29) and above.
• We will assume the device is not rooted, and has a locked boot loader, otherwise all bets are off.

Full-Disk Encryption

Android requires devices to use Full-Disk Encryption (FDE).  Meaning if your device is powered off and is configured to require a PIN at boot time, then nothing can be extracted.  If the disk were mirrored somehow, it would just be an encrypted blob.  So we've come to our second security recommendation: Set a PIN to be required at boot.

Once the PIN is entered, the FDE key is kept in memory, and for all intents and purposes, the disk is now accessible.

File-Based Encryption

Once the disk has been decrypted and the device is booted, only system level files are fully decrypted.  The user's data is still encrypted, and the File-Based Encryption (FBE) key is not resident in memory yet.  If your phone is sitting at a lock screen, this is the state your phone is in.  Hooking a phone up to a forensics tool in this state would not provide the attacker anything beyond boring system files.

FBE protects "credential protected storage," that is files and directories which are only decrypted when the user has provided their credentials.

Each time you unlock your phone, the FBE key is loaded into memory, at which point your credential protected storage (a.k.a. user data) is now accessible.

In this state, a forensics tool can extract a broad set of data.  What types of data are we talking about? Data stored in public directories for:

• Photos
• Videos
• Contacts
• Downloads
• SMS Messages

Data stored in app-private storage should be safe.  Every app only ever has privileges to read and write its own files on Android.  But there is a security loophole: app backups.

Android provides a convenience feature to backup your apps, and all of their data.  This is a well intentioned feature.  It's designed to help if your device is lost or destroyed, or to easily migrate to a new phone, but it is a glaring security hole if your device is unlocked.  The full data of each app can be exported, unencrypted.

SnapSafe protects against this style of search in two ways:

1. We never write anything to a public directory.
2. We explicitly disable all forms of app backup.

Thus on a non-rooted, non-exploited device, SnapSafe's data is safe so far.

If everyone was playing by the rules, that would be the end of it - your data inside SnapSafe is secure.  The Android Debug Bridge (ADB) used to pull these app backups is a normal piece of software.  It follows all of the OS's rules and simply would not allow exporting of any of this data marked for no backup.  This brings us to the third recommendation: Turn off developer mode and USB debugging when traveling.  This will defeat casual or incompetent searches at least.

Unfortunately for us, most forensic tools don't stop there.  Now we begin to think about how to protect ourselves when a tool is actively trying to subvert the built-in protections.

Security-Enhanced Linux

This is a Linux kernel module developed by the NSA in the early 2000s to greatly enhance the resistance of Linux to exploits.  It enforces strict access control to process memory.  The worry here is that we have an encryption key loaded into our processes' memory, and an attacker is able to read our processes' memory and steal the key.  SE Linux should provide robust security against this.  SE Linux has been part of Android since 2013, and 100 percent of devices Android 10+ will have SE Linux enforcing mode enabled.

Exploitation

We're going to get somewhat speculative here, I don't know how a tool will bypass SE Linux's protections, or Linux's filesystem permissions.  But exploits exist, so we'll move forward assuming various levels of compromise.

Vulnerabilities get reported, they get fixed, patches get deployed, but it's often up to the user to apply these.  Having a device from a manufacturer that provides regular security updates is critical.  Applying those security updates in a timely manner to your own device is critical.

Most of the exploits these commercial forensic tools are using are well known.  If the forensic company knows about the exploit, Google knows about the exploit, and there is almost certainly a patch for it.  For most of us, these will not be zero-days used to gain access to our device.  Thus we come to our fourth recommendation: Keep up to date with security patches, and that should defeat most commercial tools.

Filesystem Gets Compromised

In this scenario, the attacker has bypassed Linux's file permissions and gained access to the app-private directories.  This is bad, but SnapSafe is resistant to this type of attack.

Photos never touch the disk unless encrypted.  Even thumbnails used to improve scrolling performance in the gallery are stored encrypted.

SnapSafe's data encryption key, the most important thing to protect, is handled in one of two ways:

Key Wrapping:  On devices that support it, we use the available hardware key store to wrap the data encryption key.  This strongly encrypted key is saved to disk and should be sufficiently secure even against offline attacks.

Ephemeral Key:  An alternative method of protecting the key is to only ever derive it in memory.  In this case it never touches the disk, and thus nothing would be stolen if the disk was compromised.  This method makes authenticating with the app slower though.

A note on hardware key stores: These are a crucial element of security on modern devices.  These contain encryption keys in a separate secure part of the hardware.  Even if your OS is compromised, the attacker cannot get the keys.

Any Android phone made after 2017 will contain at least a Trusted Execution Environment (TEE).  On certain flagship devices, a higher security model exists: the secure element.  This is a physically separate chip, similar to a TEE, except it is resistant to a broader range of threats, including chip-off attacks.  SnapSafe will use whatever security hardware you have available, up to and including a secure element.

Memory Gets Compromised

This is pretty much the worst case scenario, but also the most unlikely.  Everything about both SE Linux and Android is designed to prevent this.  But as we say, unlikely events are not impossible events.

Individual images are stored transiently in memory, one at a time when viewing a specific image.  Thumbnails are a slightly bigger concern; they are stored in batches in an in-memory LRU cache.  These are lazily loaded, so only what has been requested recently would be resident in memory.  If you had just been scrolling your gallery and your memory got dumped, the attacker would get a subset of the thumbnails.

The biggest concern though is the encryption key.  Once derived, it is resident in-memory for the duration of your session.

We have two checks against this:

1.)  Key Sharing:  Keys are not stored in the clear in main memory.  Instead, they are split into two obfuscated parts using an XOR cipher.  A partial memory dump could potentially miss one of the halves making the key unrecoverable.  They are also obfuscated, which may hide them from automatic scanners looking standard AES keys.

2.)  Session Timeouts:  When your session expires, sensitive data such as the thumbnail cache and the encryption key, are securely evicted from memory.  This means that any memory-based attack must execute within that time window, or else there will be nothing of importance to steal.

Brute-Forcing

Now we get to the less technical, more social weaknesses in our security chain.

If the user has a four-digit PIN, it's not inconceivable that it could be outright guessed.  Or an automated process could brute-force it in a reasonable amount of time.  SnapSafe has several bulwarks against this.

First, a strong PIN is required.  No repeating digits such as 1111 are allowed.  No sequences such as 1234 are allowed.  The top ten most common PINs are also blacklisted, such as 6969.

Failed PIN attempts result in an exponential back-off, making each successive attempt take longer and longer.

Finally, a maximum of ten failed attempts are allowed, after which all SnapSafe data is wiped.

Closing the app or restarting the device will not reset the back-off timer or the current number of failed attempts.

All Security Is Vulnerable to a $5 Pipe Wrench

No matter how advanced our encryption and security practices, a $5 pipe wrench wielded in the right way can compel a PIN from you pretty quickly.

It's a mostly apocryphal saying in cyber security, mostly.  There could be a myriad of reasons you feel forced to divulge a PIN. Maybe you will be denied entry if you don't.  Recently a U.S. citizen, a lawyer who knew his rights, was being compelled to divulge his PIN for a phone search.  He resisted, but eventually decided to divulge the PIN.  I don't know why he made that choice, but it can happen.  The point is: even though technically and legally your data is safe, for social reasons, it might not be.

SnapSafe has a feature to help protect against this.  It's a feature of last resort: the poison pill.

This is an advanced feature not set up by default.  The user creates a second PIN, the Poison Pill PIN (PPP).  If the user is being coerced for a PIN, and they determine they must hand it over, they can provide the PPP instead of their true PIN.

When entered, it will wipe all of SnapSafe's photos and thumbnails from disk and then log the attacker in as if nothing untoward has happened.  They will have full access to the app after that.  However, in this rather extreme scenario, it may seem suspicious to the attacker that your secure photos app is empty.  Why do you have it if you don't have any secret photos after all?

So ahead of time, the user can take several benign photos and mark them as decoys.  Then, when the poison pill is activated, these decoy photos will be preserved.  Now the attacker will browse a gallery full of uninteresting photos, and will be none the wiser.

So What Have We Learned?

The fundamental underpinning of Android's security model are solid.  For most of us, it often comes down to higher level problems.  A weak PIN, biometrics, unapplied security updates, or careless apps that simply move deleted photos to another folder rather than truly deleting them.

Unfortunately, we must take our security into our own hands.  With a little bit of knowledge, and a couple of thoughtfully designed apps, such as Signal, we can indeed protect ourselves.

Key Takeaways

• Know your rights!
• Require a PIN at boot.
• Disable biometrics.
• Disable developer mode (ADB) and revoke all authorizations.
• Keep your device software up to date.
• Optionally: Turn your device off before entering a checkpoint.
• If you need a secure way to take and store photos, SnapSafe could be a good option for most threat models.