I am reading more about Free / open source alternatives to Google's Play Integrity tooling, sometimes called "attestation".
-
@teezeh Yes, mobile devices (phones, tablets etc) are computers.
-
I am reading more about Free / open source alternatives to Google's Play Integrity tooling, sometimes called "attestation".
It is the ability for an app developer to set guidelines, which dictate whether an app can run on a user's computer or not.
The more I read, the more important I feel it is for users to be in control.
A user must be able to choose whether or not to follow an attestation guideline or not.
Simply making attestation open source, without giving user's choice and control over what they can run on their computer, is insufficient.
It's also entirely security / compliance theatre in most cases. The theory is 'I require attestation for client apps for using my service, and now I can make systematic guarantees about how it will interact with the service'. Things like Outlook's corporate email features that allow you to prevent copy-and-paste work like this: Exchange will send the message only to Outlook, something like InTune attests that this really is a valid version of Outlook.
The problem is that these things are sitting on tens, if not hundreds, of millions of lines of C/C++ code that all must be 100% bug-free for the attestations to mean anything. A single vulnerability in any of the lower levels makes it possible for a malicious client to forge the attestation. So you don't really lock out anyone willing to put a little bit of effort into the attack but you do prevent a lot of legitimate use.
-
@neil What the bank thinks they're getting: if the device has some strange rootkit with flashing red and black, our app won't run so we won't have to pay for the customer's loss.
What the bank is getting: the customer must sign over all their data to an American corporation that is complicit in genocide. Also the above, maybe.What the banks thinks it's getting: Their app running on a phone that is 'secure', because its bootlocker is still locked.
What the bank may well be getting: Their app running on a phone that is definitely not secure, because despite the locked bootloader, and passing SafetyNet (or whatever Google are calling it now)... it's no longer receiving updates, has multiple vulnerabilities, and has spyware up the wazoo as a result.
-
It's also entirely security / compliance theatre in most cases. The theory is 'I require attestation for client apps for using my service, and now I can make systematic guarantees about how it will interact with the service'. Things like Outlook's corporate email features that allow you to prevent copy-and-paste work like this: Exchange will send the message only to Outlook, something like InTune attests that this really is a valid version of Outlook.
The problem is that these things are sitting on tens, if not hundreds, of millions of lines of C/C++ code that all must be 100% bug-free for the attestations to mean anything. A single vulnerability in any of the lower levels makes it possible for a malicious client to forge the attestation. So you don't really lock out anyone willing to put a little bit of effort into the attack but you do prevent a lot of legitimate use.
@david_chisnall @neil I get your point, but feel you're very much down playing the effort it takes to find an exploit on a properly updated device.
Regardless of whether the systems provide perfect levels of security or not, arguably blocking the installation of their app on rooted devices limits their exposure to systems that can perform operations they wish to block
-
@teezeh
Attestation absolutely can be used on general computers as well as mobile phones, I've been playing around with the Linux tooling for it recently. It's a technology which has some really positive potential use cases, but as with anything like this, the potential for abuse by corporate interests if they get control is high.
@neil -
@david_chisnall @neil I get your point, but feel you're very much down playing the effort it takes to find an exploit on a properly updated device.
Regardless of whether the systems provide perfect levels of security or not, arguably blocking the installation of their app on rooted devices limits their exposure to systems that can perform operations they wish to block
@david_chisnall @neil I think is may also allow them to restrict their app from being installed on systems that are on older versions of the OS which aren't going to be getting security updates, etc.
Please don't get me wrong, I much prefer running systems where I retain control to install and use things as I wish. Though I'm also under no illusion that rights holders and those that are regulated to ensure a level of safety for their users aren't going to be willing to support such systems.
-
@david_chisnall @neil I think is may also allow them to restrict their app from being installed on systems that are on older versions of the OS which aren't going to be getting security updates, etc.
Please don't get me wrong, I much prefer running systems where I retain control to install and use things as I wish. Though I'm also under no illusion that rights holders and those that are regulated to ensure a level of safety for their users aren't going to be willing to support such systems.
@david_chisnall @neil There's a balance to be struck here. Unfortunately, this is something I'd argue that won't happen without regulation. But it is also super critical that the open source community learns how to effectively talk to politicians to ensure that our views are taken into account. This means we need to effectively show and communicate the harms that allowing the unlimited locking of systems presents to users, especially, say, their more vulnerable constituents.
-
@teezeh I am not sure that it really matters for this purpose whether someone does their computing on a phone, a laptop, a tablet, a desktop etc?
-
@david_chisnall @neil There's a balance to be struck here. Unfortunately, this is something I'd argue that won't happen without regulation. But it is also super critical that the open source community learns how to effectively talk to politicians to ensure that our views are taken into account. This means we need to effectively show and communicate the harms that allowing the unlimited locking of systems presents to users, especially, say, their more vulnerable constituents.
@david_chisnall @neil And/or effectively communicating to them in terms the politicians understand how it will benefit their constituents.
We are generally terrible at doing this.
-
@david_chisnall @neil I get your point, but feel you're very much down playing the effort it takes to find an exploit on a properly updated device.
Regardless of whether the systems provide perfect levels of security or not, arguably blocking the installation of their app on rooted devices limits their exposure to systems that can perform operations they wish to block
The problem is, you don't have to find an exploit on a properly updated device, you have to find an exploit on a device that you control, with an OS version that provides PCR values that the remote attestation thing trusts in building its chain of trust. That's a much easier problem, because you can usually use publicly disclosed vulnerabilities, often ones with PoCs attached to the disclosure.
Linux averages one CVE per 1.5 days. How hard do you think it is to find a local privilege elevation that can compromise an Android kernel or part of the attestation infrastructure?
-
R relay@relay.infosec.exchange shared this topic
