Certificate Download

Certificate Download

< Back

This document describes, clearly and objectively, how the client certificate (P12) password creation process works in the location SDK.

---

1. Input sent by SDK

Before requesting the P12 certificate, the SDK generates a random value locally:

nonce_app

This value is sent in the request body:

{
  "id": "req_7b31e0c4f8c9431db99a8c87e990abcd",
  "license": "LIC-1234567890",
  "sessionId": "SESSION-55667788",
  "sdkVersion": "2.0.1",
  "osPlatform": "android",
  "timestamp": 1710087513123,
  "data": {
    "nonce": "c3a19e28fdb745cd88b31e109f01d2a7"
  }
}

Values used in password:

Field	Description
nonce_app	Generated by SDK on each request
license	Unique device/user identifier
sessionId	Active SDK session ID
sdkVersion	Current SDK version
osPlatform	Platform (android/ios)
timestamp	Request timestamp

---

2. API response (with server-generated nonce)

Upon receiving nonce_app, the API generates its own random value:

nonce_server

And responds:

{
  "id": "resp_9f2c1c7a4e5b42caa1e1dbe8fab12345",
  "requestId": "req_7b31e0c4f8c9431db99a8c87e990abcd",
  "timestamp": 1710091113123,
  "data": {
    "p12Base64": "MIIK...BASE64_CERTIFICATE...AB",
    "nonce": "48d1e93c85e442ba8f86fb91c96fd28b",
    "expiresAt": 1712693113123
  }
}

This nonce_server serves as the second required part to generate the P12 file password.

---

3. P12 certificate password construction

The password IS NOT transmitted, nor sent by the server.

The password is derived exclusively within the device, combining:

• nonce_app

• nonce_server

• license

• sdkVersion

• osPlatform

• sessionId

• timestamp

All these values are concatenated and used as input for the key derivation algorithm (conceptual example):

password_input =
    nonce_app +
    nonce_server +
    license +
    sdkVersion +
    osPlatform +
    sessionId +
    timestamp

The password results from:

password = PBKDF2(
    SHA-256(password_input),
    salt = nonce_app + nonce_server,
    iterations = 20000,
    keyLength = 32
)

Important note: Above is only the conceptual representation of the process. We do not expose exact implementation details to avoid SDK reverse engineering.

---

4. Why is this method secure?

✔ The server cannot generate the password alone

Because it depends on nonce_app, generated exclusively on the device.

✔ The SDK cannot generate the password without the server

Because the algorithm also depends on nonce_server.

✔ Each generated certificate has a completely distinct password

Even if it is:

• the same user

• on the same device

• with the same license

The nonce changes, and the timestamp also changes.

✔ The password involves unique and contextual information:

• The license (a device/user identity)

• The operating system

• The SDK version

• The current session

• The timestamp sent in the request

This ensures the password is:

• non-reusable

• impossible to predict

• impossible to reproduce externally

---

5. What travels over the network?

Only:

• nonce_app (client → server)

• nonce_server (server → client)

• public request parameters

The password never travels over the network.

---