This section provides a detailed description of the clone protection schemes that are available to protect again the cloning of virtual machines.
Clone detection for software installed on a virtual machine must employ a different technique than that used for physical machines.
The two most important fingerprint characteristics - the physical hard drive serial number and the physical motherboard ID - are not accessible to software running on the virtual machine. Instead, the virtual machine has a virtual hard drive and a virtual motherboard.
On a cloned virtual machine, the characteristics of these virtual components are identical to the source virtual machine. As a result, these characteristics are not suitable for use when creating the fingerprint at the time the protected software is activated or subsequently operated.
The VMType1 scheme relies on three different parameters for verifying fingerprints on a virtual machine: the virtual MAC address, CPU characteristics, and UUID of the virtual image. Each of these parameters is discussed below.
Virtual MAC Address
Each physical network adapter or network card has a unique identifier, but this identifier is not accessible to a virtual machine running on the computer. Instead, each virtual machine is assigned a unique virtual MAC address.
Within a network, each virtual machine must possess a unique MAC address. If a user clones a virtual machine and installs it on a second computer within the same network, working on either the original or the cloned virtual machine will be impractical as the two machines will constantly cause network collisions.
In desktop/workstation environments such as VMware workstation or VMware player, the desktop virtualization software does not expose the ability to virtualize the CPU. This increases the difficulty for a user to bypass the protection by attempting to create a virtual copy of the source computer. A number of CPU characteristics are available for inclusion in the virtual machine fingerprint, including: processor make, model and speed.
Due to the large number of different processors available in the market, the likelihood of two different desktop computers having completely identical CPU characteristics is low.
In centrally managed virtual infrastructures (also called server based virtualization), hardware clusters can be virtualized. In this environment, the virtual infrastructure does not always utilize a single, fixed set of physical hardware resources. Instead, it utilizes a shared pool of resources. For the most common types of clustered environments, where live migration capabilities are typically required, a requirement usually exists for different hosts in the cluster to have identical CPU characteristics. Solutions such as VMware vCenter Server provide the ability to enable CPU masking to improve compatibility for the high availability and fault tolerance virtualization features. CPU masking allows host machines with different CPU characteristics to be used in the cluster, while providing common (masked) CPU characteristics across all hosts in the cluster. Therefore the CPU characteristics do not change when virtual machine migrates across the hosts in a cluster. This enables licensed applications to continue working when migrated from one host to another within a cluster. However, this type of environment is restricted to a limited subset of CPU types. In addition, the migration can only be performed when the target computer contains physical CPU whose capabilities match or exceed the characteristics of the virtual CPU.
UUID of the Virtual Machine
This is used as a means of unique identification of the virtual machine with the majority of virtual machines technologies. The UUID consists of a 16-byte (128-bit) number. Each virtual machine is assigned a different UUID.
When a user makes a clone of a virtual image or copies a virtual machine from one location to another, a new UUID value is generated for the new virtual image or virtual machine.
None of the three characteristics used by this scheme to create a virtual machine fingerprint is absolutely tamper-proof.
The protection against cloning provided by Sentinel LDK for virtual machines is not as secure as the protection provided for physical machines. You have the option of blocking the protected software from running on most popular virtual machines by clearing the Virtual Machine check box in the Define License Terms dialog box in Sentinel EMS.
However, when checking the fingerprint for cloning, Sentinel LDK examines all of these characteristics. If one (or more) of these characteristics does not match the characteristics in the fingerprint of the license, Sentinel LDK prevents the protected software from operating. Thus, the combination of these parameters in the fingerprint provides protection against cloning. (See the table that follows.)
|Characteristics Compared||Virtual MAC Address||Identical||Different||Not relevant||Not relevant|
|CPU Characteristics||Identical||Not relevant||Different|
|Sentinel LDK Behavior:
The software is...
In a typical business environment (where computers in a given location are on the same network), the requirement for a unique virtual MAC address make cloning impractical.
For server virtualization, or virtualized cluster where the cluster is typically managed by the virtualized management solution (such as VMware vCenter), UUID acts as additional deterrent to running a cloned virtual image.
For computers on different networks or computers that are not networked, the likelihood of a cloned virtual machine sharing identical CPU characteristics with the original virtual machine is low.
The method employed by this scheme to protect against cloning of virtual machines is effective for all types of virtual machine software commonly used by organizations.
This scheme provides the same protection that is provided by VMType1. In addition, this scheme prevents attacks (against a protected application) that are based on virtual machine rollback snapshots. The scheme enables the protected application on a virtual machine to detect that a time shift event may have occurred.
The table that follows describes the circumstances under which the protected application is disabled with the VMType2 scheme.
|Characteristics Compared||Virtual MAC Address||Identical||Different||Not relevant||Not relevant||Not relevant|
|CPU Characteristics||Identical||Not relevant||Different|
|Rollback Snapshot Detected||No||Not relevant||Yes|
|Sentinel LDK Behavior:
The software is...
This scheme is only supported under the following circumstances:
>Run-time Environment v.7.5 or later is present on the virtual machine where the protected application is running.
>The license type is SL AdminMode.
The scheme is supported on Windows 8, Windows 10, Windows Server 2012 R2, and later versions of Windows Server, with the supported versions of the following virtual machines:
>VMware Player, Workstation, and ESXi
In addition, the scheme is supported on certain earlier versions of Windows with Hyper-V Server if Hyper-V integration services from Windows 8 or Windows Server 2012 is installed.
For more information, see: https://msdn.microsoft.com/en-us/library/jj643357(v=vs.85).aspx
For other virtual machine clients that do not support VMType2, this scheme will be handled as if you had selected the VMType1 scheme.
The VMType3 clone protection scheme provides strong and reliable clone protection for cloud computing services such as Amazon EC2 and Microsoft Azure. This scheme addresses the following situations:
>The scheme ensures that a protected application in a cloud computing service cannot be used if the license is copied from one virtual machine to another.
>The scheme ensures that an SL UserMode licenses is protected against misuse by UserMode secure storage wipeout.
NOTE The VMType3 clone protection scheme is not supported for the SL UserMode enforcement type for Linux platforms.
Prerequisites for use of the VMType3 clone protection scheme:
>The machine for which the license is generated must be a cloud computing service.
>The minimum required version of the Run-time Environment on the target machine is 7.61. (For Amazon EC2, the minimum required version is 8.13.)
>The latest fingerprint of the target machine should contain items mainboard_uid2 and vm_info2. This fingerprint should be obtained after installation of the required version of the Run-time Environment.
>The License Generation library version must be 7.61 or later in order to generate a license with the VMType3 clone protection scheme. (For Amazon EC2, the minimum required version is 8.0.45378.60000.)
| Sentinel LDK Behavior:
The protected application is...
|disabled||disabled (Secure Storage wipeout most likely occurred)||launched|
NOTE Start / Stop / Restart from Azure infra will not be reported as Cloned.
This scheme is intended primarily for Docker containers, but it is compatible with other virtual machines.
When the VMType4 scheme is selected, the characteristics checked are:
>Virtual MAC address
>Hard drive serial number
The values for these characteristics must match in the reference fingerprint and the system fingerprint. If there is any mismatch, the protected application is disabled.
If the FQDN in the reference fingerprint matches the FQDN in the system fingerprint, the protected Software is launched.
The FQDN clone protection scheme provides a solution for virtual machine live migration. It allows the guest virtual machine to freely migrate between different physical hosts, while allowing accurate license enforcement to continue. Virtual machine live migration does not cause the license to be incorrectly marked as cloned (and thus disabled).
>For cloud licensing on a hosted virtual machine (Amazon, Google or Azure), Thales recommends that you use the VMType3 scheme. For cloud licensing on other hosted virtual machines, Thales recommends that you use a custom scheme based on machine ID.
>The FQDN scheme should never be selected for Docker containers if the License Manager service executes inside the container. The fingerprint will contain a random value.
You can define a custom clone protection scheme that includes one or more criteria that you select from the table that follows.
|Ethernet address||MAC address|
|FQDN||Fully Qualified Domain Name|
|VM generation ID||Attribute of a Windows VM that helps to prevent misuse of a VM snapshot|
|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 EMS or Sentinel License Generation API.
In Sentinel EMS, you assign a name for each custom scheme. This simplifies the process of reusing the custom scheme for additional Products.