Understanding Mosaic's PKI architecture

Mosaic's Public Key Infrastructure (PKI) architecture ensures secure authentication, data integrity, and confidentiality in communications between Mosaic server and mobile SDKs. It uses cryptographic key pairs—public and private keys—to encrypt data, verify identities, and establish trust between user's devices and Mosaic by:

  • Assuring device identity when communicating with Mosaic
  • Assuring authenticator to device identity when using authenticators that utilize data stored on the local device or device-specific authentication

Mosaic leverages both device keys and authenticator keys to sign authentication and assertion messages. Using this model, Mosaic allows disabling or revoking a device or its authenticators on the server side when needed.

PKI for devices: Device binding

To validate a device, Mosaic leverages a unique private/public key pair, issued as a result of device crypto-binding. These are RSA 2048-bit keys generated via standard OS tools for iOS and Android, or Web Crypto for browsers. For example, Apple provides a specific API call SecKeyGeneratePair(), which creates a public and private key.

  • Device binding occurs when the mobile app executes the Register device journey step.
  • The public key is exported to Mosaic, where it is saved in the Mosaic database as part of the actual device record. It enables message validation and non-repudiation during communication with the device.
  • The private key is stored on the device and never leaves it, leveraging the mobile OS's API capabilities, including Keychain (Apple devices) , Keystore (Android devices) , and IndexDB (Web browsers) . The mobile OS APIs will use the most secure storage available based on the device and key type. For browsers, Web Crypto is used for key management and signing operations, ensuring cryptographic security in web environments.
  • After initial device binding, a journey can validate a device by invoking the Is known device step, which sends a challenge to the client side to sign it with the private key.

See also: Device management, Manage devices, Secure device identity.

UserMobileAppMosaic SDK / OSMosaic ServerLaunch mobile app1Registration journey2Collect device data3Check for device ID & derive device ID from Keychain/Keystore4Generate private/public key pair (RSA 2048)5Request signing with device private key6Generate device key ID & store public key along with device key ID7Login journey8Is known device? &sign challenge9Validate device10Device is known11Authenticate12Validate13Complete journey with JWT Token14Grant access15Done16UserMobileAppMosaic SDK / OSMosaic Server

PKI for authenticators

Authenticators utilize the OS ability to protect private keys with biometrics (fingerprint or Face ID). A private/public key pair is generated for the given authenticator, and requires the user to present their biometrics during registration and authentication. This ties the user biometrics into the PKI process.

  • OS APIs on Android and iOS generate a key pair.
  • The public key is exported to Mosaic.
  • The private key is stored securely by the OS, and protected by requiring the user to present their biometrics.
UserMobileAppMosaic SDK / OSMosaic ServerLaunch mobile app1Registration journey2Start registration journey3Request registration4Present biometrics5Generate private/publickey pair (RSA 2048)6Send public key for registration7Store public keyas biometric authenticator8Journey done9Login journey10Start Login journey11Send challenge forbiometric authentication12Present biometrics13Sign challenge with private key14Send signed challenge15validate with public key16Complete journey with JWT Token17Grant access18Done19UserMobileAppMosaic SDK / OSMosaic Server

See also: Register mobile biometrics journey step and Mobile biometrics authentication journey step.

JWT

Upon successful authentication or journey completion, Mosaic issues a JWT (Json Web Token). The token adheres to standard JWT specification and uses a JSON structure that is used for validation and preventing data tampering. The token includes information such as the username, application name, expiration date, and other parameters being passed by the application on the authentication request. The token is signed with RS256 algorithm.

See also: Token reference, Validate tokens, Journey tokens.