Most people do not use secure passphrase to lock their phones, but use a PIN. Even an 8 digit PIN is only 10^8 guesses, which any modern desktop can crack. To solve this, Android/iOS make an extremely long salt, so that + your PIN is your passphrase. In addition, there is logic to deter brute force attacks (e.g. after 10 guesses wipe my device)
The attacks have to overcome both of those, but if they do, cracking the original secret (your PIN)
is easy.
The other method is attacking a "live" phone/laptop, as it has the unprotected key, and one just needs to exfiltrate it.
If you are truly concerned, DO NOT USE a trivial crackable PIN! Use a long password that is hard to crack by itself. Additionally, turn off your device if you think you are in a position where you have to surrender your electronics! That way the unprotected key is gone.
(As a side rant, I wish Android and iOS would allow you to have a "start up" password and a screen unlock password. You used to be able to do that on Android, but it was through root and not officially supported. But it would be nice because then you could have an easy to unlock screen password and a really difficult encryption password).
My understanding is that the master encryption key does not exist on the device in non-volatile storage, but rather is computed by combining a secret key (I guess you could call this a “salt”) stored in the secure enclave with the user’s passphrase. When you start the device and authenticate, this derivation happens, and then the derived key is kept in memory and it’s only software keeping an attacker out.
If the locked state without a derived key loaded is as secure as it theoretically should be, doesn’t that mean recovering data off the device without uncapping (or similar) requires correctly guessing the passcode in however many master key derivation attempts the secure enclave is configured to allow before it wipes the secret key and renders the stored data useless?
This seems really secure on average, even with a weak PIN. I’m trying to decode Cellebrite’s claims about access to “locked” phones and I’m assuming they mean locked with key loaded, though I guess I can imagine some vulnerability that sidesteps the maximum attempts logic in the secure enclave.
> My understanding is that the master encryption key does not exist on the device in non-volatile storage, but rather is computed by combining a secret key (I guess you could call this a “salt”) stored in the secure enclave with the user’s passphrase. When you start the device and authenticate, this derivation happens, and then the derived key is kept in memory and it’s only software keeping an attacker out.
Sorry yes I sort of glossed over this part and some other parts in my explanation.
> If the locked state without a derived key loaded is as secure as it theoretically should be, doesn’t that mean recovering data off the device without uncapping (or similar) requires correctly guessing the passcode in however many master key derivation attempts the secure enclave is configured to allow before it wipes the secret key and renders the stored data useless?
You are correct. As pointed out below, this also assumes there is no vulnerability in the enclave. Having a secure passphrase with a secure key derivation function provides a more secure foundation however, because even having unlimited guesses means you are still down to the original brute force.
>To solve this, Android/iOS make an extremely long salt, so that + your PIN is your passphrase. In addition, there is logic to deter brute force attacks (e.g. after 10 guesses wipe my device)
nitpick: it's not just a "long salt", the "salt" is burned into the phone's security processor (trustzone or secure enclave) and can't be extracted so any attempts must be made using the exact phone. Using a gpu cracking cluster wouldn't help, for instance. AFAIK the anti-guessing logic is also implemented like this, otherwise you can just extract the salt and make unlimited attempts since the phone can't keep track of how many attempts you made.
Trustzones or secure enclaves can be "broken" via uncapping. They are designed to be resistant to that, not unbreakable. Uncapping is not new and has been around for a long time, it just takes a lot of expensive hardware and expertise. Ultimately, the keys are bits on silicon, and with some acid, a scanning tunneling electron microscope, and a lot of time, the keys can be pulled off.
It is very unlikely this sort of technique would be used against anyone but the most extreme threat actors (potential terrorists, etc). But with physical access, all bets are off. It isn't a matter of if they can decrypt, but how long it will take them given the resources available.
> Trustzones or secure enclaves can be "broken" via uncapping.
That's true, but it's a big step up from the “push a button, data appears,” described in them article.
If you become "a person of interest" to MOSSAD, good luck. You'll be needing those magical amulets and the submarine to hide in - and YOU'RE STILL GONNA BE MOSSAD'ED UPON!
Does the Titan M not store data in some physical medium?
As far as I know, there isn't any way to prevent a truly dedicated and resourceful attacker from reading data that exists physically. The only constraints are money and time.
A chip that e.g. self-destructed on detecting signs of tamper would be harder to break, but if the data exists physically, it must be recoverable in some way, no?
Bingo! Money and time. When you're going against an adversary with massive amounts of both, all bets are off. Physical access means eventual compromise.
Shouldn't a strong symmetric encryption with a long key prove to be safe enough as to not be crackable in a reasonable amount of time (~10 years), even if the hardware is directly accessible ?
Probably, at least in practice if no critical components in the chain fail due to bugs/exploits and are as secure as intended (excluding the metaphorical "hammer VS fingers" attack).
I think the difference here between you and the poster you replied to is that you're probably correct given certain assumptions but the earlier post also remains correct in a conceptual or theoretical sense, like pure information/security theory
I don't know why you were voted dead for asking a question.
That's a new account (name in green). I think they start out dead. I think one or more comments need to be voted up and then the account becomes not dead (alive?).
The trick for this case is a very long key, 1mb of more, try to recover all of them, you can lose about 60 bits, but not much more. What is the speed of extraction? You only need to delay it for a couple of decades.
Yeah some higher end security chips have passive mechanisms that make the microstructures more delicate and harder to reach and therefore harder to physically read. This is on top of active mechanisms that try constrain operation to well defined range of temperatures, voltage and power conditions to prevent brown out and booby traps that trigger effacement.
You have to disclose a lot of info during the cert process though so I don't think this is too much of a hurdle for big players like the NSA.
Newer devices (only Pixel 3 and newer, and Galaxy Note 20 and newer) also come with hardware security modules called Strongboxes (like Apple's Security Enclave).
The big issue with the unlock password being used for FDE is that the average user unlocks their phone many times/day, often in view of cameras.
If I worked for a LEO and was asked to "crack" a locked phone, I would start by looking at surveillance footage from anywhere the suspect might have pulled their phone out of their pocket.
That's my set-up with Android now. However, on a Pixel3a, I feel like I have to do a manual input several times a day, usually if I wash my hands, use lotion, things like that. It also doesnt work well if I am outside in the cold and need gloves.
Also, it is probably possible to narrow down pin codes by looking at the surface of the phone for finger prints/screen damage. At least on Android, the unlock will appear in the same location every time and unless your pin uses every digit, there will be heavier use in some areas. It is unfortunate that stock android does not rotate the input keypad, I believe some ROMS (AICP?) would do this and thus eliminate this attack surface.
Computationally I understand that cracking PINs is trivial for modern computers. But does anyone know by what means these mobile forensics tools are able to brute force? I thought iPhone's will lock you out for a certain amount of time after a certain amount of failed attempts. Depending on the device/OS, are there ways to extract some sort of hashed password then crack on desktop like usual? Is a vulnerability of some sort always required to extract phone hashes?
But Every process can be prone to glitching. Just mess with the “how many password failures have occurred? If >10 start erasing” process and there’s no such thing as too much failure anymore.
iPhones used to increment (or save the increment) after the password entry failure, so bypassing used to be as simple as quickly disconnecting power before your failure got recorded.
It’s also possible they can make copies of enough data and have a “slave” iPhone embedded in the device to continue cracking offline, just in case only the guts of an iPhone can do the decoding.
> I thought iPhone's will lock you out for a certain amount of time after a certain amount of failed attempts.
One of the techniques used is, copying the memory from your phone onto another phone, and then testing passwords on that. When it locks up, wipe it and recopy. I don't know if that is still used, however.
why not copy memory to another device and run a crack against a segment of the memory known to hold specific values until you match? I am not sure if they can block taking encrypted data off a device.
So my question is, case intrusion. Can this be detected in various forms in order to render the contents of the device useless? The safety factor to the owner is that they would have backed up the device to a trusted source before they voluntarily submitted a phone to being physically opened. you would need to not only check for separation but drilling through either side.
Not allowing "easy" access is not the same as "no" access though. I could easily imagine a radar/MRI imaging system generating instructions for a cnc drilling rig that would make micrometer accurate holes through the chip packaging, then inserting extremely precise probes directly into the wires inside the package.
I could also imagine a team of 5-10 engineers making such a system in a year (total costs <10 million), with 20-50 million in off-the-shelf hardware costs as a pessimistic estimate. As a company, you then "only" have to amortize this cost over 20 countries each wishing to crack the phones of 5 phones of high-profile criminals and/or dissidents each to get to an average cost of 600k per phone. It would easily be worth that much to the US to crack the phone of a high profile drug lord.
Long story short, private companies (even with as much resources as Apple) either need watertight mathematical proofs of security or accept that they stand no chance at all against nation state adversaries.
Unless your Apple product has a T2 chip. If it does, there's not protecting it other than don't let it physically fall into someone else's hands. The T2 debacle is probably the single greatest let down for me in Apple products. There have been plenty of things I bitch and moan about, but nothing has been as compromising as the T2 failure.
Thanks for the link, whose article is understandable by non-security technology types like myself.
Here are some limitations to the T2 vulnerability which give those of us with T2-equipped devices less to fret about:
> There are a few important limitations of the jailbreak, though, that keep this from being a full-blown security crisis. The first is that an attacker would need physical access to target devices in order to exploit them. The tool can only run off of another device over USB. This means hackers can't remotely mass-infect every Mac that has a T2 chip. An attacker could jailbreak a target device and then disappear, but the compromise isn't "persistent"; it ends when the T2 chip is rebooted. The Checkra1n researchers do caution, though, that the T2 chip itself doesn't reboot every time the device does. To be certain that a Mac hasn't been compromised by the jailbreak, the T2 chip must be fully restored to Apple's defaults. Finally, the jailbreak doesn't give an attacker instant access to a target's encrypted data. It could allow hackers to install keyloggers or other malware that could later grab the decryption keys, or it could make it easier to brute-force them, but Checkra1n isn't a silver bullet.
If the device is left unattended at a border crossing and it is taken away to a back room, you should just assume its been hacked or modified and shouldn't trust it again.
I wasn't referring to someone leaving/forgetting/losing a device. I'm talking about carry your devices through border inspection, and having those agents confiscate your devices.
> In addition, there is logic to deter brute force attacks (e.g. after 10 guesses wipe my device)
The brute force protection has historically not been flawless. Rumour says the Greykey used to brute force the pin/passphrase by glitching the power every few attempts which reset the counter.
What length PIN would you recommend in light of what commercially-available equipment is capable of cracking? Is an actual, honest-to-god password supported on latest Android?
It really depends on how your password is selected. "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" is a long password but won't protect you. You really want to optimize for ease of entry and memory, rather than using the largest character set or having the longest password. For a point of reference, these three choices have (roughly) equivalent security (128 bits of entropy):
1. 27 characters - all lowercase, randomly selected
2. 20 characters - upper/lower case + 15 special characters found on the first page of the iOS keyboard, randomly selected
3. 45 characters - 10 words from eff's short diceware wordlist, randomly selected
the first option would be the easiest to enter, despite being 7 characters longer than the second one, because you don't have to constantly switch between the various character types (since you're using a touch keyboard). The third one is 66% longer than the first one, but probably is easier to remember.
As for how many bits of entropy to use, AFAIK a preimage attack against md5 (128 bits) hasn't been pulled off yet, so it's probably safe for for the foreseeable future. You can probably go lower than that and still be safe, considering that a md5 preimage attack is significantly easier than cracking a phone pin (eg. no memory/cpu hard KDF, no trustzone/secure enclave).
> honest-to-god password supported on latest Android?
Yep, I have one. I haven't kept up with the latest, but the "standard" good password should be good (i.e. above 12 characters, letteers, numbers, etc.)?
Most people do not use secure passphrase to lock their phones, but use a PIN. Even an 8 digit PIN is only 10^8 guesses, which any modern desktop can crack. To solve this, Android/iOS make an extremely long salt, so that + your PIN is your passphrase. In addition, there is logic to deter brute force attacks (e.g. after 10 guesses wipe my device)
The attacks have to overcome both of those, but if they do, cracking the original secret (your PIN) is easy.
The other method is attacking a "live" phone/laptop, as it has the unprotected key, and one just needs to exfiltrate it.
If you are truly concerned, DO NOT USE a trivial crackable PIN! Use a long password that is hard to crack by itself. Additionally, turn off your device if you think you are in a position where you have to surrender your electronics! That way the unprotected key is gone.
(As a side rant, I wish Android and iOS would allow you to have a "start up" password and a screen unlock password. You used to be able to do that on Android, but it was through root and not officially supported. But it would be nice because then you could have an easy to unlock screen password and a really difficult encryption password).