It is a common misconception among computer security people, who are used to being able to get absolute security guarantees within some threat mode, that the purpose of remote attestation is similarly to get absolute guarantees. But that’s not the point here. As I said:
Of course attestation does not make any of these bad behaviors impossible. But there is still benefit in making them more expensive, which it does.
You are missing the point in your rush to be patronising.
The common problem among people who are not computer security is not having a proper threat model and therefore not evaluating your security theatre against any plausible attack.
Any attack that can compromise the integrity of a running app on a platform like Android or iOS can also compromise the integrity of the attestation. It gives you a nice warm fuzzy feeling and absolutely nothing else. Any system that is sufficiently compromised that the attestation would fail for a reason that will affect your app is also sufficiently compromised that the attacker can compromise the attestation.
It does not make attacks noticeably harder but, since you’re going to be patronising about security people here’s a bit more explanation:
We think of mitigations in two categories: durable and non-durable.
Durable mitigations completely eliminate the root cause of a vulnerability class. If they can be made to work within an acceptable cost, they are always worth it. They don’t prevent attacks but they mean that you don’t need to consider a particular attack vector.
Non-durable mitigations add work factor or block a particular exploit technique. They don’t prevent a vulnerability class, they just make it a bit harder. In the early 2000s, people rolled out a load of these because they did increase work factor. The problem is that newer exploit techniques work around them and are automated. Most exploits today are mostly, if not completely, automated. A mitigation that can be bypassed by an automated step in an attack chain does not make it less likely that an attacker will succeed.
At the same time they’re politically impossible to remove. If you remove them, and an attack succeeds that they would have blocked, that’s terrible PR even if there is a trivially automatic step that would have allowed the attacker to succeed with a slightly different attack. And this means that you’re stuck paying the performance and complexity costs basically forever.
And that’s when we security folks that you love to patronise do a little thing called a ‘cost-benefit analysis’. If you work for a bank, you might have heard of these. I’m told banks do them as well.
We look at these non-durable mitigations and decide whether the attacks that they will prevent (relative to a threat model, where we look at the different possible abilities of an attacker and how they could do the thing that we’re trying to stop them doing) and weigh that against the cost of supporting the mitigation for an unbounded amount of time. And, when the mitigation requires a lot of complexity in the most privileged parts of a system, we weigh those very carefully.
And, in the case of app-level remote attestation, we conclude that it’s a large amount of code in the TCB, it’s increased attack surface, and it can be bypassed by any attacker who has the ability to do the thing that it’s trying to prevent.
And then we tell you not to waste time on it.
Not because, as you imply, we’re complete muppets, but because we’ve actually thought through the cost of the complexity involved and concluded that the hypothetical (and small) increase in difficulty for attackers is not worth it.
Note that companies like Apple and Google will see the cost-benefit calculations differently because ‘users of this banking app are tied into either an Apple or Google ecosystem’ is a very large benefit. But that’s a monopolistic market positioning benefit, not a security benefit.
Any attack that can compromise the integrity of a running app on a platform like Android or iOS can also compromise the integrity of the attestation.
This is straightforwardly false. That is the whole point of attestation. If you have an exploit for reasonably up-to-date iOS or Android then you don’t need to compromise the integrity of the attestation, sure. (You still can’t; but you don’t need to.) But if you’re exploiting out-of-date or unlocked devices, you can’t fake the attestation to claim that device is up to date or locked (unless the TEE itself is compromised, which is very unusual), which is why mobile banking apps can and do refuse to run in these cases.
Yes, sometimes OEM keys get leaked, but those get revoked very quickly if they’re actively being used; and yes, it is possible to have a farm of devices relaying fresh attestations that you sub in, but this is expensive and also the bank can see that the attestation comes from a device you weren’t previously using.
(In any case, I didn’t work at a bank, but I worked with a lot of banks, and concretely remote attestation did significantly and persistently decrease the amount of account takeovers they were seeing, especially in certain markets. It’s not hypothetical at all.)
Did you check to whom you’re replying? (Look at who is on the coauthors…) My understanding of attestation is identical to yours; but, now I’m left wanting to know how I’m confused.
It is a common misconception among computer security people, who are used to being able to get absolute security guarantees within some threat mode, that the purpose of remote attestation is similarly to get absolute guarantees. But that’s not the point here. As I said:
score 1 · canonical
You are missing the point in your rush to be patronising.
The common problem among people who are not computer security is not having a proper threat model and therefore not evaluating your security theatre against any plausible attack.
Any attack that can compromise the integrity of a running app on a platform like Android or iOS can also compromise the integrity of the attestation. It gives you a nice warm fuzzy feeling and absolutely nothing else. Any system that is sufficiently compromised that the attestation would fail for a reason that will affect your app is also sufficiently compromised that the attacker can compromise the attestation.
It does not make attacks noticeably harder but, since you’re going to be patronising about security people here’s a bit more explanation:
We think of mitigations in two categories: durable and non-durable.
Durable mitigations completely eliminate the root cause of a vulnerability class. If they can be made to work within an acceptable cost, they are always worth it. They don’t prevent attacks but they mean that you don’t need to consider a particular attack vector.
Non-durable mitigations add work factor or block a particular exploit technique. They don’t prevent a vulnerability class, they just make it a bit harder. In the early 2000s, people rolled out a load of these because they did increase work factor. The problem is that newer exploit techniques work around them and are automated. Most exploits today are mostly, if not completely, automated. A mitigation that can be bypassed by an automated step in an attack chain does not make it less likely that an attacker will succeed.
At the same time they’re politically impossible to remove. If you remove them, and an attack succeeds that they would have blocked, that’s terrible PR even if there is a trivially automatic step that would have allowed the attacker to succeed with a slightly different attack. And this means that you’re stuck paying the performance and complexity costs basically forever.
And that’s when we security folks that you love to patronise do a little thing called a ‘cost-benefit analysis’. If you work for a bank, you might have heard of these. I’m told banks do them as well.
We look at these non-durable mitigations and decide whether the attacks that they will prevent (relative to a threat model, where we look at the different possible abilities of an attacker and how they could do the thing that we’re trying to stop them doing) and weigh that against the cost of supporting the mitigation for an unbounded amount of time. And, when the mitigation requires a lot of complexity in the most privileged parts of a system, we weigh those very carefully.
And, in the case of app-level remote attestation, we conclude that it’s a large amount of code in the TCB, it’s increased attack surface, and it can be bypassed by any attacker who has the ability to do the thing that it’s trying to prevent.
And then we tell you not to waste time on it.
Not because, as you imply, we’re complete muppets, but because we’ve actually thought through the cost of the complexity involved and concluded that the hypothetical (and small) increase in difficulty for attackers is not worth it.
Note that companies like Apple and Google will see the cost-benefit calculations differently because ‘users of this banking app are tied into either an Apple or Google ecosystem’ is a very large benefit. But that’s a monopolistic market positioning benefit, not a security benefit.
score 1 · canonical
One of us is very confused.
This is straightforwardly false. That is the whole point of attestation. If you have an exploit for reasonably up-to-date iOS or Android then you don’t need to compromise the integrity of the attestation, sure. (You still can’t; but you don’t need to.) But if you’re exploiting out-of-date or unlocked devices, you can’t fake the attestation to claim that device is up to date or locked (unless the TEE itself is compromised, which is very unusual), which is why mobile banking apps can and do refuse to run in these cases.
Yes, sometimes OEM keys get leaked, but those get revoked very quickly if they’re actively being used; and yes, it is possible to have a farm of devices relaying fresh attestations that you sub in, but this is expensive and also the bank can see that the attestation comes from a device you weren’t previously using.
(In any case, I didn’t work at a bank, but I worked with a lot of banks, and concretely remote attestation did significantly and persistently decrease the amount of account takeovers they were seeing, especially in certain markets. It’s not hypothetical at all.)
score 1 · canonical
Did you check to whom you’re replying? (Look at who is on the coauthors…) My understanding of attestation is identical to yours; but, now I’m left wanting to know how I’m confused.
score 1 · canonical