Photo: robert coolen – shutterstock.com
With the DeviceCheck framework, developers can reduce the risk of fraudulent use of their app and thus their services. To check the integrity, the DeviceCheck services with iOS / iPadOS 14 offer a DCAppAttestService API, which app developers can build into their apps to validate the integrity. An app can use this to check whether it has been changed in an unauthorized manner.
The DCAppAttestService API generates a hardware-based, cryptographic key for the app to be checked. This key is used with the help of Apple servers to confirm the legitimacy of the app in the event of server requests for sensitive or premium content. The generateKey (completionHandler:) method then generates said unique and device-based cryptographic key pair.
If successful, the completion handler of this method returns a key identifier that apps can later use to access the key. The app developer must hold the public key for his server service. The iOS device automatically saves the private key in the Secure Enclave. Here it can only be used to create signatures via the App-Attest service.
It should be noted that not all devices can use this new App-Attest service. A compatibility check is available for app developers, but the result is hard-coded under iOS / iPadOS and always returns “true”.
The App-Attest-Service also offers (on compatible devices) the possibility of validating sensitive server requests. For this, Apple’s own infrastructure is used to sign the requests to the server beforehand. Apple thus enables app developers to make a statement about the security of the data sent. There is no indication of the safety or integrity of the device itself.
As a result, the app receives a signature for communication based on its app ID. The Apple documentation says: “To use the App Attest service, your app must have an app ID that you register on the Apple Developer website.” This also applies to in-house apps. Since the app ID can not only be determined for publicly available or custom apps, but is also available for enterprise apps, this service should also work without problems here.
The interaction between the Apple attestation service and the device enables signed requests to be sent to the backend. If the signature deviates during validation by the server, it can end communication with the app and thus with the end device. Whether an app is possibly corrupted cannot necessarily be deduced from a successful signing of the request.
Apple itself admits that they cannot say for sure whether a device on which the app is installed is compromised: “For example, App Attest can’t definitely pinpoint a device with a compromised operating system.” If a device is compromised by a jailbreak, it can definitely not be ruled out with one hundred percent certainty that the app is not compromised. Because a broken OS cannot safely verify a binary or pick up the feedback from Apple. Practice will show here how well and safely this procedure works.
For one category of apps, this service may represent an insurmountable obstacle: apps from the Apple AppStore that are – supposedly – made safe for business use using app wrapping techniques. Many MDM manufacturers such as Microsoft (Intune), VMware Airwatch, MobileIron or Blackberry offer solutions to patch missing security functions in existing apps with security functions in the case.
Photo: Mark Zimmermann
However, app wrapping itself uses methods that hackers use to manipulate and attack apps for protection. So that this protection is not simply removed, an anchoring with the “host app” usually takes place through close interlinking of strings and client certificates between the “host app” and the wrapping library. The “reliability” of such a toothing – and thus the protection – is highly product-dependent. API calls from the “host app” are intercepted, but attacks from outside are not effectively prevented. Even code that has been developed “insecurely” can still be read by an attacker, since topics such as obfuscation (concealment) are not used here and cannot be patched into it afterwards.
Because of this “implantation” in existing apps, Apple may completely prevent wrapping for future apps or iOS updates. It is conceivable that the new app attestation service will put an end to the hustle and bustle in the future, because it will be able to detect precisely such manipulations. (mb)