Skip to main content

Version 3

Version 3.6.0​

A release with server-side and CLI updates (there is no 3.6 SDK). End user visible changes include:

  • Added support for versioned security rules rollout. This allows direct control of the specific security rule versions that are active in an account. It also allows for gradual rollout of new versions to a subset of the devices in the account. To support this the approov secrules commands are introduced to allow management of the security rules versions applied to the account.
  • Updated metrics and summary billing email information to include account types that may be using metered billing only.
  • Added elevated failure monitoring for accounts. This allows an alert email to be sent to the account monitoring and alert recipients if the number of attestation failures in the account rises above a user settable threshold. Elevated failures may be the result of account misconfiguration and this provides an opportunity to respond to issues in a timely fashion. (Additionally an internal anomaly detection capability has also been added. This capability alerts Approov on-call engineers if failure patterns arise simultaneously in multiple accounts accross the Approov estate.)
  • Added management of the account ARC encoding secret using the approov secret -arc command. This allows the active and pending ARC encoding secrets to be viewed, a new pending secret to be staged, the pending secret to be promoted to active, and the archived secrets to be listed so that previously issued tokens can still be decoded.
  • Added retrieval of the account backend configuration using the approov secret -getBackendConfig command. This writes the ARC encoding and key set information, along with the API domains it applies to, to a file for integration with backend systems that decode the arc claim or verify tokens.
  • Added a -type option to the approov keyset -getJWKS and approov keyset -getPEM commands to allow retrieval of either the pass or fail account key set. This supports backend systems that need to verify or decode both passing and failing tokens.
  • Added retrieval of the global ARC flag mappings using the approov policy -getARCFlagMappings command, which writes the mapping of ARC flag values to device property names to a file for use when decoding the arc claim.
  • Extended the approov token -genExample command with -setFlags to include specified device property flags in the example token's arc claim, and -setIPK to include an installation public key ipk claim, to help with testing backend integrations.

Version 3.5.3​

SDK changes only.

  • Improved handling of SDK resumption, to avoid some unnecessary attestations on resumption if there was no explicit Approov token fetch in the previous app launch.
  • Bug fix in Android SDK to correct performance regression related to APK analysis when the app is first launched.

Version 3.5.2​

SDK, server-side and CLI updates.

New features:

  • Improved tracing debug capability in the SDK.
  • To help with debug, the SDK token fetch call now expects the URL parameter to include the target path, not just the domain.
  • Add new -exists and -invert flags to approov filter CLI command.
  • Allow the negation of individual filters within a conjunction filter.

Version 3.5.1​

SDK and server-side updates.

Bug fixes and minor updates:

  • Further optimize app startup and Approov initialization time to reduce the latency of the first token fetch of a session:
    • Add a new InitFetch configuration option for the SDK to perform a full token fetch even if there is no resumption configuration.
    • Broaden the number of cases when the fast app resumption flow can be applied.
  • Add a workaround on Android for slow network layer wake-up when a device comes back from sleep.
  • Improve diagnostic data collection surrounding network performance monitoring from the SDK.
  • Improve the memory dump detection capability.

Version 3.5.0​

SDK and server-side updates.

New Features:

  • The SDK gains a fast resumption capability. This is used if the app has been previously launched and allows the SDK to fetch an Approov token more quickly. The Approov token fetch is performed in the background as part of the SDK initialization call.
  • The SDK now supports multiple calls to initialize if the same parameters are provided - this simplifies cases where initialization may occur in one of a number of flows. Calls to initialize with the same set of parameters after the first are ignored.
  • Further SDK hardening enhancements.
  • The Android SDK is now built with 16kb page alignment in preparation for that requirement rolling out to all Android apps.

Bug fixes:

  • Fixed an issue in the Android SDK that can cause further calls to the SDK to be blocked for a period. Previously, this could cause an ANR in very unusual circumstance: if a Play Integrity token was being fetched while an unrelated call was made to the SDK from the main UI thread.

Version 3.4.1​

Android SDK bugfix only; to deal with an issue creating installation key pairs on a small number of devices.

Version 3.4​

SDK, CLI, and server-side updates.

New Features:

  • Introduce installation message signing as a new capability on both Android and iOS. This causes a secure key pair to be generated when the app integrating the Approov SDK is first run after installation. The Approov server checks to verify that the app installation has possession of this key in subsequent Approov token fetches. A new getInstallMessageSignature SDK method allows an arbitrary message to be signed using the private key. The public part of the key pair may be optionally included in Approov tokens issued for the installation.
  • Rename the SDK method getMessageSignature to getAccountMessageSignature to differentiate its function from the new installation message signing feature.
  • Implement key attestation for Android whereby the installation key pair is attested to verify if it is being held in trusted secure hardware. Options are provided so that valid key attestation can be mandated in order to receive valid Approov tokens.
  • Added new approov token options -setInstallPubKey and -getInstallPubKey to enable or disable the inclusion of an installation public key in Approov tokens.
  • The captured device information is extended to optionally capture the additional fields boot-key (the key used to verify the boot process) and boot-hash (the verified boot image digest). These are only available on Android devices that have completed hardware key attestation.
  • Option flags require-install-key, require-android-tee and require-certified-key-attest are added to provide controls around the requirements for key attestation.
  • Added new approov token options -addAnnotateFlag and -removeAnnotateFlag to enable individual device property flags to be customized for inclusion in the Approov token anno claim, showing some properties of the attestation.
  • Added new approov token options -addOptionFlag and -removeOptionFlag for the enabling and disabling of individual specific options controlling the attestation process.
  • Extend the approov token -get command to provide information about option flags, as well as public device property flags.
  • Added a new memory dump detection capability on Android. This detects any attempt to dump memory, and prevents valid Approov tokens being issued to the device if so. An option flag crash-on-memdump is also provided to allow the app to crash immediately if this is detected.
  • Add a new application installation attributes facility. This allows a signed JWT to be passed to the running app instance from a backend service. This can then be set in the SDK using the new setInstallAttrsInToken method. If the JWT is valid then the payload information supplied will be provided in the embed claim of Approov tokens issued to that app installation. The new CLI subcommand approov installattrs is introduced to create and manage the signing keys associated with installation attributes JWTs.
  • Provide the device state obtained with the DeviceCheck integration directly in the Approov token, to allow this mechanism to be more generally useful.
  • Add a capability to update the DeviceCheck device state via the new installation attributes capability.
  • Rename the approov devicecheck command option -bits to -banBit to more precisely specify its revised operation.
  • Change the Approov token sub claim (if enabled) to also include the app package name as well as the device ID.
  • The individual option flags require-appattest, require-devicecheck and require-playintegrity are introduced as a replacement for the previous strict rejection policy. This allows much finer grain control of requirements around these capabilities.
  • Add the capability of options: to be passed to the SDK initialization to change the device ID and disable install keys if required.

Maintenance Changes:

  • Android SafetyNet support is completely removed as this is now fully deprecated by Google.
  • -bitcode option is removed from approov registration as this is no longer necessary as bitcode has been deprecated by Apple.
  • -bitcodeAdd, -bitcodeRemove, -bitcodeList options are also removed from approov sdk due to the Apple bitcode deprecation.
  • -banMode option is removed from approov device along with device banning via custom devices and Apple DeviceCheck. (This capability is still available from the approov forcefail command.)
  • The documentation around the-ban option on approov filter has been changed to make it clearer it only bans a particular installation of an app.

Version 3.3​

SDK optimizations, CLI command updates, and server-side updates.

  • The SDK on all platforms now performs a configuration check when the SDK is initialized. This involves a background network request to avoid extra latency on the first token fetch.
  • Android SDK startup and initial attestation performance improvement: apps registered with developer certificates or directly as .aab packages have a significant speed boost to the package integrity check that is performed on the first attestation of a session (up to 12x). APK registrations have no performance issues.
  • iOS SDK update to improve handling of apps with a large number of dependencies.
  • Improved iOS and watchOS SDK hardening.
  • Better handling of multiple accounts by the Approov CLI, including the ability to specify a display name for accounts that you administer.
  • Get account overview information from the Approov CLI; this reports on various limits associated with your account.
  • Server changes in preparation for upcoming feature announcements. The visible changes include minor alterations to the presentation of metrics to support future rollout.

Version 3.2.1​

Android SDK only update with the following changes:

  • Improvements in the detection of the verified boot status of Android devices to categorize as rooted.
  • New SDK option to prestart the isolated process on SDK initialization to reduce the impact of its startup latency on the first token fetch.
  • Increase the timeout period for the isolated process startup which helps detect the presence of Magisk.
  • Addition of dev-settings-enabled flag on Android to indicate if developer settings are enabled on the device.
  • Addition of adb-enabled flag on Android to indicate that ADB access to the device has been enabled.
  • Addition of installer-not-play-store flag on Android to indicate app was not installed through the official Google Play Store.
  • New KernelSU detection for Android, asserting kernelsu flag if it is detected on the device and SuperUser is enabled.

Version 3.2​

New Features:

  • Introduction of much more flexible app registrations options. This allows app signing certificates to be added to the account for either Android or iOS and these can be marked as "auto-registering" so that any app signed with the certificate will be registered automatically, with no need to register each app version upon release.
  • App signing certificates can now be added in JKS or PKCS12 format directly for Android, allowing Android Studio key store files to be used directly. For iOS x509 DER certificates (as downloaded from the Apple developer portal) may be added directly.
  • PEM encoded app signing certificates are now also supported directly, allowing direct use of Huawei AppGallery certificates.
  • Specific app signing certificates may be marked as being used for development. In this case, attestations pass without needing to add the device ID to the account. This makes development much more convenient when using Approov. Note that this feature cannot be used with iOS simulator builds since they are not signed. Moreover, care must be taken to ensure all Android builds are signed when running directly from Android Studio. This is covered in more detail in the documentation.
  • Suppression of failing live attestation metrics and billing accumulation for attestations marked as development. This prevents these metrics from being polluted by development work.
  • Introduction of a new app development key option via approov forcepass, which may be set in the SDK after initialization. If the correct key is present then attestation is always passed for those builds of the app. This is useful when testing app versions in a device farm environment that resigns apps before running them. Previously, app attestations in these environments always failed. The command approov forcepass -changeDevKey can be used at any time to change the development key and therefore defend against mistakenly leaked keys being used to obtain valid Approov tokens from production apps.
  • Introduction of approov forcepass to force particular device IDs to always pass attestation. This can be used more easily than the previous approov device option to add custom devices with an always-pass option, and the limit on the maximum number of devices for this option is much higher. This is especially useful for adding the device ID of iOS simulators.
  • Introduction of approov forcefail to force particular device IDs or specific app versions to fail attestation. This can be used in conjunction with the app signing certificate auto-registration to retire old versions of an app by forcing them to fail attestation.
  • Change the flag new-did to new-install to more accurately reflect the meaning of the flag. Note this impacts the approov device -getInfo new-did command which is renamed approov device -getInfo new-install. Also approov filter -newDIDOnly is renamed approov filter -newInstallOnly.
  • Add watchOS as a new supported platform. The approov registration command is enhanced with a -watchOS option to register a watchOS app embedded within an iOS app.
  • Significant hardening improvements to the SDK including various new static and dynamic anti-tamper measures.
  • New detections added for Zygisk within Magisk for Android. This also includes new detections for ZygiskFrida which installs the Frida gadget directly using Magisk.
  • New detections for the DobbyHook intercepting framework on Android.
  • Enable managed trust roots by default for all new Approov accounts. Change to the Approov CLI to ensure that continuous API monitoring can also be applied in the case where managed trust roots is enabled.
  • Add new approov pin -addLeafPin command to add a leaf pin directly to an API domain configuration.
  • Enable secure strings by default for all new Approov accounts.
  • Use the default rejection policy in all new accounts. The initial policy which was the old policy applied to new accounts is still available but is now deprecated.
  • Add an approov registration -checkSigType command to verify that a particular APK is using a V2 or later signature scheme and can thus be used with app signing certificates.
  • Updates to the CLI commands related to the Fingerprint web integration to reflect their latest naming convention changes.
  • Removal of bitcode for new SDK releases since this is no longer supported by Apple.
  • Removal of 32-bit ARMv7 support for iOS and increase of the minimum supported iOS version to 12.0.
  • Ensure that bitcode enablement can only be applied to SDKs which include the bitcode representation.
  • Consider all Android x86 Approov SDKs as being emulators. Previously a small number of special 32-bit x86 devices were categorized as being valid for attestation.
  • Improvements to the latency of attestations, especially those performed using attesters geographically located outside of Europe. This has a small impact on attestations performed using 2.7 and earlier SDKs, in that the new-install flag will no longer be asserted for those. Moreover if SafetyNet or DeviceCheck integrations are being used with these SDKs then this analysis will be repeated each time the app is relaunched.
  • Introduction of attesters in Asia (Singapore) and South America (Sao Paulo) to lower overall attestation latencies for customers in those regions. These join the existing attesters deployed in Europe (Dublin) and North America (Northern California). All deployments are multi-AZ autoscaling deployments.
  • Remove the redundant approov device -getDeviceState option.

Bug fixes:

  • Fixed issue in previous iOS SDKs whereby attestations could fail in the context of some React Native apps when a very large number of mapped memory regions were created.

Version 3.1​

New Features:

  • Addition of Play Integrity API integration for Android devices. This new Google protection replaces SafetyNet and allows measurement of the app and device integrity. You may choose to use this to provide an additonal layer of protection over the existing Approov capabilities. Approov manages the collection of Play Integrity tokens and their checking on the backend, providing you with the standard valid Approov tokens or transmission of runtime secrets to indicate that Play Integrity checks have been passed. Approov is able to remember the integrity state to avoid the latency or quota usage of very frequent Play Integrity attestations.
  • New approov registration -appex option to register any iOS app extensions.
  • Improved approov sdk -getAccessedURLs option to also show URLs used when the app is launched for the first time.
  • Added approov sdk -getClientPackage option to obtain Javascript packages for the web protection integration options.
  • Improvements to Android framework detections, including new detections for Riru and EdXposed.
  • Improved Android Magisk package detection for the latest versions when QUERY_ALL_PACKAGES is available.
  • Improved debug detection mechanisms on iOS.
  • Enhanced app signature analysis for iOS to detect certain ways of installing a modified app, including TrollStore.
  • New signature analysis capabilities allowing better detection of certain hooking frameworks.
  • Implement deletion of app instance secure strings if the new definition is provided as the empty string.
  • Change loggable tokens to have a status claim instead of an error claim, as some statuses are valid and the use of the word error can be confusing.
  • Change the output of approov token -check to be formatted more clearly, and provide times in a human readable format.
  • Add options to include an issued-at ("iat") and subject ("sub") claims in Approov tokens as these are needed for some backend API integrations.
  • Support for JWKS URI allowing the public keys in the keyset to exported on an endpoint to be used to obtain the public keys for a relying party. This is necessary for certain types of backend API integration.
  • Show any custom monitor port in the approov api -check command.
  • Option to send a monitoring test email with approov monitoring -sendTestEmail.
  • Improved message from approov CLI when it is unable to contact the Approov cloud due to a TLS intercepting firewall.
  • Improved email format and information for API monitoring failures.

Bug fixes:

  • Fixed issue in 3.0 SDK whereby forceApplyPins could potentially be asserted in the case of NO_APPROOV_SERVICE / noApproovService and this could prevent apps making connections for some quickstarts if pins had not been previously downloaded (i.e. for new install apps).
  • Fix the SDK version metrics to not include incorrectly reported versions when using an iOS SDK prior to version 3.0.0. These are now reported as unknown.

Version 3.0​

New Features:

  • Addition of fetchSecureString / fetchSecureStringAndWait methods in the SDK to allow storage and retrieval of persisted strings that are only accessible if the app has passed the standard Approov checks. New Approov CLI secstrings subcommands also allow the definition of predefined strings that are available to all app instances.
  • Addition of fetchCustomJWT / fetchCustomJWTAndWait methods in the SDK that allow a JWT to be fetched with a provided payload. If the Approov checks pass then a short lived valid JWT is provided. This is particularly useful for OAuth2 Dynamic Client Registrations where the custom JWT can be used as the software statement to prove the request is being made from a valid app instance, running in a valid environment. New Approov CLI customjwt subcommand to administer this feature.
  • Addition of a getRejectionReasons() / rejectionReasons response for fetching operations. If enabled, this provides a list of the device properties that are causing the app to fail Approov attestation. This can be used to provide more immediate feedback to the user if desired.
  • New managed trust roots feature. This allows an API channel to be protected so that connections must be to a certificate in a chain leading to a recognized root certificate. This provides a way to protect against MitM attacks (using a self signed certificate) without having to pin to a particular certificate. This is useful for scenarios where the backend API is not controlled by the Approov customer, so they are unable to use the existing pinning facilities.
  • Rename the -pinOnly option, when adding API domains, to -noApproovToken to better describe the behavior with the addition of managed trust roots.
  • Option to use auto for the update configuration during SDK initialization. This causes the SDK to manage the update configuration itself using persistent app storage. This simplifies SDK integration when this is not covered by a frontend quickstart. The user manual has been updated to use this simpler method.
  • New features to enable internal tracking of app activity for Android, including a new Approov CLI device subcommand option -configOptions to allow setting of tracking on a per device basis.
  • Migrate the pinning test URL features from the Approov CLI policy subcommand to the more appropriate pin subcommand.
  • New detection to determine if an iOS app is actually running on an ARM based Mac.
  • Provide new getPinsJSON method in the SDK that provides the pins as marshalled JSON. This is easier to use in some frameworks that require a bridging layer from the SDK and are unable to export the complex type of the getPins return.
  • The Approov CLI command approov pin -getCertChainPins now always provides the full certificate chain including the actual root pin. Similarly, API monitoring emails provide the full chain if there is a pin mismatch issue.
  • (Version 3.0.1) Grafana dashboards have been reorganized, partitioning live metrics in a more helpful way and renaming dashboards to better describe the contents. Please see the updated Metrics Graphs documentation for more details.

Bug fixes:

  • Fixed issue in 2.9 SDK whereby reinitializing the SDK with a different account on the same device can cause the device to be registered as a new one, and force DeviceCheck, AppAttest or SafetyNet checks to be repeated.
  • Fixed issue with iOS SDK that caused the version to be misreported as the app version number in the SDK Metrics.