Clone Detection for Virtual Machines

This section provides a detailed description of the clone protection schemes that are available to protect again the cloning of virtual 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.

VMType1 Scheme

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.

CPU Characteristics

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 LDK-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.)

		Comparison Results
Characteristics Compared	Virtual MAC Address	Identical	Different	Not relevant	Not relevant
	CPU Characteristics	Identical	Not relevant	Different
	UUID	Identical		Not relevant	Different
Sentinel LDK Behavior: The software is...		launched	disabled	disabled	disabled

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.

VMType2 Scheme

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.

		Comparison Results
Characteristics Compared	Virtual MAC Address	Identical	Different	Not relevant	Not relevant	Not relevant
	CPU Characteristics	Identical	Not relevant	Different
	UUID	Identical		Not relevant	Different
	Rollback Snapshot Detected	No			Not relevant	Yes
Sentinel LDK Behavior: The software is...		launched	disabled

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 locking 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

>Hyper-V Server

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.

VMType3 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.)

		Comparison Results
Characteristics Compared	mainboard_uid2	Different	Not relevant	Identical
	secure_storage_uid	Not relevant	Different	Identical
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.

VMType4 Scheme

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

>CPU characteristics

>UUID

>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.

FQDN Scheme

The FQDN scheme uses only the machine’s FQDN (fully qualified domain name) to verify fingerprints on a virtual machine. 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 false-positive clone detection.

The security level of the FQDN scheme is limited, as domains and hostnames can be spoofed. FQDN is useful in scenarios where you trust that the user will 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
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 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.