How to implement server-side authentication for text filtering requests??

If an app has a text filtering extension

Please clarify what you mean by “text filtering extension”. Are you referring to SMS and MMS Message Filtering?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes. Is there a way for the server to know the traffic has come from Apple and not a spoofer of Apple?

I saw somebody post a question in the past about using Shared Web Credentials to perform basic auth, is that possible?

My general advice on this front is to use App Attest, although I’m not sure how that’d work in a Message Filter app extension (I’m not the DTS primary on either of these technologies).

I’ve tweaked the tags of this post and I hope that’ll attract folks who know more about this stuff.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

AppAttest documentation says: "...Then you use the service to cryptographically sign server requests using the certified key."

With text filtering extensions, as the server request is coming from the OS, not from the app/extension, then the app/extension presumably won't be able to sign the server request?

If somebody reverse engineers the associated domain urls our of the app's info.plist or entitlement files and calls the server url directly, then how can the server detect this has occurred and the request is not coming from the iPhone OS of a handset on which the app is installed?

The basic security mechanism here is that the connection is secured using the web credentials you've provide, so all a user could do in the scenario above is report data as "themselves":

"If you have servers that can help your app extension determine how to handle a message, you must add the Associated Domains capability to your Xcode project and specify those domains. Then, you must set up shared credentials as described in Shared Web Credentials, substituting messagefilter for webcredentials throughout the steps. Lastly, you must specify the domains in your Info.plist file, which should look similar to the dictionary shown below."
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@Kevin Elliott

A few of app extensions cannot make networks calls themselves, instead the OS makes the network call on behalf of the extension (such as the Message Filter Extension or Unwanted Communication extension).

As its not the extension itself making the network call in these situations, then does that affect the situation?

A few of app extensions cannot make networks calls themselves, instead the OS makes the network call on behalf of the extension (such as the Message Filter Extension or Unwanted Communication extension).

As its not the extension itself making the network call in these situations, then does that affect the situation?

No, at least not in this case. The credentials the system is using come from the system keychain and they were inserted there by your app, presumably as part of an in-app configuration process controlled by your app.

Note that while the documentation there is structured as "user name/password", that doesn't necessarily need to be the direct credentials the user would actually use to "login" to your service. Your service could also issue back extension specific login credentials after it authenticates the user through their normal credentials (or whatever mechanism you normally use). Note that many VPN services use an approach similar to this- the user has an "account" which is used to login to the VPN services management interface (website/app/etc). That account can then create additional "login users" (which are used to authenticate the actual VPN service), but the two different account types can only be used within their respective "areas".

Returning to the original question here:

In other words, how can the server verify that the request is valid and coming from the iPhone and not from some spoofer?

The connection is authenticated to a particular user, which is how you'd normally limit the impact of any spoofer. However, I'll also so that the login architecture I sketched out above also means that you could use App Attest to perform security checks before you issue an extension account to that device.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@Kevin Elliott So the app would run code referenced in the documentation for App Attest, rather than the Message Filter Extension, however when the OS contacts the server its pulling stuff from the keychain which was set in the app?

There's a past question here about using (and failing) to use Web Credentials in the Message Filter Extension, should they have been calling that code from the app and not the extension?

https://developer.apple.com/forums/thread/758611

I'm not understanding how App Attest could be used in an app extension when the documentation for it states:

"Important. Most app extensions don’t support App Attest.....The only app extensions that support App Attest are watchOS extensions in watchOS 9 or later. " (https://developer.apple.com/documentation/devicecheck/establishing-your-app-s-integrity)

I don't understand therefore how its being suggested it could be used for a message filtering extension when its documentation says app extensions don't support it?

@Kevin Elliott So the app would run code referenced in the documentation for App Attest, rather than the Message Filter Extension, however when the OS contacts the server its pulling stuff from the keychain which was set in the app?

Correct. The app validates using App Attest, then adds the credential data into the keychain.

There's a past question here about using (and failing) to use Web Credentials in the Message Filter Extension, should they have been calling that code from the app and not the extension?

Yes, that's what I would recommend. To be honest, I haven't specifically looked at this particular detail of the filter extension in great detail, but the app is really the only place this makes sense to do. Two reasons:

1. The filer extension is going to run in a very broad set of circumstances, so you should try to keep it's implementation as simple as possible.

2. You need to validate the credential information before you use/set them and you need to do that in the app so that the user can fix anything that goes wrong (for example, password typos).

Basically, once you've validated them there isn't any reason NOT to complete the process by storing them into the web credential store.

I don't understand therefore how its being suggested it could be used for a message filtering extension when its documentation says app extensions don't support it?

Expanding on what I said above, the idea here is that you do all of your setup inside your app (including App Attest) and configure the filter extension until you've checked whatever you want to check.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@Kevin Elliott

Returning to the original question here:

In other words, how can the server verify that the request is valid and coming from the iPhone and not from some spoofer?

The quoted part of the original question, in isolation from the sentence that preceeds it, doesn't accuratly represent the actual focus of the question.

The first sentence of the question is: "If an app has a text filtering extension and associated server that the iPhone OS communicates with, then how can that communication be authenticated?"

The word "that" in "how can that communication be authenticated" refers to the earlier part of the sentence "and associated server that the iPhone OS communicates with". i.e. it is referring to the communication between the OS and the server, not between the application and the server.

The question is in reference specifically to a message filtering extension. When the associated server for a MFE is contacted, it is not contacted directly by the MFE nor by the app, instead it is contacted by the iPhone OS. The question therefore would be better off explicitly phrased as:

"How can the server verify that the request which is being sent by the OS on behalf of the app/Message FIlter Extension is valid and coming from the iPhone and not from some spoofer?

My apologies is this wasn't clear and the question has to be devided by careful study of the specific wording of the question.

I get the impression this thead is answering a different question - question about how the server can authenticate https trafic coming from the app, rather than from the OS. If it hasn't then I'm still just not understanding at all how app attest fits into the picture in this specific case.

With app attest the server is validating requests from the app. In the case of a Message Filter Extension there are no requests coming from either the extension nor from the app to the server.

"How can the server verify that the request which is being sent by the OS on behalf of the app/Message FIlter Extension is valid and coming from the iPhone and not from some spoofer?

Yes, that was how I understood your question.

As I described above, the only information your app provides here is the web credential and your app could introduce an additional verification level by performing app attest before storing credential data into the data store. That's the only validation flow that's currently possible.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Unfortunately I'm still confused.

It seems to be being suggested that the app uses App Attest for validation between the app and the server. Then once that validation has been performed, the Message Filter Extension can see that the app/server has been validated and will start functioning.

However what does that have to do with the server then subsequently validating https traffic coming from the System which is what the question is about?

Once the MFE is functioning, when the handset receives an SMS, the System is going to invoke the MFE and the extension may instruct the system to contact the server. When the system contacts the server, then the server still has no way of knowing if the traffic is coming from a phone or an impersonator of a phone. The fact that the app has performed attestation seems irrelevant to me?

The payload that the iPhone system sends to the server is going to be identical whether the app has performed attestation or not.

Therefore, when the server receives some incomming https, it cannot distinguish if that has originated from an iphone, or some something impersonating an iphone.

My apologies, I just seem to have a big disconnect in grasping the point that is being made in this thread.

When the system contacts the server, then the server still has no way of knowing if the traffic is coming from a phone or an impersonator of a phone. The fact that the app has performed attestation seems irrelevant to me?

How did the impersonator acquire the necessary credentials? If the only place the credentials are stored is in the system keychain, then acquiring the credentials means breaking the system keychain. It's not clear to me what your thread model here is but for an "external" attacker, that's a significant barrier.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

That in turn comes back to the question how are the credentials applied when the system makes the connection to the server? It isn't the message filter extension which is making the connection to the server, and the MFE can't directly affect the http payload/header/signing etc.

The MFE tells the OS that the server should be contacted, but it has no influence over how that is done, nor what the payload or signing applied is.

So that is where my misunderstanding is coming from. As the MFE can't affect the HTTP payload, how are credentials getting applied to that payload?