Release Notes

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 convienent 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 Approvo 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 behaviour 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.

Version 2.9

New Features:

  • AppAttest integration added, allowing iOS apps to leverage AppAttest on iOS 14 and later for a further enhanced level of security.
  • For DeviceCheck, expose the devicecheck-apple-err flag to make it easier to diagnose Apple authentication problems.
  • Registration of iOS apps now shows the Apple Team Identifier extracted from the app metadata.
  • Support for GameGuardian detection on Android.
  • Add an additional optional Magisk detection mechanism using an Android Isolated Process.
  • Provide the new flag no-package-query on Android that is set if the app is unable to query all packages on the system.
  • Provide -addAlert and -removeAlert options for monitoring for a specific email address to be notified about API monitoring failures.
  • Ability to assert an error condition via setUserProperty SDK method, particularly for the case of an unexpected measurement change for offline measurements.
  • Renamed rejection block whitelist to always-pass, and blacklist to always-fail.

CLI Behaviour Changes:

  • App registration removals now assign the registration an expiry time 2 minutes in the future, at which point the registration is actually removed.

Bug fixes:

  • Fixed an Android SDK issue preventing some analysis of memory mapped files (worked around in older SDK versions with a dynamic security update)
  • Fixed an issue on iOS SDK regarding a buffer size limit for internal analysis causing a failure in some apps with a large number of other libraries

Version 2.8

This is a server-side only release and therefore there is no update to the SDK or approov CLI. End user visible changes include:

  • Inclusion of the short configuration for initializing SDKs in the onboarding email.
  • Option to use brew to install the approov CLI.
  • Use of initial as the rejection policy applied to new accounts.

Version 2.7

New Features:

  • Add support for web protection integrations, initially for reCAPTCHA, hCaptcha and FingerprintJS. This allows Approov tokens to be fetched for specific API domains using the protection tokens obtained using these services. A new backend endpoint allows Approov to check these with the 3rd party service and then generate an Approov token if they are valid. This makes it much easier to integrate Approov with backend APIs that are common between mobile apps and single page web applications that make API calls directly from the browser client. The configuration is managed using the new approov web subcommand.
  • Registration now provides a -playSigned option to support registration of Android APKs that will be signed by Google Play when being released.
  • Provide the metrics link in the onboarding email for easy access. Add an approov monitoring -refreshMetricsLink command to revoke and reissue the link if necessary.
  • Added a approov users -sendOnboardingTo option to resend an onboarding code to an existing Approov user email address.
  • Provide an ability to add an app registration based on the app signature and other information captured on a running device, to deal with situations where the original APK or IPA is no longer available.
  • Addition of -bitcodeList, -bitcodeAdd and -bitcodeRemove options to approov sdk for finer grain control of which SDKs are in bitcode mode.
  • New -bitcode option on app registration to select bitcode mode for the SDK used, if this has not been done previously.
  • New pentest role for the purposes of allowing an independent pentester to set device specific policies and to generate example Approov tokens.
  • Bitcode mode usage is now automatically propagated to delegate accounts if registration cloning is used.
  • New approov registration -updateExpiry option to update the expiry of a registration without needing the app package.
  • New wildcard Approov token mode that issues failing tokens on all domains for initial integration checking.
  • New approov sdk -getConfigString to get the initial configuration as a short string to make intial setup easier.
  • DeviceCheck get command now checks the validity of the authorization against the Apple endpoint and provides the error, to help with analysis.
  • The approov device -getInfo <DeviceID> will now only provide information if the device has been added as a custom one to avoid confusion caused by outdated information captures.
  • The approov registration -remove command now accepts a partial registration identifier if it represents a unique prefix of all registrations available.
  • Introduce approov support to provide emergency contact information for Approov paid plan holders. Move to email support for other users.
  • Change CLI output to provide greater emphasis for user confirmations.
  • No longer force a password setup when importing existing management tokens.
  • List all available roles after performing an onboarding approov init.
  • A new approov init remove-all command enables all access roles to be removed.
  • Better information about the reason why account access is not allowed.
  • Enhanced security analysis, especially in the Android SDK.
  • Consistently use the term initial, rather than base, configuration for SDK interface.

Version 2.6.1

SDK only update with minor changes:

  • For Android, use of the SDK down to API level 19 was restored for compatibility with some existing customer apps where it was not practical to increase the minimum API level to 21. However, we strongly recommend that you require API level 21 or above for new Apps using Approov.
  • For iOS, we provided support for the arm64-sim simulator archiecture for using the simulator on new ARM based Macs.

Version 2.6

New Features:

  • New flow introduced for approov account signup, initial installation of management tokens and the password protection of them.
  • Users now receive an onboarding email with a time limited code that can be used on the approov CLI command line, using a new approov init subcommand, to install the required management tokens onto their machine. There is no longer a need to set an APPROOV_MANAGEMENT_TOKEN environment variable, although that option remains. Management tokens are stored in a .approov file in the user’s home directory.
  • Provide a new approov role subcommand for selecting which particular role (such as dev or admin) is required for the succeeding operations. This style is now preferred over the addition of a myadmin.tok option in commands for performing adminstration operations. It is possible to initialize with management tokens from multiple Approov accounts and switch between them using the approov role command.
  • An approov init option allows existing Approov users to import their management tokens to use this role based method.
  • A management token recovery mechanism via email is now supported using a variant of the approov init command.
  • The approov management command has been renamed approov users (although management is still recognized for compatibility). Usability of the options has been improved, making it easier to create and revoke management tokens, which are now described more clearly as user roles. When new management tokens are added using the -add option the recipient is emailed automatically with onboarding information, so there is no longer any need to transfer the management tokens (through a potentially insecure channel).
  • A facility for password protection of management tokens has been added. This prevents any management tokens that are accidentially compromised being used without knowledge of the password. Additional integrity protections are also provided in the channel between the host machine being used for account administration and the Approov cloud. Even if this channel is compromised it is not possible for an attacker to invoke arbitrary operations. Existing users can opt into this facility. Newly issued management tokens will require password protection by default. Users are invited to set a password when they perform the approov init command to install their management tokens.
  • Addition of automation management tokens specifically for inclusion in scripted approov CLI access, such as in CI systems.
  • Introduction of keysets, allowing additional keys to be generated or imported for an account that can be used to sign Approov tokens issued for particular API domains.
    • Ability to select various different signing algorithms, now supported: HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512.
    • Support is included for RSA and ECDSA signing methods using asymmetric cryptography. This only requires the public key to verify that the token was issued by Approov, without risk when using symmetric keys of the signing key being compromised. Backend token checking systems only need to have access to the public key.
    • Options for exporting the keyset keys in JWK or PEM formats. Approov only provides facilities for exporting public keys to ensure the private key cannot be compromised.
    • Private key import option to support BYOK (Bring Your Own Key) usage too if required.
    • Since different API domains may be assigned different signing keys, this allows different signature schemes and keys to be applied to each if required.
    • Ability to select desired key lengths when generating new keys.
  • Customizable rejection policies
  • Approov CLI command to get the current security policy lists all of the individual flags and whether they cause a rejection or not. A short description is also provided for each flag.
  • Daily and monthly email summaries now show the individual flags for the rejection policy.
  • Support for user cutomizable rejection policies, whereby the specific flags that will cause a rejection can be directly controlled.
  • New option to obtain the current ARC token inclusion status, also providing a list of the rejection flags that can be encoded using ARC.
  • Token format improvements
  • Introduction of an audience claim inclusion feature, whereby Approov tokens add the aud field with the domain for which the Approov token was issued. This allows an additional check that tokens intended for one domain cannot be reused for access to different domains (if the backend verifies the aud claim).
  • Introduction of an issuer claim inclusion feature, whereby Approov tokens add the iss field with the account for which the token was issued. Where signing keys might be shared between multiple different Approov accounts, this allows an additional verification that the token was issued from the correct account.
  • Token checking now also shows the algorithm and any key ID for the token.
  • Filtering and reporting enhancements
  • The /token-info API endpoint now also provides the expiry time of the provided token as a UTC readable string.
  • The execution of the special filtered security policy now also includes any probe set on that special device using the -probeURL option.
  • New filter options to set and get a sampling threshold for the devices. This allows this percentage of devices to be subject to the special filtered security policy.
  • iOS XCFramework support
  • Option for getting iOS SDKs in the .xcframework format, which is now the default recommended approach.
  • Option for getting iOS SDKs in a raw unzipped .framework directory.
  • Option to select between either devices or simulator SDKs when getting an iOS .framework or .zip format SDK.
  • SDK enhancements
  • Improvements and generalisations to the detection of cloner apps on Android.
  • Additional app internal memory analysis on for Android to detect the cloaking of dynamically loaded libraries. This has required the minimum Android version requirement for SDK to be increased to Android 5 (API level 21+).
  • Significant improvements to the detection of Magisk Manager Hide on Android, especially for Android versions 9.0 and later. Note that to benefit from the enhanced protection you need to integrate your app with the 2.6.0 SDK.
  • New -unversioned option for registration of Android .aab and iOS .ipa to generate a registration that is not dependent on the version number of the app.
  • API monitoring option to provide notification if endpoints are not accessible or the public key pins on them no longer match the configuration in the Approov account.
  • The hourly, daily and monthly metrics have been simplified to only show the total and app package names for passes. Flags are still shown for failures.
  • General CLI improvements
  • API domain addition and listing now shows the type, algorithm and any key ID associated with the API domain.
  • Updated the format of the JSON used for -getAll and -setAll to also provide the type, algorithm and kid for each API domain.
  • Improve naming consistent in the CLI and documentation to ensure the default token secret is referred to as the account secret key.
  • Option to export the account secret key in a JWKS (in addition to a JWK) format.
  • Option to directly obtain the account secret key used for JWE tokens.
  • Option to obtain the account secret key in plain form for easier interworking with other shell commands.
  • Added SDK subcommand -getConfigOptions and -setConfigOptions to support upcoming SDK feature enablement.
  • Ability to add API domains using the -pinOnly option only for using the Approov pinning facilities without sending Approov tokens.
  • Ability to self manage pins for the Approov channel for accounts with custom settings that send Approov server channel through a proxy.
  • Option to use latest as the device ID when adding a custom device.
  • Option to remove multiple devices in a single command that match a specific user or label.

Bug fixes:

  • Fixed an SDK issue preventing some app internal memory analysis on Android 10.

Version 2.5

New Features:

  • Added new optional Attestation Response Code (ARC) claim to Approov tokens. This will be enabled by default for new accounts, and can be enabled by the Approov CLI for existing account holders. It provides an encoded form of the device properties that the token was issued for, and also whether the token was valid or not. The encoding is such that it is not possible to determine the device properties or status without access to the Approov backend to decode it.
  • Approov CLI command to enable/disable ARC encoding on an account.
  • Added a new method in the SDK to get the ARC encoding for any particular token. This provides the option of displaying the ARC encoding to the user for support purposes.
  • Provide a new API endpoint that can be called directly by Approov account holder backend systems to decode an ARC claim into the device properties that are encoded.
  • Provide a new API endpoint that can be called directly by Approov account holder backend systems to obtain additional information about an Approov token. This also provides an option to report a particular token if there is reason to think it is being misused, or it is believed there has been a token failure in error.
  • Reorganize documentation around Device Properties for improved readability.
  • Provide conjunction filters that match when a set of input filters are matching for a given attestation.
  • Provide a filter option to mark a device as risky if there is a match.
  • Provide a filter option to just reject a device on a filter match without a permanent device ID ban.
  • Provide regular expression support for filtering matching.
  • Make execution of the custom filtered security policy conditional on a filter option to allow finer grain control.
  • Change filtered security policy selection so that an app does not need to continue to execute it once it has been selected once.
  • Support -getInfo filtered option to get the device information for recent devices that matched one or more filters that use a new -captureDeviceInfo flag.
  • Provide a setUserProperty method in the SDK that provides an arbitrary string that can be seen in the device information and is subject to filtering.
  • Support message signing as an advanced option. Provide a primitive in the SDK to sign an arbitrary message with a secret account key that is only transmitted to app instances that pass attestation. Additional CLI options to get, clear and change the secret key used. New Approov token claim indicates if signing is available and the current key.
  • Provide Approov CLI option to list all of the available SDK libraries.
  • Various security enhancements in the SDK, especially on Android with further advanced memory analysis features added.
  • Basic Appium detection for iOS apps.

Bug fixes:

  • Execution time regression in getIntegrityMeasurementProof on Android, related to App Bundle Support added in 2.3.

Version 2.4

New Features:

  • New branding for documentation and monitoring emails.
  • MacOS Approov CLI binary is now notarized with Apple so there are no longer any warnings on first use on Catalina.
  • Android app bundle registration support now includes verity signing algorithms.
  • General support for the banning (and unbanning) of specific device IDs with the approov device commands. It is no longer specific to the user of the Apple only DeviceCheck functionality and can be used on either iOS and Android, and without use of DeviceCheck.
  • Improved DeviceCheck support so that the device check token fetch (which can take several seconds) is only performed on the first invocation of an app after initial installation.
  • Add support for Google SafetyNet via the new approov safetynet commands.
  • New approov device commands to obtain the persisted state for a particular device. Also a command to completely clear all persisted device state for an account.
  • Ability to reinitialize the SDK to support the use of multiple different Approov accounts associated with an app.
  • New delegate management token that can be provided to the developer of an app, with their own Approov account, who is then able to manage registrations in the account.
  • Registration cloning option used in conjunction with the delegate management token to copy permanent registrations from one account to another.
  • Added SDK command to get the list of URLs the SDK may access to make it easier to setup firewall rules when running an app inside a private network.
  • Provide option to set a user specified label for a particular device that has a custom policy.
  • Improved error information from the Approov CLI when attempting to get pins for a domain with an untrusted certificate chain.
  • Ability to specific ports when obtaining certificate chains or leaf pins using the Approov CLI to support API endpoints not served on the normal https 443 port.
  • New live metrics graph showing the causes of rejections and also the current rejection policy that is being applied.
  • Facility for 2.4 SDKs to obtain the pins for the certificate chain as seen by the SDK on a particular device for an arbitrary URL specified by the user in the approov device command set.
  • Capability for 2.4 SDKs to always perform a pinning integrity check when the device ID is first used to verify that the pinning support libraries on the device have not been compromised.
  • Approov CLI device command to get more detailed information associated with a device ID that has had a custom device policy set. This also provides the same information for up to the last 100 new devices added to an account.
  • Approov CLI device command to obtain the stream of device IDs (and timestamps) for up to the last 1000 token fetches performed on the account.
  • Approov CLI filter commands added to perform matching on the attributes of devices fetching tokens, and to show matches in a new graph in live metrics and to optionally ban devices that match.
  • Ability to execute a custom security policy on devices which match one or more filters.
  • Enhanced detection of attempts to spoof the IP address being presented to the Approov cloud servers.
  • Generate warnings from the Approov CLI if pinning to a certificate not supported by iOS pinning implementations.

Bug fixes:

  • Fix issue whereby an app would always show app-not-registered after it has been launched, even if the registration was subsequently added with approov registration (previously the app needed to be relaunched to match the newly added registration).
  • Fix app package name reporting when running in the iOS simulator.

Version 2.3

New Features:

  • Simplified support for Android App Bundles. There is no longer any need to download the base.apk from the Play Store for production registration. It is now possible to register .aab files directly after having added the app signing certificate for your apps.
  • SDK optimizations to improve the latency of token fetching on both iOS and Android.
  • Added detection on Android of cloned multiapps (such as Parallel Space), as these undermine the security of running apps. Cloned apps are now rejected in the standard security policies. Note that this policy is retrospectively introduced in prior versions via an over-the-air update to SDKs.

Version 2.2

New Features:

  • Significant improvements to the hardening of the iOS SDK, especially with regard to attacks using a debugger. The additional debugger defences may prevent you from attaching a debugger at all on a real device during iOS development unless you specifically whitelist the device.
  • Improvements to the detection of Magisk Manager on Android devices. Detection is now possible even when using all manager hide features in the latest (20.3) release.
  • Support for multiple mobile provisioning files in an iOS IPA. The Approov CLI will automatically choose the one relevant for your overall app registration.
  • Availability of the backend API integration example walk-throughs.
  • Detection of the automated launching of an app on Android and inclusion of a flag in the annotations to show this. This can be used to combat some app automation attacks.
  • Introduction of the Approov monitoring service that sends monthly (and optionally daily) email updates on your usage of the service.
  • Email alerts when management tokens you have created are about to expire.
  • New getDeviceID() method in the SDK to obtain the device upon which the SDK is running.
  • Some improvements to the metrics that are collected for the account and accessible through the CLI, approov metrics.
    • SDK metrics now show the Approov SDK ID and architecture that is being used.
    • Certain metrics that simply showed as error previously are now shown more explicitly as fail-bad-request.
    • Fail metrics for hourly, daily and monthly are now restricted to only showing those metrics that are relevant as causes of the failure.
    • App related metrics now show the platform of the app, as either ios or and (for Android).
  • Offline measurements are now restricted to being performed on API domains restricted with encrypted (JWE) tokens, as an additional security precaution.
  • Introduction of the health checking endpoint for a specific account, showing if the primary Approov service is operating normally.
  • Significant improvements to the pinning management commands in the approov command line tool. It is now possible to individually remove and add pins on a specific API domain.
  • New mechanism to signal to a running app that the latest pin updates provided in an updated configuration must be applied. This is for app integrations that are only able to set the pins during the startup of the app. This allows the app to be signalled that it must update its pins, even if that means prompting the user to allow an app restart. An additional isForceApplyPins property is provided on the token fetch result to support this and a new approov CLI command can initiate the force action.
  • The approov policy -get option is enhanced to provide more detailed description of the different aspects of the currently selected security policy.
  • The range of approov secret -get options are expanded to get the secret in base64, base64url or JWK format. An option is also provided to restrict a new secret to printable characters and to retrieve that form. This is required for some JWT libraries that are unable to accept secrets containing non-printable characters.
  • A new facility is provided whereby a keyID can be set for the Approov tokens in the account. This is included in the kid header of JWS tokens. This allows easier integration for certain backend token checking systems.

Bug fixes:

  • Fix issue with approov CLI when using the approov devicecheck -add command and a certificate path not in the current directory.
  • Fix problem whereby some requests that failed due to very poor connectivity were showing as sdk-result-no-approov in the SDK metrics.
  • Correctly handle approov token -check for loggable tokens on Windows, whereby the single quotes suggested in the documentation where insufficient.

Version 2.1

New Features:

  • New account level metrics facility showing both live, hourly, daily and monthly metrics on the usage of the account. This provides insight into the reasons for any attestation rejections, the status of different app versions being run and the total usage on the account. The dashboards can be reached using the new approov metrics command. This new facility is designed to replace the graphs previously available using the approov usage, although these remain available but will be removed in a future release.
  • Capability to ban particular iOS devices using the Apple DeviceCheck facility. This is setup using the new approov devicecheck command.
  • Ability to fetch Approov tokens when running on the iOS simulator.
  • Direct control over the stance regarding the collection of end user IP addresses and their inclusion in the Approov tokens. The IP tracking settings are available in the approov policy command.
  • Enhancements to the obfuscation of the SDK code to further protect against reverse engineering.

Version 2.0

New Features:

  • New SDK architecture allowing dynamic updates of runtime app threat analysis
  • Various security enhancements in the SDKs and facilities for gathering of threat analysis from live installations
  • Changes to SDK interfaces to create more consistency between the iOS and Android versions
  • Improved error reporting and status logging from Approov token fetching
  • Optimization of SDK network access to reduce number of transactions and size of data transmitted
  • New dynamic pinning approach leveraging standard public key pinning, allowing easier app integration and availability of pins on app startup without network access
  • Range of administration tool features to gather and manage public key pins
  • Over the air secure updates to pins and Approov networking rules
  • Migration to a new command line tool for administration of accounts
  • Support for registration of iOS and Android apps across all OS platforms (no dependency on Android Studio or iOS Xcode installation)
  • Option for single command deletion of multiple unused app registrations
  • Direct user administration of security policies
  • Per device setting of security policies and pinning modes, including blacklisting and whitelisting specific devices
  • Access to latest SDKs via administration tool with upgrade messages when new versions available
  • Facilities for creating example Approov tokens for testing
  • Facilities to check the validity of particular Approov tokens
  • Facilities for generating customized long lived Approov tokens
  • User issuance and revocation of management tokens to administrate the account
  • Option for user initiated update of Approov token secret
  • Support for encrypted (JWE) Approov tokens
  • New offline measurement mode functionality to allow attestation of app to a remote device when neither is Internet connected

Version 1.12

New Features:

  • Added payload capability to add your content to the generated token

Fixes:

  • Change Android APK registration to avoid the v2 signing block while generating the app signature. This makes new registrations work with the soon-to-be-released Google Play signing behaviour

Version 1.11

New Features:

  • Architecture banning
  • Emulator detection
  • SDK hardening

Version 1.10

New Features:

  • Man in the Middle detection
  • Improved rooted device detection
  • Detect function hooking frameworks
  • Android 8 (Oreo) support
  • New ‘did’ token claim containing device ID.

Deprecations:

  • The fetchApproovToken() and fetchApproovTokenandWait() interfaces without URL/hostname parameters are deprecated on all platforms. You should now supply a valid hostname string or null when fetching a token.
  • The ‘ad’ token claim is now obscolete.

Version 1.9

New Features:

  • Internal SDK library improvements

Version 1.8

New Features:

  • Time limited registrations
  • Removed dependency on external tools for registration
  • Admin Portal support for Safari browsers on macOS/OSX
  • Bug fixes for Admin Portal on Microsoft Edge browsers
  • Deprecation of app-repackaging support in Android and iOS SDKs
  • Client side bug fixes and stability improvements

Version 1.7

New Features:

  • Failover mechanism on both server and client side enabling more robust service
  • Client side bug fixes and stability improvements

Version 1.6

New Features:

  • Breaking change: New callback-based API for Approov token fetch notifications in Android and iOS clients
  • Synchronous Approov token fetch API in Android and iOS clients
  • Client-side iOS support for iOS 10, Xcode 8 and Swift 3

Version 1.5

New Features:

  • Server-side bug fixes, stability and performance improvements

Version 1.4

New Features:

Improve Android notification mechanism, alter registration mechanism so that registration of BroadcastReceiver is done via the ApproovAttestation class Server-side bug fixes, stability and performance improvements Known Issues:

Version 1.2

New Features:

  • Health Check API added
  • Server-side bug fixes, stability and performance improvements

Known Issues:

  • Token Intents are broadcast globally

Version 1.0

Initial version