Thursday, July 7, 2022
HomeMobileEnhance the safety of your app with the nonce discipline of the...

Enhance the safety of your app with the nonce discipline of the Play Integrity API



Posted by Oscar Rodriguez, Developer Relations Engineer

illustration with a mobile device displaying a security shield with a check mark, flow chart imagery, and Android logo

With the latest launch of the Play Integrity API, extra builders at the moment are taking motion to guard their video games and apps from doubtlessly dangerous and fraudulent interactions.

Along with helpful indicators on the integrity of the app, the integrity of the gadget, and licensing data, the Play Integrity API incorporates a easy, but very helpful function known as “nonce” that, when appropriately used, can additional strengthen the prevailing protections the Play Integrity API gives, in addition to mitigate sure varieties of assaults, reminiscent of person-in-the-middle (PITM) tampering assaults, and replay assaults.

On this weblog submit, we’ll take a deeper have a look at what the nonce is, the way it works, and the way it may be used to additional defend your app.

What’s a nonce?

In cryptography and safety engineering, a nonce (quantity as soon as) is a quantity that’s used solely as soon as in a safe communication. There are lots of functions for nonces, reminiscent of in authentication, encryption and hashing.

Within the Play Integrity API, the nonce is an opaque base-64 encoded binary blob that you just set earlier than invoking the API integrity examine, and it is going to be returned as-is contained in the signed response of the API. Relying on the way you create and validate the nonce, it’s potential to leverage it to additional strengthen the prevailing protections the Play Integrity API gives, in addition to mitigate sure varieties of assaults, reminiscent of person-in-the-middle (PITM) tampering assaults, and replay assaults.

Aside from returning the nonce as-is within the signed response, the Play Integrity API doesn’t carry out any processing of the particular nonce knowledge, so so long as it’s a legitimate base-64 worth, you may set any arbitrary worth. That mentioned, to be able to digitally signal the response, the nonce is distributed to Google’s servers, so it is extremely necessary to not set the nonce to any sort of personally identifiable data (PII), such because the person’s identify, cellphone or e-mail handle.

Setting the nonce

After having arrange your app to make use of the Play Integrity API, you set the nonce with the setNonce() technique, or its acceptable variant, out there within the Kotlin, Java, Unity, and Native variations of the API.

Kotlin:

val nonce: String = ...

// Create an occasion of a supervisor.
val integrityManager =
    IntegrityManagerFactory.create(applicationContext)

// Request the integrity token by offering a nonce.
val integrityTokenResponse: Activity<IntegrityTokenResponse> =
    integrityManager.requestIntegrityToken(
        IntegrityTokenRequest.builder()
             .setNonce(nonce) // Set the nonce
             .construct())

Java:

String nonce = ...

// Create an occasion of a supervisor.
IntegrityManager integrityManager =
    IntegrityManagerFactory.create(getApplicationContext());

// Request the integrity token by offering a nonce.
Activity<IntegrityTokenResponse> integrityTokenResponse =
    integrityManager
        .requestIntegrityToken(
            IntegrityTokenRequest.builder()
            .setNonce(nonce) // Set the nonce
            .construct());

Unity:

string nonce = ...

// Create an occasion of a supervisor.
var integrityManager = new IntegrityManager();

// Request the integrity token by offering a nonce.
var tokenRequest = new IntegrityTokenRequest(nonce);
var requestIntegrityTokenOperation =
    integrityManager.RequestIntegrityToken(tokenRequest);

Native:

/// Create an IntegrityTokenRequest object.
const char* nonce = ...
IntegrityTokenRequest* request;
IntegrityTokenRequest_create(&request);
IntegrityTokenRequest_setNonce(request, nonce); // Set the nonce
IntegrityTokenResponse* response;
IntegrityErrorCode error_code =
        IntegrityManager_requestIntegrityToken(request, &response);

Verifying the nonce

The response of the Play Integrity API is returned within the type of a JSON Internet Token (JWT), whose payload is a plain-text JSON textual content, within the following format:

{
  requestDetails: { ... }
  appIntegrity: { ... }
  deviceIntegrity: { ... }
  accountDetails: { ... }
}

The nonce might be discovered contained in the requestDetails construction, which is formatted within the following method:

requestDetails: {
  requestPackageName: "...",
  nonce: "...",
  timestampMillis: ...
}

The worth of the nonce discipline ought to precisely match the one you beforehand handed to the API. Moreover, because the nonce is contained in the cryptographically signed response of the Play Integrity API, it’s not possible to change its worth after the response is acquired. It’s by leveraging these properties that it’s potential to make use of the nonce to additional defend your app.

Defending high-value operations

Allow us to contemplate the state of affairs during which a malicious person is interacting with a web-based recreation that reviews the participant rating to the sport server. On this case, the gadget is just not compromised, however the person can view and modify the community knowledge circulation between the sport and the server with the assistance of a proxy server or a VPN, so the malicious person can report a better rating, whereas the true rating is way decrease.

Merely calling the Play Integrity API is just not enough to guard the app on this case: the gadget is just not compromised, and the app is authentic, so all of the checks completed by the Play Integrity API will go.

Nonetheless, it’s potential to leverage the nonce of the Play Integrity API to guard this explicit high-value operation of reporting the sport rating, by encoding the worth of the operation contained in the nonce. The implementation is as follows:

  1. The person initiates the high-value motion.
  2. Your app prepares a message it needs to guard, for instance, in JSON format.
  3. Your app calculates a cryptographic hash of the message it needs to guard. For instance, with the SHA-256, or the SHA-3-256 hashing algorithms.
  4. Your app calls the Play Integrity API, and calls setNonce() to set the nonce discipline to the cryptographic hash calculated within the earlier step.
  5. Your app sends each the message it needs to guard, and the signed results of the Play Integrity API to your server.
  6. Your app server verifies that the cryptographic hash of the message that it acquired matches the worth of the nonce discipline within the signed end result, and rejects any outcomes that do not match.

The next sequence diagram illustrates these steps:

Implementation diagram for encoding the value of the operation inside the nonce. Steps outlined in the body of the blog.

So long as the unique message to guard is distributed together with the signed end result, and each the server and consumer use the very same mechanism for calculating the nonce, this gives a powerful assure that the message has not been tampered with.

Discover that on this state of affairs, the safety mannequin works below the belief that the assault is going on within the community, not the gadget or the app, so it’s significantly necessary to additionally confirm the gadget and app integrity indicators that the Play Integrity API gives as properly.

Stopping replay assaults

Allow us to contemplate one other state of affairs during which a malicious person is making an attempt to work together with a server-client app protected by the Play Integrity API, however needs to take action with a compromised gadget, in a means so the server doesn’t detect this.

To take action, the attacker first makes use of the app with a authentic gadget, and gathers the signed response of the Play Integrity API. The attacker then makes use of the app with the compromised gadget, intercepts the Play Integrity API name, and as a substitute of performing the integrity checks, it merely returns the beforehand recorded signed response.

Because the signed response has not been altered in any means, the digital signature will look okay, and the app server could also be fooled into considering it’s speaking with a authentic gadget. That is known as a replay assault.

The primary line of protection towards such an assault is to confirm the timestampMillis discipline within the signed response. This discipline accommodates the timestamp when the response was created, and might be helpful in detecting suspiciously previous responses, even when the digital signature is verified as genuine.

That mentioned, it is usually potential to leverage the nonce within the Play Integrity API, to assign a singular worth to every response, and verifying that the response matches the beforehand set distinctive worth. The implementation is as follows:

  1. The server creates a globally distinctive worth in a means that malicious customers can’t predict. For instance, a cryptographically-secure random quantity 128 bits or bigger.
  2. Your app calls the Play Integrity API, and units the nonce discipline to the distinctive worth acquired by your app server.
  3. Your app sends the signed results of the Play Integrity API to your server.
  4. Your server verifies that the nonce discipline within the signed end result matches the distinctive worth it beforehand generated, and rejects any outcomes that do not match.

The next sequence diagram illustrates these steps:

Implementation diagram for assigning a unique value to each response, and verifying that the response matches the previously set unique value. Steps outlined in the body of the blog.

With this implementation, every time the server asks the app to name the Play Integrity API, it does so with a distinct globally distinctive worth, so so long as this worth can’t be predicted by the attacker, it’s not potential to reuse a earlier response, because the nonce received’t match the anticipated worth.

Combining each protections

Whereas the 2 mechanisms described above work in very alternative ways, if an app requires each protections on the similar time, it’s potential to mix them in a single Play Integrity API name, for instance, by appending the outcomes of each protections into a bigger base-64 nonce. An implementation that mixes each approaches is as follows:

  1. The person initiates the high-value motion.
  2. Your app asks the server for a singular worth to determine the request
  3. Your app server generates a globally distinctive worth in a means that malicious customers can’t predict. For instance, you might use a cryptographically-secure random quantity generator to create such a worth. We advocate creating values 128 bits or bigger.
  4. Your app server sends the globally distinctive worth to the app.
  5. Your app prepares a message it needs to guard, for instance, in JSON format.
  6. Your app calculates a cryptographic hash of the message it needs to guard. For instance, with the SHA-256, or the SHA-3-256 hashing algorithms.
  7. Your app creates a string by appending the distinctive worth acquired out of your app server, and the hash of the message it needs to guard.
  8. Your app calls the Play Integrity API, and calls setNonce() to set the nonce discipline to the string created within the earlier step.
  9. Your app sends each the message it needs to guard, and the signed results of the Play Integrity API to your server.
  10. Your app server splits the worth of the nonce discipline, and verifies that the cryptographic hash of the message, in addition to the distinctive worth it beforehand generated match to the anticipated values, and rejects any outcomes that do not match.

The next sequence diagram illustrates these steps:

implementation diagram for combining both protections. Steps outlined in the body of the blog.

These are some examples of the way you should utilize the nonce to additional defend your app towards malicious customers. In case your app handles delicate knowledge, or is weak towards abuse, we hope you contemplate taking motion to mitigate these threats with the assistance of the Play Integrity API.

To study extra about utilizing the Play Integrity API and to get began, go to the documentation at g.co/play/integrityapi.



RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments