With the explosion of mobile apps in the market, app attestation becomes a key strategy. It allows app developers to evaluate the security of their apps and is applicable for Android and iOS. It becomes an important part of a company’s abuse detection system wherein your security experts can check if your servers are indeed interacting with genuine applications. 

     App Attestation

App attestation uses a series of integrity tests and measurements to verify an app’s integrity. Once integrity is proved, a cryptographic token is provided and shared with the backend servers for verification. App developers can assess an app and check for the security and compatibility of the environments in which an app is running by looking for integrity issues and comparing them with reference data. A range of areas can be tested like data tampering, unsafe URLs, fake users, harmful applications/features etc. It ensures to protect apps from risky transactions and fraudulent usage, while reducing the chances of cheating and unauthorized access. Instead of relying on the app’s security features alone, this approach uses a remote attestation strategy, whereby the app needs to prove its genuine nature by connecting with the remote environment, thereby making it more robust. 

Apple / iOS App Attestation through App Attest Service

Since applications are used by millions of users, it is important to test them in a sandbox environment. The same holds true for app attestation. You can then generate and attest multiple keys on a device while keeping the production environment safe, up and running. If one wants to test during development, the App Attest Environment entitlement needs to be added to the app’s entitlements file and the value should be set to ‘production’. But do note that the keys across the environments are independent of each other. To avoid overwhelming the system, activate the app attest feature for smaller batches of users before rolling it out to a wider audience. This would ensure a limited number of calls for app updates. 

One use case to consider in app attestation is while checking if a valid instance of an app is getting connected to your server. The app uses a shared instance of DCAppAttestService to generate a cryptographic key, post which an attestation object and a key identifier are passed to the server where the verification happens. The key is used to verify assertion objects for activities like downloading or accessing premium content. Alternatively, you can also use a randomized data value for verification when an app needs to communicate attestation data to your server. This is called a one-time challenge. This is then integrated into the objects that it provides and your app sends it back to your server. So first you get a key identifier and the backend service starts working on the first challenge string. The attestation token is retrieved from the app attest service. This, along with the key identifier, is sent to the backend service where the decoding / parsing happens. If the validation passes, the service saves the CredCert (first buffer in the decoded “x5c” arrays) value. A second challenge string is then generated and sent to the iOS app. An assertion token is again generated and decoded/parsed. The API call is the final step. 

Android App Attestation through SafetyNet Attestation API

SafetyNet Attestation API works for Android devices and helps app developers assess their devices. It provides a cryptographically signed attestation and examines a device’s software and hardware environments. A call called nonce is first made from an app to the server. The runtime environment is evaluated and a signed attestation of the assessment results is shared from Google’s servers to the SafetyNet Attestation service to the app. It is then forwarded to the server which validates and generates a report with findings. The attestation token is formatted in JSON Web Signature (JWS). When it comes to checking the legitimacy of an app, the value of basicIntegrity and ctsProfileMatch should be true, nounce should not be empty, and the value of apkPackageName and apkCertificateDigestSha256 should be the same as that of the Android app.

Publisher attestation comes as a saviour

All teams around the globe are looking for more streamlined, exhaustive compliance and adherence to security measures. Publisher attestation, part of Microsoft 365 App Compliance Program, is a step towards this direction. A detailed self-assessment is the key feature here. It comes equipped with frequently asked questions from customers or IT admins while evaluating app security. These details are published for better transparency, ease of access and swifter evaluation. It covers web apps (SaaS apps from the commercial marketplace in Partner Center) which integrate with Microsoft products like Teams, Word, PowerPoint, Outlook, SharePoint, Excel etc. The major benefits of publisher attestation are greater transparency, reduced time and better compliance since best practices are noted down and shared. It also is pretty exhaustive since its covers the entire scope of an app’s functionality (looking at a whopping 80 risk factors) like the below:

• Data handling: Collection, storage and usage of data
• Security: Rules, procedures and protocols to protect data from attacks
• Compliance: Adherence to industry-wide standards and specifications 
• Legal: Adherence to legislative regulations 

If the above checks do not pass, the app attestation request is rejected. Even after an approval, misinformation in a document will rescind the confirmation status. Even from a timeline perspective, the attestation is valid for a year post which the procedure has to be initiated again. Any updates or modifications to an app would also call for a retest. 

App attestation with Google FireBase

With the Google firebase, you can test your apps in your Apple app. You have to first enable App Check and set up your FireBase project through Xcode 12.5+ version and register your apps to enable access. Then add the App Check library to your app in your project’s Podfile. Then you have to initialize App Check by writing an implementation of AppCheckProviderFactory. Then the updated apps can be distributed to end users. Here the Request Metrics screen becomes paramount where you will be able to see requests from different categories like verified, outdated client, unknown origin and invalid. Metrics can be analyzed in the Google Cloud Console. When it comes to finally enabling enforcement, you have to just open the App Check section of the FireBase console, expand the metrics view and click on ‘Enable’. 

Upping the app security game with AppSealing

It is widely known now that application security is important. But lack of standards makes it a tad bit difficult. The origin of the application code and its residency make it more complicated. Especially since we are talking about threats that take place internally as well as externally. Third-party risk assessments are often just a half-baked strategy when it comes to application security. We know how recently Apple discovered security flaws in its iPhones, iPads and Macs, putting the focus on users to update their softwares. A holistic application security solution is the only way out – one that helps you look at threat analytics with the least minimum effort. One that is compatible with third party libraries and lets you test your application security at run time. AppSealing is one such platform that has protected 1 billion+ apps and is blocking a whopping 150 million+ hacking vectors. If you are keen to learn more, do get in touch with the mobile application security leader now!