Aladdin HASP security dongles, USB-over-Ethernet devices, and licensing frameworks.

If you’ve done virtualization work in an engineering companies, you’ve probably come across a USB hardware dongle. These awful devices are used to ‘secure’ software from unauthorized copying. Software companies love them because they believe that dongles prevent piracy (or make it difficult), and VMware architects hate them because

• they require additional hardware and software to use in a virtual environment
• the additional software is sometimes flaky
• physical elements add a single point of failure and prevent us from using SRM
• they’re difficult to test because our customers need them to use their products, and we need them to test our solutions
• we dislike physical things.

In 2010-2011, the most common type of security dongle in circulation is the Aladdin HASP series. Aladdin HASP is a family of hardware produced by SafeNet Inc (previously Aladdin Knowledge Systems). There are several types of HASP dongles.

• HASP
• HASP4
• HASP Hard Lock (HL)
• NetHASP
• TimeHASP

The most common HASP keys are the HASP4 and HASP HL. The features of these two types differ: amount of onboard memory (used to store entitlements, instructions) and encryption strength. Neither dongle has a battery-backed RTC (real-time clock, typically used to enable time-based software rental). HASP keys can be identified by their translucent and coloured shells. The following are photos of the HASP4 and HASP HL keys.

Dongles: back, and with a vengeance!

As shown above, the form factor cannot be used to accurately identify the type of dongle. HASP4 dongles typically have stickers containing the letters H4. HASP HL dongles typically have an engraving in the reading HASP HL.
Dongles are only half of the problem. The problem is the license software used to drive them. For HASP4 dongles, it’s often FlexNet. For HASP HL dongles, it’s the HASP HL server.
Applications protected with FlexNet and Aladdin HASP4
FlexNet is a licensing framework published by Flexera Software. Vendors license and customize the FlexNet framework to meet their entitlement management requirements. In the majority of FlexNet implementations, machine-specific license files are used to protect applications.
The non-dongle FlexNet license check-out process is illustrated below.

1. Client contacts FlexNet license server and requests vendor daemon port: The FLEXenabled application contacts the license server and asks for the port of the vendor daemon. The FLEXenabled application knows the hostname and FlexNet license server port number from the client license file.
2. Server responds with vendor daemon port: The FlexNet license manager replies with the port of the vendor daemon
3. Client responds with license check-out request: The FLEXenabled application sends a license check-out request to the vendor daemon
4. Vendor daemon reads license file to determine entitlement
5. Server sends accept or reject: The vendor daemon determines whether any valid licenses are available and sends an accept/reject to the FLEXenabled application.

The FlexNet framework supports the use of Aladdin HASP hardware dongles (as well as other dongle types). HASP4 sits on top of the FlexNet framework. This involves an additional step between step 4 and 5. I’ll label these 4A and 4B.

4A. Contact HASP4 server: the vendor daemon contacts the HASP4 server and requests the HASP_ID of all connected HASP dongles.
4B. Dongle check: The HASP4 server contacts all connected HASP dongles and retrieves the HASP_ID. It passes these to the vendor daemon which checks for an authorized dongle.

Applications protected with HASP HL
Aladdin HASP HL is a standalone licensing framework. The license check-out process is illustrated below.

1. Client contacts HASP HL Server: The protected application sends a request for a license check-out to the HASP HL Server.
2. Entitlement check: The HASP HL Server asks the Aladdin HASP HL dongle whether the license check=out is permitted. The dongle determines whether this is allowed and replies with an answer.
3. Response: The HASP HL Server replies to the application.

Okay, enough about licensing frameworks. How do you virtualize a server that has a USB dongle plugged in the back?
To do it, you’ll need a USB-over-Ethernet device. A USB-over-Ethernet device is a network attached USB hub that connect USB peripheral devices to a server over a network. They were typically used as range extenders for USB devices (such as receipt printers, point of sale barcode scanners, biometric readers, manufacturing line control systems) where having a local PC was not practical or secure. Recently, they have been used to connect USB devices to virtual machines.
The following illustration (taken from VMware's AnywhereUSB guide) shows how an AnywhereUSB USB-over-Ethernet device can be used to connect USB devices to a virtual machine.

The advantages of USB-over-Ethernet devices are

1. Dongles with potentially high replacement costs can be secured in datacentre (I worked with a dongle that costed $45,000 to replace. The vendor had a clause in the EULA stating the replacement cost of a dongle was equal to the cost of the license. No joke.)
2. VMs with license servers can be protected with VMware HA and VMware FT – license servers previously didn’t have any HA mechanism.
3. They allows you to virtualize those “final few” servers in datacentre.
4. They are easy to centrally manage and monitor
5. No major architectural changes required.

USB-over-Ethernet devices aren’t without their drawbacks…

1. There is the possibility of potential incompatibility between dongles and USB-over-Ethernet device. These devices aren’t perfect.
2. They introduce another point of failure
3. No USB-over-Ethernet devices on market have redundant power supplies – if you have to do power testing, get ready to lose the device.
4. The cheapest USB-over-Ethernet devices aren’t rack mountable.
5. They require additional drivers in virtual machine.
6. They are difficult to source in Australia: It is important to have hot spare ready or you could potentially be waiting weeks for a replacement. That’s a week of your licensed software being unavailable to users. If you need them, please contact me!

A word of caution: hardware dongles are notorious for being finicky. Working with dongles can be tedious and time consuming. When you find a configuration that works for you, document the solution current state: the USB-over-Ethernet firmware level, the host driver software, the OS and even the hotfix level. Pay careful attention during your patch cycle and ensure that the dongle continues to work after any updates have been applied. There are documented cases of incompatible dongles and servers and there is no definitive hardware compatibility list and determining compatibility is an exercise in trial and error. USB-over-Ethernet devices vendors periodically release firmware updates to improve compatibility, but those same firmware updates could break compatibility. Exercise extreme caution!
USB-over-Ethernet devices
There are a few USB-over-Ethernet devices on the market.

1. Digi AnywhereUSB: these are the most popular device on the market. Use these and your problems will be minimized. If you can’t source the AnywhereUSB…
2. Lantronix UBox: was previously popular. Although discontinued, the UBox is more compatible with certain families of security devices. The device drivers for this software are a little less stable.
3. Belkin Network USB hub: don’t even bother. Support for HASP dongles are hit and miss.

The Digi AnywhereUSB/5. Plug the USB dongle in the front, the network cable in the back, and you’re set.

In my next post, I’ll describe the process for installing these devices in your environment.