Clone Detection for Physical Machines
This section provides a detailed description of the clone protection schemes that are available to protect again the cloning of physical machines.
Platform Default Scheme
The Platform Default scheme instructs Sentinel LDK to automatically apply the most appropriate clone protection scheme for each end user based on various parameters. For details, see Using the "Platform Default" Scheme.
PMType1 Scheme
The PMType1 scheme uses two components to verify fingerprints: hard drive serial number and motherboard ID.
If either the hard drive serial number or the motherboard ID does not match the characteristics in the fingerprint in the secure storage, Sentinel LDK License Manager still allows the protected software to operate. Sentinel LDK recognizes that situations occur where an end user has a legitimate reason for replacing one of these components in the user’s computer. This policy possibly enables a user to operate protected software on a cloned computer. However, this policy also frees the Vendor from dealing with numerous support calls from users who have replaced a component in their computer. Such calls would otherwise generate costly support cases for the Vendor’s customer support organization.
If both the hard drive serial number and the motherboard ID do not match the characteristics in the fingerprint of the license, Sentinel LDK regards computer as a clone and prevents the protected software from operating. (See the table that follows.)
| Characteristics Compared | Comparison Results | |||
|---|---|---|---|---|
| Hard drive serial number | Identical | Different | Identical | Different |
| Motherboard ID | Identical | Identical | Different | Different |
| Sentinel LDK Behavior: The software is... |
Launched | Launched | Launched | Disabled |
Supported operating systems: Windows, Linux, and Macintosh
PMType2 Scheme
The PMType2 scheme uses various components such as CPU, ethernet card, optical drive, PCI card slot peripherals (for example: display, storage, network, multimedia) along with the hard drive serial number and motherboard ID to verify fingerprints on a physical machine.
Each component that makes up the reference fingerprint is assigned a weighted value. Sentinel LDK performs the following computations:
>A = total for the weighted values of all components in the reference fingerprint.
>B = total for the weighted values of all components in the system fingerprint that match components in the reference fingerprint.
>matching percentage = (B/A) * 100
Sentinel LDK computes a required percentage based on the level of agreement that is found between the hard drive serial number and motherboard ID in the reference fingerprint and in the system fingerprint.
If the matching percentage reaches the required percentage, the protected application is allowed to execute.
NOTE Thales recommends the use of PMType2 over PMType1 because PMType2 is a more advanced scheme that provides better reliability and security.
PMType3 Scheme
The PMType3 scheme is specifically for Android applications.
The requirements of the PMType3 scheme are:
>The internal storage serial number must match the characteristics in the fingerprint in secure storage.
>If the internal storage serial number is absent, the CPU information must match the characteristic in the fingerprint in secure storage.
If the protected application is re-installed on the user's device, the user must send a C2V file to the vendor and receive a new V2C file in return in order to activate the product license.
NOTE PMType3 is a legacy clone protection scheme. Thales recommends that you use PMType4 instead. PMType4 is not disruptive if app re-installation is required, and it provides the same level of security and reliability as PMType3.
The table that follows describes the requirements of the PMType3 scheme in detail.
| Characteristics Compared | Comparison Results | |||
|---|---|---|---|---|
| Internal Storage serial number | Identical | Different | Absent | Absent |
| CPU information | Not relevant | Not relevant | Identical | Different |
| Sentinel LDK Behavior: The software is... |
Launched | Disabled | Launched | Disabled |
PMType4 Scheme
The PMType4 scheme is a more advanced scheme for Android applications. This scheme uses the Android ID as the primary factor in checking for clones. When available, the internal storage serial number, the Android serial number and Android first boot time are also used.
(For Android 10 and later, due to platform restrictions, only the Android ID is available.)
This scheme allows for situations where the end user uninstalls and then reinstalls the protected application.
Typically, after a reinstall, the user is required to request a new V2C file from the vendor to re-enable the license for the application. This is required because some licenses may restrict the number of executions or may be time-restricted based on the installation date.
With the PMType4 scheme, if the license is perpetual or is time-restricted based on an absolute expiration date, a new V2C file is not required. As a result, both the vendor and the customer are saved the effort of resolving licensing issues unnecessarily.
The table that follows demonstrates the requirements for the operation of an application that is protected using the PMType4 scheme.
| Characteristics Compared | Comparison Results | ||||||
|---|---|---|---|---|---|---|---|
| Android ID | Identical | Different | Absent | Absent | Absent | Absent | Absent |
| Internal Storage serial number | Not relevant | Not relevant | Identical | Different | Absent | Absent | Absent |
| CPU information | Identical | Not relevant | Not relevant | Not relevant | Identical | Identical | Different |
| Android serial number | Not relevant | Not relevant | Not relevant | Not relevant | Identical | Not relevant | Not relevant |
| Android first boot time | Not relevant | Not relevant | Not relevant | Not relevant | Not relevant | Identical | Not relevant |
| Sentinel LDK Behavior: The software is... |
Launched | Disabled | Launched | Disabled | Launched | Launched | Disabled |
FQDN Scheme
The FQDN scheme uses only the machine’s FQDN (Fully Qualified Domain Name) to verify fingerprints on a physical machine. If the FQDN in the reference fingerprint matches the FQDN in the system fingerprint, the protected Software is launched.
Use of the FQDN scheme reduces possible false-positive clone detection that may result from changes to hardware devices. Such changes may be flagged as the result of license cloning to another machine.
The security level of the FQDN scheme is limited, as domains and hostnames can be spoofed. FQDN is useful in scenarios where you trust the users to not attempt to bypass the licensing, but where license compliance is important.
Use of the FQDN scheme is preferred primarily in networks where a domain is used. This is typical in the networks of corporate users. On standalone machines, domains are typically not used; therefore, only the hostname is used for locking.
For higher security, use either of the following:
>SL key with the Platform Default clone protection scheme. This does not require connectivity, but significant changes to the hardware may result in false-positive clone detection.
>Cloud licensing. This scheme is resistant to hardware changes on the client machine but requires at least occasional connectivity.
Custom Scheme
You can define a custom clone protection scheme that includes one or more criteria that you select from the table that follows.
| Criteria | Notes |
|---|---|
| CPU | CPU information. CPU UID is excluded |
| Ethernet address | MAC address |
| FQDN | Fully Qualified Domain Name. Not supported for Android |
| Hard disk | Hard disk ID (on a PC) or SD card ID (Android device) |
| IP address | IP address |
| Machine ID | Motherboard (on a PC) or Android serial number (or Android first boot if serial number is not available) |
| Security Identifier (SID) | Microsoft Windows Security Identifier (Windows machine only) |
You also specify how many of the selected criteria must match when the License Manager validates the license. For example, you can select six criteria from the table, but specify that only three of the six must match in order to validate the license.
You can define custom schemes using either Sentinel LDK-EMS or Sentinel License Generation API.
In Sentinel LDK-EMS, you assign a name for each custom scheme. This simplifies the process of reusing the custom scheme for additional Products.