Enhance the secure messaging app with tamper and debug detection.
- [Instructor] Android apps are signed to provide details of their source. This is usually the developer's signature. And while Android doesn't validate the authenticity of the certificate used for the signature, it does enable a level of trust to be established. One of the forms of attack that we might be concerned about is unauthorized modifications made to otherwise legitimate apps. This can be done by deconstructing the app, modifying it, rebuilding it, and resigning it. However, the hash code for the app will have changed, and the signature won't be that of the legitimate developer.
We can detect this kind of change by getting the signature of the app certificate prior to release, and then checking it subsequently at run time to confirm it hasn't changed. We might even display this for the user to allow user level validation. A determined attacker who detects this feature could compromise it, but if cleverly done, then it does increase the cost to the attacker. To get the signature, we need to run the app, and use the packet manager's signature function, and display the signature hash code, and then code it in with a check.
In this case, my certificate's hash code is 249550521, and I can validate against this. You'll need to validate against your own. As with any sensitive information, this value will need to be protected. This check certainly can be defeated by an attacker, but you can be creative in hiding the validation code or making it difficult to do so. Another check we can add to detect unusual activity is to determine whether the app is being run in debug mode. We can do this with two checks.
The first is to check whether the app is debuggable or not, which is a good check against inadvertently releasing a debug version. We can do this by checking the application's information. Next we can check whether the app is currently being run across a debug connection such as ADB. We can use an Android system call to check this. When I run the program with my debug build variant selected in Android Studio, a toast pops up to warn that this is a debugging deployment. Tamper detection is a big issue, and one that has some heavier solutions, which, while again not being perfect, they once more increase the cost to the attacker.
One of these is the Google Plays SafetyNet service. SafetyNet introduces the concept known as attestation, which is an opinion regarding the status of a device once a suite of compatibility tests have been run. This service is used to confirm that an app can be allowed to include Google Play services. It can also be used by a developer to increase the level of tamper detection in his or her app. Compatibility in the safety net context means that the device is currently in a non-tempered state.
From a safety net perspective, being tampered includes being routed, being monitored, or being infected with malware. Using SafetyNet in an app requires three steps. The app calls the SafetyNetApi.attest function, which comes in the Google Play services SDK. The request uses Google API client to connect to the Google servers. The request includes a random number or nance to prevent replay attacks. Google responds with the attestation result as a signed Jason object.
The key item in the response is the CTS profile match value, which can be true or false. The app verifies the response, and takes appropriate action. This is an advanced topic and we'll not code any attestation into our app. But for high value apps, it's definitely worth considering. You can learn more about how to go about using SafetyNet attestation here.
- Understanding Android OS, app, and hardware security components
- Using the Trusted Execution Environment
- Developing Android apps with security in mind
- Analyzing existing applications
- Understanding Android vulnerabilities
- Securing Android apps
- Developing secure enterprise apps