Moderator's introduction
— And now I'll invite Dmitry to announce our next speaker. Yes, thank you very much. Can I get the clicker?
Evgenia Valeryevna, the clicker isn't working again. Could you switch the slide for me, please? Otherwise the magic won't happen. There. So, right now we'll have a presentation from the company ACE Lab. But let's talk in general about what it'll be about. Because after all, today we have a conference specifically on digital forensics. And modern mobile devices increasingly use various hardware keys, access code checks and other critical operations. That is, protection is now built not only at the level of important mechanisms, but it's now moved into a separate, isolated cryptographic processor.
And here a completely different set of tasks arises for specialists. How such protection is designed, what limitations it imposes, and what methods let us work with such devices in practice today. Please welcome the speaker from ACE Lab, Vyacheslav Chikin. Let's give him a round of applause.
Vyacheslav, the clicker.
Talk
Good afternoon, I'm glad to see you all today. And we'll talk about why it isn't possible to work at full capacity with such modern processors as Kirin, Exynos, maybe modern Qualcomm. It's because they have a device, a full-fledged processor that handles cryptography. And we'll try to conduct a little research.
So, this is what a crypto chip looks like on the processor board. We'll look at the cases where the crypto chip isn't built into the processor but is placed separately on the board. Clearly, for our research that's much more convenient. Here we can solder in, see what exchange is happening, and draw some conclusions. Today we'll be looking at devices based on the MTK and Unisoc processors.
Namely, on Unisoc that'll be the Samsung Galaxy Tab A8, and the crypto chip is connected to the processor via the SPI interface, and the Samsung Galaxy A06 on the MTK processor, and here the crypto chip is connected via I2C. Accordingly, here we have two different generations of crypto chips.
So, what does a cryptographic processor actually represent? In fact, it's a full-fledged device with everything that entails. It has its own core, which runs at a fairly decent frequency, which allows it to do a ton of cryptographic computations. And not only that. There are built-in cores, accordingly. It even has its own GPIO. It's a full-fledged device that we're dealing with.
This is for MTK. The only thing here is that it's I2C. But on the other hand, there's so much memory here you could fit whole operating systems in it.
What the key is made of and why you cannot peek at it
So, let's get started. Namely, what interests us. This slide shows the scheme for generating the key for the file system space. Accordingly, in order to get a key, some hash, we need the user's password. Also some kind of hardware uniqueness contained in the processor. It could be a key, a hash. Each manufacturer defines this differently. Certain constants, again, can vary.
A 4-kilobyte blob, secdis, that's also arbitrary. The state of the phone, locked, not locked, that's also taken into account. So if you're thinking somewhere that now we'll unlock the phone and somehow gain access to it, that doesn't work. Because in that case the encryption keys change at once and all the data effectively disappears. Also the so-called color. This is, essentially, the state of the phone.
That is, whether it's unlocked, not locked, what firmware is installed. That is, if the firmware isn't verified, the state changes from green to yellow, and again, we lose the data. And also some so-called ROT. This is data embedded by the manufacturer. Most often it's a public key and a hash of it. And here one more ingredient appears. I called it knox_nonce, some block of data contained in the cryptographic processor.
Okay, well, if some block of data is in the processor and an exchange takes place, we'll try to sneak a look at it over SPI and see what we get. That is, as always, we take the phone, look for the pads, solder, connect the analyzer, and what will we see.
Well, to start, let me tell you what exactly we're going to be up against. If it were all so simple, cryptographic processors wouldn't exist. If we just said: give us the key, and it said: here you go, guys. But that's just no fun. So, to start, the first problem is we need to turn the processor on. Samsung made it clever, it only turns on for a transaction. That is, we want to ask it something, the main processor turned it on, talked with it and says: okay, don't get in the way of my work.
Then, after we've turned it on, the processors have to shake hands with each other. To say: I'm Vasya, you're Petya, you're Petya, I know you, you're saying everything right, let's keep working. After this, the crypto co-processor sends a random number to the main processor. The main processor encrypts it with the established key. And this thing is then verified by the crypto chip. If all is well, the next stage happens.
A secure channel opens, session keys are brought up. And, essentially, the rest of the data we see as just garbage for us and some information underneath it, meant for the processor. At first glance this scheme looks fairly protected, but let's try to look for weak spots in it. So, essentially, this is the native option. We solder in, watch the exchange, try to find something. But even if we sneaked a look at the challenge, after the secure channel came up, we see garbage.
Accordingly, we need not just to see the packet exchange, but also to somehow wedge into controlling it.
Accordingly, if we can't observe it, let's try to desolder the processor somewhere, control the power, and try to go down this path. But here this option doesn't suit us, because we don't know the encryption key. Let's call it that, though there are session keys too.
Accordingly, we have to learn to control the main processor, to somehow get to the data. Okay, right now we're looking at it in theory. Suppose we intercepted control of the processor. Good, we control the processor. Somehow, let's say, we found the key in the processor and repeated the exchange over SPI. Accordingly, we have the key. But the next problem is supplying power to the crypto-processor. You can feed it head-on, bypassing everything, by soldering on some wires. But we might fry something.
So we'll have to deal with this problem inside the processor too. Well, let's say we solved that one too. Then here we can already, by taking apart the transaction, knowing the session keys, look at Knox. knox_nonce. And by adding it, this missing link, to the previous scheme, offload the brute force to an external computer. So here we have GPU power, CPU power, and clusters, so here we're already working at full scale.
In principle, this process turns out to be pretty high-level, but it has its vulnerabilities and the attack can be carried out.
Galaxy A06 on MTK: the crypto chip as a gatekeeper, brute force only on the phone
Now let's move on to the next phone, the Samsung Galaxy A06. Here the difference isn't just that it's controlled over the I2C bus. You can look at the I2C bus, and I'll say even more. We'll see the exchange. It isn't encrypted here. Let's say the trick here is something else entirely. Roughly speaking, it's in forming what's called the key space.
If in the first case we only needed, let's call it, a secret blob, and we calmly offload the brute force outside. Here the crypto-processor is directly involved in checking the password. And a so-called Weaver file appears in our folder. So let's call it, for ourselves, the Weaver logic.
And let's look at how our key retrieval scheme has changed. That is, here we've added weaver_info. Well, basically it's lying in the folder under your feet, you can look at it, there's nothing interesting there. What's interesting here is forming the key for the file system. In fact, only a hash is passed to the CryptoMCU, and this crypto-processor, the crypto-chip, is a gatekeeper. So it sits there and says: aha, right, I know this hash.
So, here are your keys, go work. If the hash doesn't match the crypto-chip's expectations, it says: well, go away, you won't get the keys until you show the correct hash. So, accordingly, problems can arise here. That is, we can't offload the brute force outside the phone. So here the CryptoMCU can count the number of attempts internally. It has internal memory, so it can add up, sum these attempts. Then it has its own timers inside, it can slow down the response — which is what we run into. You enter 10 passwords, then wait a minute. And so on.
And so, theoretically, it can then tell the program: that's it, a thousand attempts, I'm clearly being cracked, I'm wiping it all. Actually, you don't need much computing power for that, it's enough to just implement a memcpy function, that is, comparing memory, matches, doesn't match, and a simple counter, and we get a whole pile of problems. There's no way we can offload this.
So, let's sum up once more what this gives us… And, essentially, why it's so hard to take apart, so hard to implement. That is, here we run into a fundamental difficulty. For us, the crypto-chip is a black box. We don't know what's inside. And the data is stored in it, the key itself. That is, it can be arbitrary, it isn't tied to the hash or to anything. Only the crypto-chip itself knows it.
Again, the whole authorization doesn't come down to getting some blob, and we can't offload it outside. An attempt counter can also appear, and errors can also be logged. That is, in fact, we can lose the data if it's handled wrong.
This is a short slide. If we just need to pull a blob out of the crypto-chip and add it to the chain, then in that case we can do something. If the password check and getting the final key happen directly inside the crypto-chip, then here we fundamentally can't do anything at the moment.
Q&A
So, basically I'm done. If there are any questions, I'm ready to hear them. Thank you very much, colleagues. Your questions by raised hand. Right, I see one in that section. Valeria Mikhailovna, I'll ask you to go there. Alexey, sit over there for now.
— Good afternoon. Let me ask a question, it's related directly to the formulas that, let's say, you presented symbolically. That is, certain operations, root of trust, for forming the key. Was this obtained empirically or from analyzing the CryptoMCU docs? This is part of the CryptoMCU documentation. Part of it is, let's say, our own learning, our research. It's a small piece of generalized information. How the keys are structured.
— In principle, this information is in open sources too. Well, maybe somewhere it's less complete, somewhere it's called differently. Since internally, let's say, within the team we formed our own names, so there's no fixed terminology anywhere here. Here a lot of people call these things whatever.
— Colleagues, any more questions? Alexey, go ahead.
— Vyacheslav, you said that's how things stand at the moment. Are any prospects expected?
— Well, most likely, if there's anything, it will all be brute-forced not on external hardware, but on the phone itself. But again, this needs separate research. Who resets, who doesn't reset the processor's state, how many times you can safely try. Maybe there will be some, but that's a completely different direction. Maybe, again, the firmware of this crypto-processor leaks somewhere, somewhere something gets clearer.
Everything moves, everything changes, the battle of shield and sword will always be there. Thank you. Colleagues, any more questions? Valeria.
— Vyacheslav, hello. My question was also exactly about key formation. You paid separate attention to whether the phone is locked or unlocked, and you said that depending, specifically on that state, the data can be destroyed if, for example, it's unlocked. Can you explain in a bit more detail what you meant? Yes, so it turns out we have a key, but let's not consider it now with the check in the crypto-chip, let's take the general case, and let's even drop the crypto-chips, it's just an auth blob, so forming the key involves the so-called phone state, that's color and is_locked.
That's the state. What is is_locked? Basically, is the bootloader unlocked or locked. Color is the phone state, that is, first it takes into account whether the bootloader is unlocked, and, I think, whether boot is swapped or not swapped, and some other files, I can't recall them right now, it's not something you hit that often. In short, it depends on the firmware state, if I generalize. That is, unlocked or locked, firmware original or not original, signed or not signed, signed with the maker's key or a different key, and all these states affect the key.
So if we changed the key, the data, let's say, if we don't reflash the phone too much, don't do anything, just accidentally installed the wrong firmware, well, there's a chance to recover the data. Roughly speaking, if we go this deep, not with the phone's own tools, but copied the data and try to work through this chain, there's a chance. But again, this is no longer the phone's own tools. So with the phone's own means, if we reflashed it or unlocked, locked it, that's it, we've lost the data for that phone.
Thank you. Colleagues, any more questions? Yes, please. Sorry, following up on the answer to the previous question, so if we, in the case where we saved the data, could we later restore it back onto the phone? Well, if we saved the data and we have the phone's unique identity, that is, the phone is in our hands, so the phone absolutely has to be there and there has to be a backup. And then, during reflashing, if something the phone doesn't like, it does a so-called wipe, meaning it erases it all. So that's a matter of luck. If we pulled the battery in time, noticed it, fine, but with live phones it's better not to do that.
— Colleagues, are there any more questions? I see a hand.
— Thank you for the talk. My question follows on from the previous one. Does it physically erase the data, or is it just that because the parameters change, the final keys change, and it can't decrypt them? Yes, that's right. At first it just changes the key, we can't decrypt them. And later on, if it actually boots up, there are internal processes in the phone, self-recovery, all sorts of other things, it's a whole world in there. And those processes may already overwrite the data. Got it, thank you.
I'd like to ask you a provocative question, as a Samsung user. Over here. What stops you from breaking the latest expensive models, the Knox folder, which, by the way, I use quite a lot? Well, models on which processors? On MediaTek, or on Kirin, or in general? Well, in general. In general? On Knox in general I can't say. What is Knox on Samsung, in fact? It's just a separate space. So there's space 0 and space 1. It's an independent space. And the problem is getting the key to that space.
So what exactly is the difficulty in getting the key to that space? Because we all remember the situation when, many years ago, the National Security Agency asked Apple to break into a phone. Apple, of course, refused. They broke it themselves. But then GrayKey appeared, out of nowhere.
— But that's a different matter. The thing is, I talk to Samsung, Samsung reps, and they claim almost 100% security for this Knox folder. Well, let's say, on devices that were on MTK and that are supported, Knox can basically be taken apart there. As for modern Exynos, I can't say. Our company basically doesn't work with Exynos.
— Alright, I wish you progress in that direction, because, as we all understand, the new models now also have AI built in, and I think they'll build AI into the phone's security too, and we all know AI can be used both for good and for bad. That's all, thank you very much. Dima, I have a question over here. Please. The question is basically about the prospect posed by phones evolving, when not only charging but also data transfer will eventually be wireless. And the absence of data transfer interfaces on mobile devices will become the basic standard for new model releases.
My question to you. Since you work more with the approach of accessing the system board and extracting information, what prospects do you see going forward for extracting data from devices that will have no data transfer interfaces at all? Apart from the fact that, the only thing left is to unlock the phone the natural way, by picking the password from other devices in the incident or the case.
And the usual photo and video capture of correspondence and recording of criminally relevant information. How do you see data extraction going forward from devices with no data interface, in short? Okay, interesting question. A bit philosophical. Let's try to, a little... Let's philosophize a bit. So, in the current situation, in any case, any device has to boot somehow. It has to be flashed somehow. All of that, I mean it's impossible at this stage, and not soon, I think, I mean it's impossible to flash memory over the air. There will still be some conductors, some circuits in there. You'll be able to get into that circuit, make changes, take a peek.
So, well, the task will get harder. Still, I think at some level there will be wires, you may have to disassemble, solder on, whatever it takes. Here I see the problem not so much in wired interfaces as in the pace of development. In general, how much attention manufacturers pay to security, how critical it's becoming.
— Well, since, let's say, our May conference up to today, as I said, for MTK in that time, what is it, 2 or 3 months, let's even say 4. Still, in that time two significant security patches came out. That's just for MTK, and that's not the most serious manufacturer. So, essentially, that pace is far scarier than wireless interfaces.
Vyacheslav, thank you very much. Let's send him off with a round of applause. Please leave the clicker on the table. Thank you very much.