In brief
Why a dedicated crypto chip breaks the usual password guessing — on two devices: Galaxy Tab A8 (Unisoc, the chip over SPI) and Galaxy A06 (MTK, over I2C). In the first case a missing block of data has to be pulled out of the chip, and then the brute force can be offloaded to external computing power — but this is a theoretical chain, "suppose we intercepted control". In the second the chip itself checks the hash and issues the keys, working "like a gatekeeper", and then "we fundamentally can't do anything at the moment": the brute force cannot be offloaded, and inside there may be an attempt counter, slowdown and wiping. The result of the talk — a precise description of the wall, not a way around it. The most substantive part — the seven questions from the audience.
Key points
- The topic: why "it isn't possible to work at full capacity" with modern Kirin, Exynos, the new Qualcomm — cryptography is handled by a separate full-fledged processor.
- Only chips placed on the board separately from the SoC are considered: you can solder into such a chip and watch the exchange. Test rigs: Galaxy Tab A8 (Unisoc, SPI) and Galaxy A06 (MTK, I2C), chips of two generations.
- The crypto chip — "a full-fledged device": its own core at a decent frequency, memory, its own GPIO; in the MTK version there is so much memory that "you could fit whole operating systems in it".
- The key for the file system space is made up of the password, the hardware uniqueness of the SoC, constants, an arbitrary 4-kilobyte blob secdis, the state of the bootloader (is_locked), the state of the firmware (color), the manufacturer's ROT (usually a public key and a hash of it) and knox_nonce — a block of data inside the chip.
- Hence the main practical consequence: "we'll unlock the phone and somehow gain access to it" does not work — the state goes into the key, and when it changes "the encryption keys change at once and all the data effectively disappears"; unverified firmware changes color from green to yellow with the same result.
- Observing the exchange (pads, soldering, an analyzer) runs into the protection: the chip is turned on only for the duration of a transaction; the processors authenticate each other (the chip sends a random number, the main one encrypts it with the established key), a secure channel with session keys is brought up — after that, on the wire there is "just garbage".
- Desoldering the chip and playing with the power is useless: the encryption key is unknown. So one has to wedge into controlling the main processor.
- The theoretical chain for SPI: intercept control → find the key → repeat the exchange → supply power to the chip (head-on with wires — "we might fry something") → take apart the transaction, pull out knox_nonce → offload the brute force to external GPUs, CPUs and clusters.
- Galaxy A06 (MTK): the I2C bus is visible, the exchange over it is not even encrypted — and that does not help. The difference lies elsewhere: a weaver_info file appears (lying in the open, "nothing interesting") and the "Weaver logic" is at work.
- Only a hash is passed to the CryptoMCU, and the chip behaves like a gatekeeper: the hash is familiar — "here are your keys, go work"; it does not match — "go away, you won't get the keys".
- The ceiling: the brute force cannot be offloaded outside the phone. The chip can count attempts in its own memory, slow down the response ("You enter 10 passwords, then wait a minute") and, theoretically, after a thousand attempts wipe the contents — a memcpy and a simple counter are enough for that.
- The fundamental difficulty: the chip — a black box, the key inside may be arbitrary and not tied to the hash, authorization does not come down to extracting a blob, errors may be logged — "we can lose the data if it's handled wrong".
- The bottom line: if only a blob is needed — there is a chance; if the password check and the issuing of the key happen inside the chip — "we fundamentally can't do anything at the moment".
Tools, artifacts, technologies
- Crypto chip (CryptoMCU) — a separate processor on the board: a core, memory, GPIO; interfaces SPI (Tab A8, Unisoc) and I2C (A06, MTK).
- Components of the key: the password, the hardware uniqueness of the SoC, constants, the secdis blob (4 KB), is_locked, color (green/yellow), ROT, knox_nonce.
- Weaver logic / the weaver_info file — a scheme in which the chip itself checks the hash.
- Platforms: MTK, Unisoc; mentioned: Kirin, Exynos, Qualcomm; Knox — a separate Samsung space (spaces 0 and 1).
- Methods: soldering in and a logic analyzer, power control, intercepting control of the SoC, offloading the brute force to external GPUs/CPUs/clusters.
- The chip's protection: power only for the duration of a transaction, mutual authentication, session keys, an attempt counter, slowdown, wiping.
Legal and organizational context
There is no procedural content, but there is a direct warning to practitioners: unlocking the bootloader and reflashing destroy the data, and by the phone's own means — irreversibly; "with live phones it's better not to do that". In the questions the story of Apple and the American agency comes up, along with the appearance of a commercial tool for the iPhone — as an argument that there is no such thing as "100% security" from a vendor.
Questions from the audience
- 1 (name not given): the key scheme and root of trust — empirical work or CryptoMCU documentation? → Both; "this information is in open sources too", and the names inside the team are their own: "here a lot of people call these things whatever".
- 2 (Alexey): prospects? → If there is anything, the brute force will be "on the phone itself"; separate research is needed — who resets the state, how many attempts are safe; the chip's firmware may leak. "The battle of shield and sword… will always be there".
- 3 (Valeria): why do the data die because of the phone's state? → is_locked and color take part in the key (whether the firmware is original, whose signature it is signed with, whether boot is swapped). If the wrong firmware was installed by accident — recovery is possible, but only not with the phone's own tools: copy the data and go through the chain.
- 4: if the data have been saved, will it work to restore them back onto the phone? → Both the backup and the device itself are needed (the hardware uniqueness); during reflashing the phone may do a wipe — "that's a matter of luck".
- 5: is it erased physically or do the keys simply change? → At first the key changes and decryption is impossible; later the phone's internal processes may overwrite it as well.
- 6 (a Samsung user, "provocative"): what stops them from breaking the Knox folder, given that the vendor claims "almost 100% security"? → Knox — just a separate space, the question is the key to it; on supported MTK devices "Knox can basically be taken apart", on modern Exynos there is no answer: "Our company basically doesn't work with Exynos".
- 7: what to do when phones are left without wired interfaces? → The device still has to be booted and flashed, "it's impossible to flash memory over the air" — conductors will remain, the task will only get harder. Something else is more dangerous: since the May conference, two significant security patches came out for MTK in 2–4 months, "and that's not the most serious manufacturer".
The speaker's position
An engineering lecture with no sales pitch: no name of his own product, no promises. The limitations are named outright and more than once — the black box, the counters, the risk of destroying the data, "we fundamentally can't do anything". Where there is no result, that is said out loud rather than hidden behind "work is under way"; his own terminology is flagged as his own. The conclusion for the extraction industry is pessimistic: the pace of patches is scarier than any new interfaces.
Quotes
- "…this crypto-processor, the crypto-chip, is a gatekeeper. So it sits there and says: aha, right, I know this hash".
- "For us, the crypto-chip is a black box. We don't know what's inside".
- "…then here we fundamentally can't do anything at the moment".
- "…that pace is far scarier than wireless interfaces".