How can I stop other driver developers to hacking USB device?

I’m working on a very simple requirement but not finding any perfect solution over msdn or other sites.

I have developed USB driver for custom vendor class product and now customer want to “secure” its USB device in terms of no other driver developers can develop a device driver to access usb device using PID/VID Hardware Ids. Because smart developers can easily develop USB driver based on PID/VID.

I am finding a solution like if I do something in my driver and generate some encrypted tokens and that tokens will only understand my device.
Such a thing is feasible with the Windows USB driver?

I also come across below link,
https://patentscope.wipo.int/search/en/detail.jsf;jsessionid=10EEC8108591BCA21EE287AF07684365.wapp2nB?docId=US236968922&recNum=2661&office=&queryString=&prevFilter=&sortOption=Pub+Date+Desc&maxRec=73796280

On Apr 26, 2019, at 11:39 PM, Bhoomil_Chavda wrote:

I have developed USB driver for custom vendor class product and now customer want to “secure” its USB device in terms of no other driver developers can develop a device driver to access usb device using PID/VID Hardware Ids. Because smart developers can easily develop USB driver based on PID/VID.

It’s not impossible, but why is it a problem? The money comes from sale of the hardware, the driver is given away for free. If someone hacks a driver, they still have to buy the device. It’s a lot of trouble to create a driver for an unknown device. Why would someone go to that trouble? What’s the gain?

I am finding a solution like if I do something in my driver and generate some encrypted tokens and that tokens will only understand my device.
Such a thing is feasible with the Windows USB driver?

Once they have your driver binary, anything in it can be reverse engineered by a suitably motivated hacker.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

It’s just hardware, software, time, and money…right? So, given enough of those things you can make it very, very, difficult for an unauthorized user to access the device.

Nothing is absolute, and the real question is “how secure does it need to be”… do you want to deter kids or state sponsored actors?

Peter

It’s not impossible, but why is it a problem? The money comes from sale of the hardware, the driver is given away for free.
If someone hacks a driver, they still have to buy the device. It’s a lot of trouble to create a driver for an unknown device.
Why would someone go to that trouble? What’s the gain?

It is not always as simple as that…

For example, consider some security-sensitive application. How many times did we have to give “this is just impossible” answer to the posters who wanted to find this or that way to ensure that their apps or drivers could not be spied upon or otherwise hacked by some malware components? This is why one may want to implement the security-sensitive solution as a tightly-coupled
‘device-driver-application’ stack, with the most security-critical components placed in a hardware device so that it cannot get hacked as easily as a 100% software-based implementations may be. The very fact that we are speaking about the USB device somehow suggests that we are dealing with this kind of scenario here.

However, there is still a"small" problem with this approach - if an attacker finds out how the target device gets programmed they may potentially defeat the whole thing without even trying to hack the device itself. Therefore, the OP’s concerns may be perfectly
reasonable in a situation like that. …

Anton Bassov

anton_bassov wrote

security-sensitive solution as a tightly-coupled
‘device-driver-application’ stack, with the most security-critical components placed in a hardware device so that it cannot get hacked as easily

So this is simply a special case of securing end-to-end communication over an open channel.
Two entities: app and something in/behind the device talk over USB.
USB has no built-in encryption like in DHMI and various wireless protocols, so the OP needs to bring their own.
Nothing impossible here, it is very common requirement these days. Customers (paying :wink: always get what they want.

– pa

So this is simply a special case of securing end-to-end communication over an open channel.

In the above mentioned scenario the only insecure part is the communication channel, but both communicating parties are assumed to be secure by themselves. However, please note that everything that happens to be on the side of the host computer is potentially insecure and may be compromised.

One may, indeed, look at it as at the particular case of the communication over an open channel, but in this case the secure parties are, first, USB device itself, and, second, some other entity that may well be located across the network. Everything that lies in between, including an app and a driver, is potentially insecure. The primary reason why the OP may want to do what he asks about may be the prevention of
“man-in-the middle” and other types of impersonation attacks…

Anton Bassov

I am finding a solution like if I do something in my driver and generate some encrypted tokens and that tokens will
only understand my device. Such a thing is feasible with the Windows USB driver?

Well, you can always try something…

For example, you can embed some “secret” data in both your device and in a driver’s code (or data) section. Every time you send data to the device you can calculate, for example, SHA256 hash of the imaginary buffer that contains both data to send and above mentioned embedded “secret” data, and send this hash along with your request, without sending the embedded “secret” data itself. Once the “secret” data is embedded on the device side as well your device can calculate the (sent_data +embedded_data) hash, and compare it to the one that it had received from the driver. In case of a mismatch it will conclude that some unauthorised party is trying to access the device, and abort the whole thing.

The weak point of this approach is that, as long as your driver’s binary is available to the attackers they may simply disassemble it, and impersonate your driver. In order to make their task more complex you can try to obfuscate the whole thing. There are plenty of obfuscation methods and software tools available so that you can choose the one that suits you best.

Certainly, it is not 100% secure - as Peter had pointed out already, everything depends on dedication of the attackers , as well as on time and the resources available to them…

Anton Bassov