Are hardware dongles able to protect your software?

Question

Various software companies distribute their software with hardware security, usually a dongle which must be mounted in order for the software to operate.

I don't have experience with them, but I wonder, do they really work?

What is it that the dongle actually does? I think that the only way to enforce security using this method, and prevent emulation of the hardware, the hardware has to perform some important function of the software, perhaps implement some algorithm, etc.

Answer 1

Clearly Peter has addressed the main points of proper implementation. Given that I have - without publishing the results - "cracked" two different dongle systems in the past, I'd like to share my insights as well. user276 already hints, in part, at what the problem is.

Many software vendors think that they purchase some kind of security for their licensing model when licensing a dongle system. They couldn't be further from the truth. All they do is to get the tools that allow them to implement a relatively secure system (within the boundaries pointed out in Peters answer).

What is the problem with copy protection in general? If a software uses mathematically sound encryption for its licensing scheme this has no bearing on the security of the copy protection as such. Why? Well, you end up in a catch 22 situation. You don't trust the user (because the user could copy the software), so you encrypt stuff or use encryption somehow in your copy protection scheme. Alas, you need to have your private key in the product to use the encryption, which completely contradicts the notion of mistrusting the user. Dongles try to put the private key (and/or algorithm and/or other ingredients) into hardware such that the user has no access in the first place.

However, since many vendors are under the impression that they purchase security out of the box, they don't put effort into the correct implementation. Which brings me to the first example. It's a CAD program my mother was using. Out of the knowledge that dongles connecting to LPT tend to fail more often than their more recent USB counterparts, I set out to "work around" this one. That was around 2005.

It didn't take me too long. In fact I used a simple DLL placement attack (the name under which the scenario later became known) to inject my code. And that code wasn't all too elaborate. Only one particular function returned the value the dongle would usually read out (serial number), and that was it. The rest of the functions I would pass through to the original DLL which the dongle vendor requires to be installed along with the driver.

The other dongle was a little before that. The problem here was that I was working for a subcontractor and we had limited access only to the software for which we were supposed to develop. It truly was a matter of bureaucracy between the company that licensed the software and the software vendor, but it caused major troubles for us. In this case it was a little more challenging to work around the dongle. First of all a driver had to be written to sniff the IRPs from and to the device. Then the algorithm used for encryption had to be found out. Luckily not all was done in hardware which provided the loop hole for us. In the end we had a little driver that would pose as the dongle. Its functionality was extended so far as to read out a real dongle, save the data (actually pass it to a user mode program saving it) and then load it back to pose as this dongle.

Conclusion: dongles, no matter which kind, if they implement core functionality of the program to which they belong will be hard to crack. For everything else it mostly depends on the determination and willingness to put in time of the person(s) that set out to work around the dongle. As such I would say that dongles pose a considerable hindrance - if implemented correctly - but in cases of negligence on part of the software vendor seeking to protect his creation also mere snake oil.

Take heed from the very last paragraph in Peters answer. But I would like to add one more thought. Software that is truly worth the effort of being protected, because it is unique in a sense, shouldn't be protected on the basis of customer harassment (== most copy protection schemes). Instead consider the example of IDA Pro, which can certainly be considered pretty unique software. They watermark the software to be able to track down the person that leaked a particular bundle. Of course, as we saw with the ESET leak, this doesn't help always, but it creates deterrence. It'll be less likely that a cracker group gets their hands on a copy, for example.

Answer 2

Problem description

Let's make a couple of assumptions. Software is divided into functional components. Licenses are for functional components within that software package. Licenses can be based on time, on version or on a number of uses, i.e you may use the functionality until a set point in time, you may the functionality of the version you purchased or some minor derivative of it or you may use it a number of times. There are two main scenarios you have to solve, where an attacker doesn't have access to a license and where he does.

Attacker with no license

The first scenario is where your attacker does not have access to a valid license to your product. This problem is easy to solve. Simply assign a separate encryption key to each of the functional licenseable parts of your software. Encrypt each functional part with the encryption key designed for that part. Now you can distribute your software without worry of someone being able to decrypt functions they have not licensed since you never send them the key.

Attacker with access to license

The second scenario, which is much harder to solve, is when your attacker has a valid license to your software but he either wants to redistribute the functions he has licensed or to extend his license time wise.

Now you need a reliable time source, this can be solved by:

• embedding a public key into a dongle and having the dongle issue a random challenge which must be forwarded to a time server. The time server responds by signing the current time and the challenge and returning it to the client which then sends it to the key and the key then updates its internal clock and unlocks.
• updating the internal clock based on the time it has been plugged into the computer. The USB port supplies power to your dongle all the time while its plugged in.
• updating the internal clock based on timestamps sent from drivers installed on the machine its attached to. Only allow timestamps forward in time. Only allow movement backwards in time if the time source is a remote trusted time server supplying a signed timestamp.

If your license is based on versions you actually have an attacked who does not have access to a license because your key derivation function for the functional unit takes both the identifier of the functional unit and the version of it as input.

Key distribution

So once you have separate keys for each functional unit your licenses basically becomes a matter of distributing symmetric keys so that they can be sent to the dongle. This is usually done by embedding a secret symmetric key in the dongle, encrypting the license decryption keys with the shared secret key and then signing the encrypted key update files. The signed update files are then passed to the dongle which validates the signature on the update, decrypts the new keys with the shared symmetric key and stores them for later use.

Key storage

All dongles must have access to secure storage in order to store license decryption keys, expiration timestamps and so on. In general this is not implemented on external flash memory or EEPROM. If it is it must be encrypted with a key internal to the ASIC or FPGA and signed such that it can not be changed.

Plain text hole

Once the user has a license to your functional component, even if he can't extract your secret key, he can use your dongle to decrypt that functional component. This leads to the issue that he may extract all your plain text and replace the decryption call with a direct call to the extracted plain text. Some dongles cover this issue by embedding a processor into the dongle. The functional component is then sent encrypted over to the dongle which decrypts the component and executes it internally. This means that the dongle essentially becomes a black box and the functional components sent to the dongle needs to be probed individually to discover their properties.

Oracles

A lot of dongles are encryption and decryption oracles which leads to potential issues with Chosen-ciphertext attacks, e.g the recent padding oracle attacks.

Side channel attacks

Besides the oracle issues you also have a lot of concerns with all of the so far well known side channel attacks. You also need to be concerned with any potential but undiscovered side channel.

Decapsulation

Be aware that there are a number of companies in the world who specialize in picking apart and auditing secure chips. Some of the most well known companies are probably Chris Tarnovsky of flylogic, now part of IOActive and chipworks. This sort of attack is expensive but may be a real threat depending on the value of your target. It would surprise me if but a few, possibly none of, dongles today are able to withstand this sort of high budget attacker.

Do they work

Given a dongle which is based on strong encryption, isn't time based since you can not expire encryption keys based on time nor is time an absolute, free of any side channel attacks and executes the code on the chip, yes it will make discovering the underlying code equivalent to probing a black box. Most of the breaks that happen with these dongles are based on implementation weaknesses by the licensees of the hardware licensing system due to the implementer being unfamiliar with reverse engineering and computer security in general.

Also, do realize that even software where a majority of the logic is implemented on an internet facing server has been broken simply by probing the black box and inferring server side code based on client code expectations. Always prepare for your application to be broken and develop a plan for how to deal with it when it happens.

Answer 3

As Peter has indicated, looking at how the dongle is used for security is the starting point to identify the attack vectors. In most cases, the software developers implementing the dongle security is the weakest point.

In the past when I have tested software with dongles, I have used free tools like ProcessMonitor and RegShot to identify simple vulnerabilities to defeat bad implementations of dongle security.

I have seen software that on startup checks for the presence of dongle and then proceeds with its operation without using the dongle until its restarted. In these cases, patching the application with OllyDbg is not that difficult to tell the app to run with full functionality as long as the dongle is NOT plugged in to the system.

I have also seen software that allows a user to click on a button in the software so that the user doesn't have to have the dongle inserted. The software claimed that is an extra functionality like "Remember Me" option. RegShot and ProcessMonitor showed me that a file is written with some information and as long as the file is present in the expected folder, I can run the software on multiple systems without a dongle.

Just because someone uses AES or Hardware Dongles or any XYZ doesn't mean they are secure. All that maters is whether they are implementing those security measure in the right manner assuming that there are now known (or 0-day vulnerabilities) in the security measure.