Protecting With AppOnChip

Sentinel LDK Envelope incorporates AppOnChip protection to significantly increase the security of an application that is protected with a Sentinel HL (Driverless configuration) key.

Currently, the following limitations apply for the application to be protected using AppOnChip:

>AppOnChip protection cannot be applied to applications and DLLs that are already protected with tools from other vendors or sources.

NOTE    

>An application that is protected using AppOnChip is not compatible with Sentinel SL keys or with any HL keys other than Sentinel HL (Driverless configuration) keys.

>AppOnChip does not include the integrated performance profiling mode that is provided when protecting a Windows application with AppOnChip. Performance profiling must be performed using an external 3rd-party utility.

How does AppOnChip work?

Once enabled, AppOnChip uses a code transformation engine to analyze the application code. AppOnChip determines which functions are eligible to be executed by the Sentinel HL key. The eligible functions are indicated in a table on the AppOnChip tab in the Sentinel Envelope interface.

Envelope examines all the functions that are compatible with AppOnChip protection and uses advanced heuristics to select by default those functions that will provide the best increase in security with the least impact on performance.

NOTE    If a time-critical function is protected with AppOnChip, this could lead to a significant drop in performance for your application. The reason is that the extracted code is executed inside the secure environment of the Sentinel HL key. To accomplish this, the HL key must perform the same calculation as the native processor. However, the Sentinel HL key cannot match the level of performance that is provided by the native processor. Thales recommends that you avoid the protection of time-critical functions.

Thales recommends that you use any means of profiling to identify suitable functions to be protected with AppOnChip. Criteria for protection should be the count of the function call and the complexity of the function

You examine the list of eligible and selected functions, and modify the selections to include only those functions that you want AppOnChip to protect.

When Envelope generates the protected application, AppOnChip automatically extracts the code for selected functions from the protected binary of the application and replaces the extracted code with a placeholder. The extracted code is encrypted and signed with a vendor-specific sign key, and saved as part of the protected application.

The protection process is fully automatic. It is not necessary for you to make any changes to your application code to accommodate this process.

At run-time, when the application calls one of the protected functions, the encrypted function code is uploaded to the Sentinel HL key. Within the key, the code is decrypted, loaded into a virtual machine, and then executed. The output of the code is passed back to the protected application through the placeholder that was inserted into the function during the protection process.

As a result of this process, protected functions are never exposed in any manner that would enable a cracker to analyze or disassemble the code.

The Sentinel HL key can only contain the code for a single function at any given time. When a protected function is called by the application:

>If the function code is currently present in the HL key, the code is executed immediately.

>If the function code is not present in the HL key, the code is uploaded to the HL key, decrypted, and executed. The uploaded code replaces the code that was uploaded previously.

How do you select functions to be protected?

Review the list of functions that are available for protection using AppOnChip.

AppOnChip provides significant protection when you implement it correctly to create a strong binding between the application logic and the HL key. To achieve optimum security, be sure to implement the following recommendations:

>Apply AppOnChip to a large number of functions. This increases an attacker's effort and also increases the odds of covering the recommendations that follow.

>Use AppOnChip to protect functions that are really necessary for the application's core purpose. There is little benefit in protecting secondary functions (for example: licensing, phone home). Your main objective is to force an attacker to really attack AppOnChip instead of just disabling the calls to the AppOnChip-protected functions.

>Use AppOnChip to protect functions that process user data and not just constant data. Functions that process unchanging data can be defeated using a replay attack.

>Use AppOnChip to protect functions that have not been released with a previous version of your application. Otherwise, an attacker could reconstruct AppOnChip snippets by taking the code from a previous release.

Select the functions that you want protect. To achieve an optimum balance between performance and security for the protected application, consider the frequency with which the function is called.

When you choose which functions should be protected, pay attention to recursive functions and to functions that are called within loops.This becomes especially important when you enable concurrency, and the protected application is licensed using a Sentinel HL network key. Multiple instances of the protected application will be calling different functions at the same time.

Use the Performance Profiling mode to evaluate the impact on performance for your selected functions.

How is the Sentinel HL key for AppOnChip selected?

The Sentinel HL keys that contains the license used by the protected application is not necessarily the same key that is used by AppOnChip to run the encrypted function code.

In the protection details for the protected application, you select the Protection Key Search Mode. This setting determines where the protected application searches for a protection key that contains a license for the application - on a local key, a remote key, or both.

AppOnChip only selects a key with the same Batch Code that was used to protect the application.