|
|
Log in / Subscribe / Register

On Android distros

On Android distros

Posted Jan 2, 2025 18:42 UTC (Thu) by sionescu (subscriber, #59410)
Parent article: Some things to expect in 2025

> Distributions for mobile devices will see a resurgence in interest

It will be interesting to see how this will interact with the device security attestation that's built into Android. Many banking apps will refuse to run on a device that was unlocked or has even one app installed from an unknown source (i.e. neither the Google Play store nor the manufacturer store).


to post comments

On Android distros

Posted Jan 2, 2025 21:26 UTC (Thu) by epa (subscriber, #39769) [Link] (11 responses)

Presumably if you control the distribution all the way down to the kernel, you could program it to hide the apps that are installed or change the ‘unlocked’ flag.

On Android distros

Posted Jan 2, 2025 21:50 UTC (Thu) by intelfx (subscriber, #130118) [Link] (4 responses)

> Presumably if you control the distribution all the way down to the kernel, you could program it to hide the apps that are installed or change the ‘unlocked’ flag.

The "remote attestation" thing (read: pervasive DRM facilitated by hardware) is explicitly designed to mitigate this... unfortunate possibility (unfortunate, of course, in the eyes of the commercial interests).

On Android distros

Posted Jan 2, 2025 22:06 UTC (Thu) by epa (subscriber, #39769) [Link] (3 responses)

Yes, I guess it depends on whether you have open hardware or there are some parts of the system (a TPM) that not even the kernel can fully control.

On Android distros

Posted Jan 3, 2025 2:12 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

Most (all?) mobile devices have two systems in one chipset, one is running Android (or other high-level OS) and the other one runs proprietary RTOS and certified to drives the radio.

Guess which one is in charge of everything and couldn't be easily touched and/or changed?

On Android distros

Posted Jan 3, 2025 8:56 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

That’s true but I think it is not what we were talking about. A banking app does not check whether your phone’s radio is operating within FCC parameters. It may ask to list the apps installed at the Linux level or whether the user has root access (which does not give you control over the locked-down radio hardware).

The question is whether there is a third piece of hardware, the TPM, which can be queried from user space but isn’t under the device owner’s control, so you cannot tell it to say you are running a particular software stack when you aren’t.

If you do have root you could in principle attach a debugger to the misbehaving app and alter its memory to make it run anyway, but that wouldn’t help with a cryptographically strong attestation to a remote server using a private key locked inside the TPM.

On Android distros

Posted Jan 3, 2025 14:56 UTC (Fri) by khim (subscriber, #9252) [Link]

> A banking app does not check whether your phone’s radio is operating within FCC parameters.

Sure, but the existence of separate, “hidden” and “secret” world means this quesion

> The question is whether there is a third piece of hardware, the TPM, which can be queried from user space but isn’t under the device owner’s control, so you cannot tell it to say you are running a particular software stack when you aren’t.

Has very definitive and obvious answer: yes, there is such a piece of hardware. And you can not forge it.

Of course many banking apps look for things that shouldn't concern them (things like what other apps are installed), and these can be easily forged by suitable firmware.

But if they just look for the attestation then this couldn't be forged.

> If you do have root you could in principle attach a debugger to the misbehaving app and alter its memory to make it run anyway, but that wouldn’t help with a cryptographically strong attestation to a remote server using a private key locked inside the TPM.

Of course our world is not perfect and we couldn't have nice things: because in certain places hacked Chinese phones are extremely popular (they are cheaper but need hacked ROM to stop phoning to the Chinese landlords) banks couldn't just trust the attestation. Instead they invent elaborate schemes that allow the use of some of these hacked phones, but not all hacked phones.

Whether it'll work on your device depends on the bank and the phase of the moon.

On Android distros

Posted Jan 2, 2025 22:10 UTC (Thu) by excors (subscriber, #95769) [Link] (5 responses)

The kernel may not be low-level enough - the Google Play Integrity API reports a few different levels of integrity, and I believe the strongest requires Verified Boot and hardware attestation to prove you're running a certified, locked, unrooted, official bootloader/kernel/etc (https://developer.android.com/google/play/integrity/verdi...). If an app requires that level of integrity, and is willing to sacrifice compatibility with older Android devices and niche device configurations, no amount of fiddling with software will get around it (barring severe bugs in the implementation).

GrapheneOS notes that instead of using the Play Integrity API, apps could use AOSP's lower-level attestation API and choose to accept devices that match a list of "official GrapheneOS verified boot keys" (https://grapheneos.org/articles/attestation-compatibility...), which should provide a similar level of assurance without being tied to the proprietary Google Play Services. But I don't know if any serious apps actually do that.

On Android distros

Posted Jan 3, 2025 11:31 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

What is to stop the API reporting that it's certified and unrooted when running a custom distribution?

On Android distros

Posted Jan 3, 2025 12:08 UTC (Fri) by excors (subscriber, #95769) [Link] (2 responses)

The app connects to some online service (e.g. your bank) which controls all the sensitive data this system is trying to protect. (It's not meant to protect purely offline apps). The app uses the API to get a securely signed attestation report, which it forwards to the online service for verification (checking the root certificate is signed by Google's attestation root key, the Verified Boot details say it's running trustworthy firmware, etc). The app/kernel/firmware can't forge the signatures, because the hardware does a reasonable job at keeping the private keys secret, so the server would reject a fake report and the app wouldn't have access to your money/secrets/etc.

On Android distros

Posted Jan 3, 2025 14:01 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

So you're saying the signature for the attestation report comes from the TPM (not the Linux operating system).

On Android distros

Posted Jan 3, 2025 16:25 UTC (Fri) by excors (subscriber, #95769) [Link]

Basically, yes.

(Technically it's not called a TPM, probably because that's a specific ISO standard and they don't implement that, but it's a vaguely similar idea. On Pixel phones there's a small 'secure' OS running on the main CPU in parallel to Linux, using ARM TrustZone for isolation; plus a security core on the main SoC, with its own dedicated CPU/RAM/etc running another OS; plus a physically separate security chip with yet another simple OS. Some combination of those are used for Verified Boot, attestation, etc. See https://security.googleblog.com/2021/10/pixel-6-setting-n...)

On Android distros

Posted Jan 10, 2025 13:30 UTC (Fri) by anton (subscriber, #25547) [Link]

According to the German Wikipedia, GrapheneOS works with a number of banking apps (the bank where I have my main account is listed). I don't know if these apps use the attestation API, but it certainly looks encouraging.

On Android distros

Posted Jan 2, 2025 22:13 UTC (Thu) by leromarinvit (subscriber, #56850) [Link] (12 responses)

> Many banking apps will refuse to run on a device that was unlocked or has even one app installed from an unknown source (i.e. neither the Google Play store nor the manufacturer store).

Funnily enough, I've seen more issues running banking apps on stock Android. Root it and hide everything but base system stuff using MagiskHide (or whatever it is called now), and poof, the problem is gone.

The day they start effectively locking rooted devices out is the day I'll quit my account there, making sure they know why (not that I expect them to care). First of all, because it's the only language they'll understand. But even more importantly in practice, dealing with such restrictions just complicates daily tasks too much. They decided I have to use their app to confirm transactions - not what I'd have preferred, but fine, I'll go along as long as it doesn't cause too much friction. But they sure as hell don't get to decide what hardware or software I'll run their app on.

On Android distros

Posted Jan 3, 2025 6:10 UTC (Fri) by merge (subscriber, #65339) [Link]

I don't use stuff that ties an online account to one specific device (that qualifies as what I tell my kids to be a "large" computer - phone/tablet/tv...). I always want to be able to switch devices easily.

I don't have a google account. When I'm asked to use the banking apps I ask "why would I create an account with google or apple company now? that doesn't feel right for wanting to use online banking." nobody in a bank has a good answer for that and I now use a "cardtan" device ("small computer", i.e. non-connected uC-based).

Similar story for the "legal services" app in my country where I use a fido2 key instead of an app.

While the app-solutions are what people are primarily shown and using, I guess there's good reasons for why this is not the only technical solution for critical services. I hope there's even a law that requires that, not sure.

On Android distros

Posted Jan 3, 2025 9:06 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (10 responses)

I believe they will be happy to let you go. The cost of losing one client is much much less than the cost of fraud the banks are on the hook for. They minimise their risk by requiring certain platforms with known security profile.

You may be tech savvy enough to secure your device, but you're an outlier among banks customers. It is safe (less risky) to NOT serve such complaining liability. Sorry, that's life.

(I've worked in three different banks in EU, I know some internals).

On Android distros

Posted Jan 3, 2025 9:43 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

> I believe they will be happy to let you go. The cost of losing one client is much much less than the cost of fraud the banks are on the hook for. They minimise their risk by requiring certain platforms with known security profile.

The problem is they are trying to force everyone on to mobile. I wanted to read the small print for a loan. So I logged on to the "bank" to look for it. Next thing I know, "give us your mobile so we can finish everything ..." with NO apparent way to bypass it!

With fat fingers and aging eyes, do you really think I want to read the small print on a screen I can hardly see!!!

I've got no security conscious stuff on my personal phone (other than 2FA for work), and I have no intention of putting anything such on it. Anything of note (that doesn't require a PHONE) gets done on a minimum 15" screen. Usually with a 24" monitor attached.

Cheers,
Wol

On Android distros

Posted Jan 3, 2025 13:00 UTC (Fri) by dskoll (subscriber, #1630) [Link] (2 responses)

That's really terrible. Here in Canada, all of the banks still support almost all banking via a vanilla web browser rather than forcing you to use an app. The only exception is remote cheque deposits.

If my bank forces me to use a mobile device, I'll switch banks. If all of them do, I suspect there will be a legal challenge, probably on the basis of accessibility. I doubt the mobile banking apps support visually-impaired users.

On Android distros

Posted Jan 3, 2025 19:31 UTC (Fri) by Wol (subscriber, #4433) [Link]

It was actually Volkswagen Finance. "Take out a finance deal and get a £4K discount" iirc. But from what I could make out, they added all the interest up front when calculating the repayments, and I didn't trust them to refund the finance charges if I repaid it early. That was what I wanted to check, and I got the distinct impression any refund was discretionary ... so if you took the loan to get the discount, then repaid it after a month or two, you could end up out of pocket. I chose not to take the risk.

Cheers,
Wol

On Android distros

Posted Jan 5, 2025 0:08 UTC (Sun) by jkingweb (subscriber, #113039) [Link]

> Here in Canada, all of the banks still support almost all banking via a vanilla web browser rather than forcing you to use an app. The only exception is remote cheque deposits.

RBC has a lower limit for Interac transfers via the Web than their app, too.

On Android distros

Posted Jan 3, 2025 16:20 UTC (Fri) by busman (subscriber, #7333) [Link] (1 responses)

Why mobile apps need such draconian measures while desktop browsers don't? I can happily use Firefox on Linux without my banks complaining but having *less* functionality in mobile clients is somehow more dangerous (for some of them)?

On Android distros

Posted Jan 3, 2025 17:01 UTC (Fri) by excors (subscriber, #95769) [Link]

I think it's not about "need" - it's a tradeoff between security and compatibility. There's no practical way to do this kind of integrity verification on PCs, and blocking access from all PCs would drive away too many customers, so the banks will put up with a certain level of fraud from keylogging malware etc. But there is a practical way to do it on modern phones, and blocking access from unverified phones would only drive away a small number of customers, so they've decided the reduction in fraud makes that worthwhile.

(My bank also makes the app much more convenient than the website - e.g. I can set up new payments through the app with just a fingerprint (and maybe facial recognition if it's a large amount of money), whereas on the website I need to type in my ID and password and then insert my physical card into a card reader to generate authorisation codes to type in. There's always a security vs convenience tradeoff, but the improved security of the phone platform means they can increase convenience and still keep fraud within acceptable levels.)

On Android distros

Posted Jan 4, 2025 5:12 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

Here in good ol' 'merica, I know of at least one major brokerage firm (perhaps THE largest) that doesn't even require 2FA ... anywhere :)

For that reason, I strongly suspect the "rooted Android = no banking app" problem is likely specific to over-regulated Europeans.

On Android distros

Posted Jan 4, 2025 13:32 UTC (Sat) by kleptog (subscriber, #1183) [Link] (2 responses)

> For that reason, I strongly suspect the "rooted Android = no banking app" problem is likely specific to over-regulated Europeans.

By "over-regulated" I guess you mean the banks can't tell the customer to suck it up if money vanishes from their account without the customer being involved?

Because banking regulations don't say anything about Android phones, rooted or otherwise. Or even apps.

On Android distros

Posted Jan 5, 2025 9:13 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (1 responses)

my bank in italy retired the 2fa hardware tokens and moved to sending the otp via sms. They said it was because of european regulations. I went to read the regulation and it said to use hw tokens, prefer to avoid otp apps and absolutely never send the otp in clear text.

Banca san paolo if you are wondering. A very large bank.

On Android distros

Posted Jan 5, 2025 9:37 UTC (Sun) by Wol (subscriber, #4433) [Link]

Sounds right. Lorry drivers are allowed to drive a maximum of 13 consecutive days without a 2-day (45hrs to be pedantic) break.

One of my colleagues - responsible for enforcing the regs !!! - insisted that meant "one break every second week", and then designed our enforcement system to only look back 8 days. I still think he doesn't understand what's wrong - he hates the system I wrote to replace it ...

Cheers,
Wol


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds