There are a lot of arguments against remote attestation but I’d like to focus on one with respect to your use case: it does not give useful guarantees for security in this model.
Remote attestation is great for simple embedded devices wanting to connect to a server, to ensure that the server is talking to only trusted endpoints. It’s great in this use case because the code on the client devices that you need to verify is largely stateless, so compromises struggle to persist, and the total amount of code is small. It’s not perfect, but it adds some defence in depth, especially when coupled with a bootloader with anti-rollback protection.
Remote attestation is absolutely essential for confidential cloud computing to attest to the first stage loader in a pristine confidential VM so that you know that you have an isolated VM to boot your OS into and that the bootloader will boot only the thing that you have authorised it to boot.
Remote attestation of applications on general-purpose devices is absolutely snake oil for security. It tells you that the application is running on top of a few tens of millions of lines of privileged C code and if that code is 100% bug free then you have some properties about the application.
Remote attestation builds on the same ideas as secure boot. Each layer starts in a known-safe state and then loads the next layer. Each layer is then able to attest to the initial state of the next layer and depends on an indicative security proof to assume that, if the initial state was secure, the next stage is also secure.
When you’re talking about something like the first EFI loader, you get some reasonable claims. It typically has a tiny attack surface (though some support network booting protocols) and is a small amount of code. It has to do some early initialisation and then read another loader into memory, read its cryptographic signature, verify the signature against an allowed set of public keys, and jump to it. If it’s a trusted version then it’s probably still trustworthy. It may load a larger second-stage loader that has a richer UI and can do things like network boot a recovery image.
You probably can still make meaningful claims about this second-stage loader. It may even be a full OS, but it’s running a smaller set of programs, a limited set of drivers, and has a smaller attack surface. It does the same kind of signature verification as the first stage, but this time for an OS image (possibly a kernel, possibly a kernel plus loadable modules, possibly an initial immutable root filesystem).
Now the OS boots. It’s running millions of lines of C in privileged mode. It spawns a bunch of services that have sufficient privilege that they could do a lot of damage if compromised. It exposes attack surface to userspace, to every network interface, to any bus. It runs for days at a time (possibly weeks or months) accumulating state that may allow an attacker to seed the ground for an attack. Knowing the initial state of this tells you absolutely nothing about the current security posture of a system.
It then runs a program and provides an attestation quote related to the state of the system when the program was started. Everything in that quote that comes after the kernel boot is true if and only if the kernel has not been compromised[1].
The kernel is responsible for enforcing process isolation. Any attacker that has the ability to tamper with the state of the attested process from another process also has the ability to tamper with the attestation state. One requires a kernel privilege-elevation vulnerability, the other requires a kernel privilege-elevation vulnerability.
So the thing that an application-level attestation quote tells you is that either the application is running unmolested, or an attacker has compromised the kernel and has the ability to compromise the application. This is not a useful security property (it’s also roughly the property that you can assume withoutdoing remote attestation).
It’s actually somewhat worse than this because all of the machinery to be able to do remote attestation adds a lot of code that runs in one of the most privileged environments of the system. So the mere fact that a system can do remote attestation at this level in the stack means that it has a larger TCB and a larger attack surface than one that can’t. So you’re asking OS vendors to intentionally weaken the security of their systems to get a meaningless security claim.
You would get far better security by having some additional path that required them to confirm any large transactions via a separate device.
Fortunately, the security of most banks doesn’t depend on any of this nonsense. It depends on having legally mandated undo functionality, so transactions that were initiated by a compromised device can be rolled back. As long as users are notified of transactions rapidly (within the rollback window), you have the security that you need without building a house of cards stuck together with snake oil.
[1] Some of these things use hypervisor extensions and have a hypervisor make claims about the state of the kernel[2]. That doesn’t really add much work factor for the attacker because kernels are so big that code-reuse attacks are trivial.
[2] Note that things like Windows’ virtualisation-based enclaves are quite different here. Hyper-V has a good security track record and a secure boot chain to Hyper-V gives you some useful properties. Hyper-V can usefully attest that a micro VM is secure and can then do things like emulate a smart card there (rather than a full OS). The problem is that all of the I/O goes via the untrusted layer, so you can’t really depend on it for any user-initiated action.
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.
There are a lot of arguments against remote attestation but I’d like to focus on one with respect to your use case: it does not give useful guarantees for security in this model.
Remote attestation is great for simple embedded devices wanting to connect to a server, to ensure that the server is talking to only trusted endpoints. It’s great in this use case because the code on the client devices that you need to verify is largely stateless, so compromises struggle to persist, and the total amount of code is small. It’s not perfect, but it adds some defence in depth, especially when coupled with a bootloader with anti-rollback protection.
Remote attestation is absolutely essential for confidential cloud computing to attest to the first stage loader in a pristine confidential VM so that you know that you have an isolated VM to boot your OS into and that the bootloader will boot only the thing that you have authorised it to boot.
Remote attestation of applications on general-purpose devices is absolutely snake oil for security. It tells you that the application is running on top of a few tens of millions of lines of privileged C code and if that code is 100% bug free then you have some properties about the application.
Remote attestation builds on the same ideas as secure boot. Each layer starts in a known-safe state and then loads the next layer. Each layer is then able to attest to the initial state of the next layer and depends on an indicative security proof to assume that, if the initial state was secure, the next stage is also secure.
When you’re talking about something like the first EFI loader, you get some reasonable claims. It typically has a tiny attack surface (though some support network booting protocols) and is a small amount of code. It has to do some early initialisation and then read another loader into memory, read its cryptographic signature, verify the signature against an allowed set of public keys, and jump to it. If it’s a trusted version then it’s probably still trustworthy. It may load a larger second-stage loader that has a richer UI and can do things like network boot a recovery image.
You probably can still make meaningful claims about this second-stage loader. It may even be a full OS, but it’s running a smaller set of programs, a limited set of drivers, and has a smaller attack surface. It does the same kind of signature verification as the first stage, but this time for an OS image (possibly a kernel, possibly a kernel plus loadable modules, possibly an initial immutable root filesystem).
Now the OS boots. It’s running millions of lines of C in privileged mode. It spawns a bunch of services that have sufficient privilege that they could do a lot of damage if compromised. It exposes attack surface to userspace, to every network interface, to any bus. It runs for days at a time (possibly weeks or months) accumulating state that may allow an attacker to seed the ground for an attack. Knowing the initial state of this tells you absolutely nothing about the current security posture of a system.
It then runs a program and provides an attestation quote related to the state of the system when the program was started. Everything in that quote that comes after the kernel boot is true if and only if the kernel has not been compromised[1].
The kernel is responsible for enforcing process isolation. Any attacker that has the ability to tamper with the state of the attested process from another process also has the ability to tamper with the attestation state. One requires a kernel privilege-elevation vulnerability, the other requires a kernel privilege-elevation vulnerability.
So the thing that an application-level attestation quote tells you is that either the application is running unmolested, or an attacker has compromised the kernel and has the ability to compromise the application. This is not a useful security property (it’s also roughly the property that you can assume withoutdoing remote attestation).
It’s actually somewhat worse than this because all of the machinery to be able to do remote attestation adds a lot of code that runs in one of the most privileged environments of the system. So the mere fact that a system can do remote attestation at this level in the stack means that it has a larger TCB and a larger attack surface than one that can’t. So you’re asking OS vendors to intentionally weaken the security of their systems to get a meaningless security claim.
You would get far better security by having some additional path that required them to confirm any large transactions via a separate device.
Fortunately, the security of most banks doesn’t depend on any of this nonsense. It depends on having legally mandated undo functionality, so transactions that were initiated by a compromised device can be rolled back. As long as users are notified of transactions rapidly (within the rollback window), you have the security that you need without building a house of cards stuck together with snake oil.
[1] Some of these things use hypervisor extensions and have a hypervisor make claims about the state of the kernel[2]. That doesn’t really add much work factor for the attacker because kernels are so big that code-reuse attacks are trivial.
[2] Note that things like Windows’ virtualisation-based enclaves are quite different here. Hyper-V has a good security track record and a secure boot chain to Hyper-V gives you some useful properties. Hyper-V can usefully attest that a micro VM is secure and can then do things like emulate a smart card there (rather than a full OS). The problem is that all of the I/O goes via the untrusted layer, so you can’t really depend on it for any user-initiated action.
score 1 · canonical
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