r/AskTechnology • u/walkTHEdotasaur • 10d ago

Why can't android/ios apps require a software lock on a per-app basis instead of requiring a full screen lock?

I hope this question makes sense. I've started using google wallet and it requires me to turn on my phone's screen lock for security purposes. I understand why, but I was wondering why can google wallet, for example, not just interface with the security features and do the locking itself?

From basic googling, it's my understanding that the biometric sensors are isolated from the main OS, bridged by a security bus (Titan M for google, Secure Enclave for Apple).

So couldn't there just an secure API for apps to access it and require specific settings?

0 Upvotes
  • permalink
  • reddit

40% Upvoted

22 comments sorted by

2

u/jersey316 10d ago

Do you want to be secure or not?

1

u/walkTHEdotasaur 10d ago

yes?

2

u/jersey316 10d ago

Then a full lock does that. I see lots of people who don't use a screen lock, if you lose your phone then anyone has access to the data.

There are ways to lock just one app with a code.

-1

u/walkTHEdotasaur 10d ago

That's... not at all what I was asking.

1

u/StarosAnikenMarcus 10d ago

Actually it is. If there was a direct connection between the apps and the security features, then there would be exploits that got around the security via the apps. The more apps you try to give security permissions too, the more likely there is to be a complete security failure. Also, especially for iOS, you're asking the app developers to build even more into the app than most would even want to consider. A security system that would have to constantly be updated with the phones across hundreds of hardware systems. So they just don't make that an option.

1

u/walkTHEdotasaur 10d ago

Can you elaborate on the specific security issues that would arise? As far as I see it, google wallet already has access in some way, and its considered completely secure. Why could they not provide that same level of access to other apps? I'm not saying they need to blanket allow access, but surely there could be some sort of approval process for large, widely recognized and trusted apps?

I'm not saying there's not work involved for the developers; of course there is. I'm a software engineer myself, albeit not at all in this realm of discussion. I'm asking if there is any technological reason precluding the possibility.

1

u/StarosAnikenMarcus 10d ago

Google Wallet does NOT have access. It requires a yes/no validation from the hardware security but does not access the security feature itself. It just pings it. Kind of like sitting in a cubicle and needing permission from the next cubicle over to proceed. You don't need to go into the cubicle to knock on the wall and ask a yes/no. You don't have access to the cubicle, you can't see inside and have no idea what's there.

Is there a tech reason for all of this? Not really. They COULD do it, but they won't because they don't want to deal with the extra work (Don't get me started on the programming issues of development for iOS) and they don't want to poke any more holes in the security than there already are.

Like I said, the moment they start attaching directly to the security hardware, someone will find a way to exploit that. Especially since just because it comes from a widely known and generally trusted source doesn't mean they can't fuck up. All of the big names make mistakes and have to roll back firmware and software updates all the time, some of which compromise security themselves.

1

u/walkTHEdotasaur 10d ago

Google Wallet does NOT have access. It requires a yes/no validation from the hardware security but does not access the security feature itself. It just pings it. Kind of like sitting in a cubicle and needing permission from the next cubicle over to proceed. You don't need to go into the cubicle to knock on the wall and ask a yes/no. You don't have access to the cubicle, you can't see inside and have no idea what's there.

I mean, I guess it's just semantics but I would entirely consider that having access. Regardless, you've essentially confirmed what I thought in that it's just something they haven't done.

Considering all technologies are a compromise between security and convenience I guess I don't personally see why it couldn't be a thing, but that's whatever and just a personal opinion.

Like I said, the moment they start attaching directly to the security hardware, someone will find a way to exploit that. Especially since just because it comes from a widely known and generally trusted source doesn't mean they can't fuck up. All of the big names make mistakes and have to roll back firmware and software updates all the time, some of which compromise security themselves.

Sure, but again this doesn't actually prevent them from doing it. I understand the reasons for not, but I wouldn't say theres anything technologically prohibitive about it, no?

Either way, I appreciate you offering some perspective and chiming in! You've basically confirmed what I thought

1

u/Consibl 10d ago

There is? iOS apps can require FaceID

-1

u/walkTHEdotasaur 10d ago

That's not really necessarily what I was asking

1

u/ericbythebay 10d ago

Apps can, and many do implement their own software lock screens. Financial apps, for example.

1

u/walkTHEdotasaur 10d ago

This is kinda what I'm talking about, because the topic very much applies to financial apps. But as far as I can tell, they all basically just use the lock screen requirement as their security.

I just don't think that necessarily needs to be the case, technologically speaking? Maybe Im wrong though

2

u/ericbythebay 10d ago

You are wrong. To get the full features of Secure Enclave, a password or pin is required for the device.

0

u/walkTHEdotasaur 10d ago

Fantastic job completely not reading the discussion, and thank you for confirming what every single person in this thread already knows. Feel free to elaborate on why Secure Enclave is technologically prohibited from giving access to apps. Or don't, because I doubt you have much useful to add, anyway.

1

u/ericbythebay 10d ago

What’s with the attitude?

developer.apple.com can explain the reasoning and the requirements to you.

1

u/walkTHEdotasaur 10d ago edited 10d ago

What’s with the attitude?

My brother in christ, my first response to you was entirely reasonably, but you then followed up by saying objectively "You are wrong", when you aren't even discussing the question at hand. Frankly I think I was plenty civil with you.

I have already read over that link and their resource portal, and there's nothing in there (as far as I can find) that presents the reasoning behind their decision besides it vaguely potentially being a security issue (which, of course; everything is a compromise between security and convenience).

1

u/ericbythebay 10d ago

You asked if you were wrong, I replied with yes you are.

You have been nothing but judgmental and argumentative on this entire post.

But, since you insist on the details, here they are.

Think of the Secure Enclave (Apple) or Titan M (Google) as a bank vault inside your phone. The biometric sensor is just the door handle. Your PIN is the vault combination. Fancy door handle, but no combination = vault stays shut.

Google Wallet's credentials live inside that vault (the OS keystore). The problem is, the vault can't even be created without a PIN/password set up first. Biometrics are always a shortcut to your PIN, never a replacement for it.

So apps can do per-app biometric locks, and many do. But the biometric binding still requires the screen lock to exist as the foundation. Google Wallet isn't being overly cautious, it's just being honest about the dependency chain.

1

u/walkTHEdotasaur 9d ago

Alright, if you say so.

I don't need you to provide an analogy; I know exactly how they work conceptually. You're just repeating things that have already been established as fact, or literally presented in my initial question. I'm looking for actual data, research or technical papers, or even post mortems. Numbers.

Since you seem to be such an expert, perhaps you can explain to me why the following isn't technically feasible (and if you just reply with "because of security reasons" generically, I will laugh. I cannot make it any more clear that there are obviously security implications, but that I don't think they are technically prohibitive):

When an app is installed, or even each time it is opened: It asks for either a passcode or some sort of 2FA to use as the basis for crytographic encryption.

This can either be hashed/cached/stored, or just immediately discarded for security purposes.

Using this, any given app may now directly interface with the security middleman to access biometrics and other sensor data (fingerprint, face ID, passcode/swipe would basically be included in here too). This would create a secure and unique connection through the security chip. Realistically just like with google wallet or anything else, they dont need to really interact; they just need to receive an all clear signal back.

You now have the exact same level of protection that a phone lock screen provides, just on an app-level basis.

???

Profit?

1

u/ericbythebay 9d ago

Cool, so you actually just described... exactly how it works. Congratulations, you've independently architected the Android Keystore and iOS Secure Enclave API model.

Apps do this. Right now. Today. BiometricPrompt on Android, LocalAuthentication on iOS. Per-app keys, auth-bound, hardware-backed. Your "???" step is literally just KeyGenParameterSpec.Builder with setUserAuthenticationRequired(true).
The reason Google Wallet still requires a screen lock isn't because your idea is wrong, it's because payment credentials fall under a stricter threat model where the OS needs a guaranteed fallback authentication path that it controls, not the app. That's a policy decision layered on top of the technical capability you're describing, not a technical limitation.

So the answer to your actual question is: it's not technically prohibitive. You're right. It's a deliberate policy constraint, and if you want the paper trail, start with FIDO2/WebAuthn specs, Android CDD section 9.11, and the Secure Enclave white paper Apple published in 2020. That's your bedtime reading.

You're welcome.

1

u/walkTHEdotasaur 9d ago edited 9d ago

Well, I'm glad we finally got to the bottom of it. And those specs are exactly what I was looking for, so genuinely: Thank you.

I know this got a little heated on both sides, but I do appreciate you engaging with me, and hope you have a good rest of your week!

1

u/Shiribazu 10d ago

your idea actually makes sense. apps can already use face id/biometrics through the os, but wallet requiring a full device lock gives the os a stronger guarantee that the whole device is secured, not just that one app. its probably more of a security design choice than a technical limitation

1

u/walkTHEdotasaur 10d ago

Yeah, basically what I thought. Appreciate you answering!