lobsters score: 4 · tags: culture, security
One thing I don’t see discussed is that there is a simple solution to keeping remote attestation while making it a security feature for the user instead of a DRM mechanism.
Owner override. The industry refused it when it was suggested over 20 years ago, they should be forced to implement it.
Another solution would be to ban the inclusion of a vendor EK, in that way turning the system into trust on first use. It would prevent tampering with an existing properly set up device, but it would allow the user to lie when signing up (for example for a banking app if the bank thinks your OS is not corporate enough).
In both cases this needs to be a legal ban, because even though protests managed to stop the initial full rollout of TC on PCs and WEI, once people forget it is way too lucrative for corporations to not try again slowly.
score 1 · canonical
This then begs the question: Security for who? It’s definitely not for the user, as they are locked out of their device. Their security and autonomy have been harmed significantly.
The article argues against using the label “security” for remote attestation. I think it’s pretty much right in its criticisms, but it’s not complete:
A horrifyingly common attack addressed by remote attestation is that an attacker calls the user and claims their device is already hacked, but the attacker will helpfully walk the user through sideloading an app to “fix” it. The malicious sideloaded app either breaks out of its app sandbox or uses disability assistance features to steal auth credentials to banking apps.
Another is stalkerware, where an attacker sideloads software to surveil their victim, often a family member or intimate partner.
Another is apps with intrusive permissions. Nowadays the review practices of the app gatekeepers do a reasonably good job of preventing apps from requesting overbroad permissions, like a flashlight app that accesses the user’s contacts. These aren’t all obvious BS: every banking app could truthfully argue that always-on precise location tracking would help them reduce fraud. (And of course give them a lucrative product line selling that data.)
A variation on the previous is coercion. Employers and governments force people to sideload similarly intrusive apps, especially marginalized people with reduced autonomy like the poor and those crossing borders. RA is a kind of commitment device.
Remote attestation does have real security value along with its problems because sometimes the user is part of subverting their own security. Like everything in security, it’s a tradeoff. I think it’d be great to see an article that addressed why these protections aren’t worth the downsides.
score 1 · canonical
The malicious sideloaded app either breaks out of its app sandbox or uses disability assistance features to steal auth credentials to banking apps.
Remote attestation as it presently exists does not address these threats. Remote attestation only attests that the device booted normally, i.e. that you’re running stock firmware. It does make persistent “bootkit” malware harder, but it does absolutely nothing to stop a malicious app from LPEing (and if you set up the right accessibility hooks then it can re-pwn you on every boot, after the clean boot state has been measured).
The threat it would actually mitigate is someone being SE’d into unlocking their bootloader and flashing a backdoored firmware image.
score 1 · canonical
I think it’d be great to see an article that addressed why these protections aren’t worth the downsides.
I don’t disagree with your analysis. But I don’t it’s just a risk/reward calculation, either, because there’s a deeper value at stake. I think computers have practically and psychologically become “part of the self” in many ways. And just as you cannot, even if someone is willing, legally buy a slave, I don’t think remote attestation should even be legal.
The case for “surveillance”, broadly writ, is similar. There are good things that can come of it, like crime prevention. Still, most people have the (imo correct) instinct that something much more important, something incalculable, is being lost.
score 1 · canonical
deleted by creator
deleted by creator
…and of course the user can also make mistakes, like visit a typosquatted site or install a lookalike malicious app.
score 1 · canonical
The more common scam is simply calling someone up and asking them to transfer money to their “son” or “mother” who urgently needs it for some reason.
Remote attestation doesn’t solve the common case.
Having walked non-technical family through how to restore computers, the attacks via walking the user through replacing their OS with a backdoored one seem very implausible: they simply won’t understand the instructions, and each attack will take hours of 1 on 1 technical hand-holding. This would include steps where they’re rebooting the device and calling you back. The cost of the attack is simply too high compared to convincing them to use the well attested credentials on your behalf.
Attestation is weak defense against high cost attacks, but it does a good job of locking users into big tech.
There’s one place where attestation helps: if you’re a high value target, and don’t trust the security of your own installed os (eg, you’re in a journalist in jurisdiction that mandates encryption backdoors), you could ensure you are running an OS that hasn’t gotten backdoored when, eg, you hand the phone over for inspection by the police. But in this scenario where you’re a very high value target for a state actor, vendors are part of the threat model, so the remote attestation provided by current systems isn’t enough; you need to be able to enroll your own keys to ensure that the OS you’re running is the one you chose to install. None of the current remote attestation solutions allow users to ensure that they’re running the right custom, third-party build, and that the vendor can’t force an update.
score 2 · canonical
Having walked non-technical family through how to restore computers, the attacks via walking the user through replacing their OS with a backdoored one seem very implausible: they simply won’t understand the instructions, and each attack will take hours of 1 on 1 technical hand-holding. This would include steps where they’re rebooting the device and calling you back. The cost of the attack is simply too high compared to convincing them to use the well attested credentials on your behalf.
There are teams in call centres in less developed countries that follow scripts honed through thousands of interactions. Simply put: the bad guys are experts in 1:1 technical hand-holding.
As an aside, at my old job, we ran the numbers on how much fraud attestation turned up. We did the same for rooted devices. Turns out the checks weren’t worth it. You know what was worth it? Flagging if a customer’s touchStart -> touchEnd events were superhumanly quick.
score 1 · canonical
I worked in anti-fraud. I’ve heard this argument many times, and I’m sympathetic, but I wish people making it would engage with the counter-arguments, so I’ll try restating them.
Since this is making a purely principled case, I’ll start with a principled objection:
Our personal devices are in a very real sense extensions to our body, which means that bodily autonomy should in some way extend to them.
Yes, that’s a reasonable analogy. And just like with our bodies, that autonomy extends to the freedom to make binding pledges to avoid certain kinds of behavior in our interactions with others, because there are desirable things which simply cannot happen in the absence of such a pledge. Many sports require you to agree to avoid the use of steroids, sometimes as confirmed by urine or blood tests, even though this is most certainly a restriction of your bodily autonomy; similarly many events are sober, where as a condition of entry you agree not to do drugs before or during. We can contract to do jobs (such as doctors, therapists, military planners, etc) where we are going to obtain information that should not be shared, and this works only because we can make binding pledges not to reveal that information later.
So, yes, you should be able to run whatever software you like on devices you own. But you should also be able to promise, and demonstrate, that you are not running certain software, in order to participate in certain shared activities (such as competitive games, banking, etc). Having the ability to make this pledge is not a restriction of your freedom any more than the existence of tests for steroids in competitive sports is a restriction of your freedom.
So that’s the principled objection. But there’s a practical one as well: attestation has significant concrete benefits for users, contra this post. Lots of people have lost their life savings because someone talked them into sideloading a malicious app and then drained their bank account. The only two kinds of popular competitive online games are those with attestation and those overrun by cheating. Attestation is why your bank is willing to let you put your card on your phone (for fraud/liability reasons they don’t like to issue tap-to-pay cards that can be trivially cloned, which means they need your phone to verifiably keep the cards somewhere they can’t easily be copied). If a website’s login form can be brute-forced by anyone with a subscription to a residential proxy and the latest password dump, you’d best hope it doesn’t have anything valuable behind it.
(Why do we still have login forms, then? As I said, I worked in this space, so I can tell you: it’s captchas, behavioral analysis, and fingerprinting. That’s it. Captchas were already a joke before LLMs trivialized them, behavioral analysis has either unacceptably high false positives or >20% false negatives, and everyone hates fingerprinting plus browsers are trying to kill it off, which leaves us with… well, either nothing or remote attestation.)
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. And these benefits are very broadly popular, whereas the restriction to our autonomy is felt mostly by highly technical people. “I demand to be able to participate in all these activities without attestation; it’s your job to figure out how to deal with fraud/etc without it” is a nicely principled stand but you have no power to enforce it and your bank/etc have little reason to allow this. If you want to convince the world to give up attestation, you’re going to need to provide some alternative way of achieving its benefits.
score 1 · canonical
I worked in anti-fraud.
First off: so did I. So I’ve upvoted you in solidarity. I’ve struggled to explain fraud / risk to anyone not in it. That there are Very Professional Multinational Organisations that have job boards, good benefits, call centres, and customer service all in service to commit crime? 😮💨 Moreover, fraudsters often know how financial organisation’s antifraud systems better than the financial organisations in question! ugh… I’ve derailed.
A couple things:
- AFAIK attestation has little to do with tap-to-pay. (Apple|Google) Pay both use the Secure Element to prevent things like cloning. The Application Processor is mostly untrusted here.
- I strongly suspect you’re underestimating the effectiveness of behavioural analysis and overestimating the effectiveness of attestation. My former employer was like Target #1 in this regard.
But, yes, I tend to agree there is a degree of If Your Bank Won’t Serve You Because You Don’t Want To Wear Clean Clothes, Switch Banks.
score 1 · canonical
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:
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.
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.
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.)
score 1 · canonical
One of us is very confused.
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
So, yes, you should be able to run whatever software you like on devices you own. But you should also be able to promise, and demonstrate, that you are not running certain software, in order to participate in certain shared activities (such as competitive games, banking, etc). Having the ability to make this pledge is not a restriction of your freedom any more than the existence of tests for steroids in competitive sports is a restriction of your freedom.
So then if I’m a journalist/whistleblower/human rights activist and I want to use an OS like GrapheneOS for privacy, should I be allowed to do so? Or not? Or should I be allowed to install it, but if so not be allowed to do basic things like banking?
score 1 · canonical
You should be allowed to use any operating system you choose, and your bank should be allowed to decline to provide mobile banking services on operating systems it doesn’t trust.
score 1 · canonical
But if all the banks decide to just use remote attestation, you in practice can’t use any other OS except Google’s Android or iOS. So you are essentially saying that users shouldn’t have a choice.
It leads to a chicken and egg problem, because banks will only support platforms with many users and users will only use platforms with banking support, so we end up further cementing a duopoly which is a real problem.
score 1 · canonical
That’s the crux of the matter. We are the customer and customer is supposed to be king, but not when it comes to banks. They have such a special position in society that we’re effectively subject to their whims. And it gets really bad when their whims further entrench an existing and highly undesirable lock-in duopoly.
score 2 · canonical
It’s not just banks, either. Employers and landlords might require you use specific apps on specific OSes. Really you’re locked in for anything where you have a choice between parties to contract with in a category, but you must contract with a party in that category, and all parties have aligned their policies due to regulation, cartelization, or simple groupthink.
score 1 · canonical
In my country it’s common with car parking apps as well. Almost one app for each parking…
score 2 · canonical
Banking is not a shared activity. The bank is holding onto my money on my behalf, and it’s their job to do what I ask with it.
When I can hold onto the bank’s money and make arbitrary demands from them before they get it back, the same way they do with my money, then we can say it’s a shared activity.
score 4 · canonical
… Banking is definitely a shared activity. The bank is a different entity than you. You are doing this activity together. What?
score 2 · canonical
They are my delegate when it comes to managing my money, not my peer – a shared activity, to me, implies a roughly equal amount of agency and power on both sides.
score 1 · canonical
Ah. Well, that’s not how I intended it to be read. Read “multi-party” instead of “shared”, then.
(This is a side point, but no, they’re not your delegate. It’s not even your money anymore; the bank is just your debtor. Banks have always placed restrictions on what you can do with your balance, including placing controls on withdrawals, many required by law. You can find entities for whom this is less true, but they’re regulated differently and more expensive. That’s not the relationship you signed up for.)
score 1 · canonical
If banks are allowed to arbitrarily decide they don’t need to make good on their debts to me because they’re involved in those debts, that’s a very strong argument that the laws around this are broken.
score 1 · canonical
They are not allowed to decide they don’t need to make good on their debt, but that isn’t the topic of discussion here. They are allowed and in fact required to have a variety of controls on the manner and mechanisms with which they discharge said debt, and pretty much everyone is in favor of this, broadly construed. You just don’t like this particular control.
score 1 · canonical
This is not a required control, at least in many jurisdictions.
It’s also a particularly onerous control, making it effectively impossible to use hardware not under the control of American cartels. If the USA were to behave poorly on the international stage (inconceivable, I’m sure), this may cause problems for people outside of the USA. This seems rather unwise from a digital sovereignty perspective.
Edit, also:
They are not allowed to decide they don’t need to make good on their debt
If they’re allowed to impose arbitrary barriers, they can dodge making good on their debt indefinitely, which is approximately equivalent.
score 1 · canonical
extends to the freedom to make binding pledges to avoid certain kinds of behavior in our interactions with others
Banking is not a shared activity.
Banking is a business activity, regulated as much as or more than any other, which means that the current apparatus should be free to exert even more control for the benefit of society.
It seems wholly reasonable to me to suggest that a bank that has been granted the ability to operate broadly should be held to certain requirements, such as… there should be enough branch locations with reasonable staffing and hours of operation so that people are not forced to use a device to perform basic, routine transactions.
If there were the case, perhaps we might be less anxious about the dubious benefits of attestation if all it meant was a minor inconvenience?
Instead, I think the worry about these kinds of technologies is that it is inevitably accompanied by an overall worsening of customer service and customer choice. It’s not only that you are forced to use certain devices in a certain way, you are forced to only be able to operate through that means to survive the demands of modern life.
Setting aside the dubiousness of these security approaches and the outright carelessness of their implementation, I think they are often objectionable just in their outright indifference to providing good customer service…
score 2 · canonical