4

I distribute a client application where I would like to identify a user's hardware specifications when they begin interacting with my server. I am specifically interested in identifying the user's GPU make and model, but I would appreciate hearing techniques applicable to other facets of the hardware such as CPU or RAM.

Users are aware that I seek to collect this information and have consented to its collection. Currently, the client is self-reporting what their hardware specifications are to my server. Most of my users are honest, but we can consider some of them as attackers seeking to lie about their hardware specifications.

My first thought is that I could issue a challenge to the client from the server that requires them to use their GPU in a manner such that I could benchmark it based on the response time, similarly to how GPU mining works. My concern with this approach is that I might not be able to achieve enough granularity to distinguish between GPUs with similar performance.

I know that the attacker in this case has physical hardware access and as such I am in fact hosed as far as perfect identification is concerned. As an example for the intents of this question, if the attacker has the capacity to solve my challenge such that I believe they are using an NVIDIA 2080 Ti when they are in fact using some specialized hardware of equivalent strength, then that is acceptable.

Any tools, techniques, or existing software options that could help me achieve this would be much appreciated. Thank you!

Tim Clancy
  • 41
  • 2
  • 1
    [Scrypt](https://www.tarsnap.com/scrypt/scrypt.pdf) has a memory-hard function that is supposed to be easy to compute when you have the memory, and hard to compute when you have not. Maybe that can be adapted to an algorithm which can prove that the client has a certain amount of memory available. – Sjoerd Aug 07 '19 at 18:36
  • 2
    I don't see an information **security** problem here, i.e. I consider this question as off-topic. Maybe it gets on-topic if you provide a use case why you need to detect the hardware in the first place and show how this is needed in the context of information security. In general: unless you have sufficient control over the clients system you cannot hinder the client to send faked information. – Steffen Ullrich Aug 07 '19 at 19:48
  • @drewbenn we will be maintaining our own results server-side and using that as a source of truth. We still desire to engineer a relatively tamper-proof way of identifying particular hardware, even if only for analytics. – Tim Clancy Aug 07 '19 at 20:29
  • @SteffenUllrich after careful consideration of the many different communities in what I consider to be the highly-fragmented StackExchange ecosystem I decided to ask this in the information security community. I chose to do this because this is the community which I believe has the most familiarity with the perhaps-relevant topic of fingerprinting and the best appreciation for an attacker's capabilities.This is at essence a question reaching out for advice about how I might increase my confidence in data I might be receiving. – Tim Clancy Aug 07 '19 at 20:33
  • I think requiring such a specific security concern to be outlined here is so narrowing in scope as to render this community useless when even the broader question as it is has useful implications for forcing some degree of valid data to be generated even by an attacker. – Tim Clancy Aug 07 '19 at 20:37
  • @Sjoerd thank you for the pointer to Scrypt, I'll certainly look into this. – Tim Clancy Aug 07 '19 at 20:38
  • 2
    @TimClancy: As the question is currently it looks like an [XY problem](https://en.wikipedia.org/wiki/XY_problem) to me. X is the unknown problem you are trying to solve and which might or might not be related to information security. Y is your idea of a solution which involves finding out about the hardware in a way the user cannot fake. I recommend that you don't concentrate too much on finding a solution to Y since there is no foolproof one as long as you don't control the users system. Instead provide more information about the problem X you are trying to solve with Y. – Steffen Ullrich Aug 07 '19 at 21:05
  • The problem X is as stated: I want to identify the user's hardware specifications. This is not the solution Y to an unknown problem X, this is in and of itself the problem. This information is not strictly necessary for the functioning of my app but I would like to be able to have this information available for the sake of analytics with some reasonable sense of confidence in its reliability. I don't need a foolproof solution, I just want to find some way of at least binning the attacker's performance into a best-guess of what their hardware is; mining indicates some solution exists to me. – Tim Clancy Aug 07 '19 at 21:12
  • 1
    @TimClancy: *"... I would like to be able to have this information available __for the sake of analytics__ with some reasonable sense of confidence in its reliability."* - this sounds more like your real problem X. But *"for the sake of analytics"* is not an information security problem either so I still feel this question is off-topic. Given that you assume that some users will fake these information I would expect to be some security problem here (i.e. users would gain something if they fake the information) but you don't provide this. – Steffen Ullrich Aug 07 '19 at 21:23

1 Answers1

2

You may be overthinking the problem.

If you distribute a client to them, you can just query the OS directly. The best route is likely to ask users for their specs and query silently; they are unlikely to put forth the (rather substantial) effort to fabricate data if they don't know you are collecting it.

On Windows, you could query the Win32_VideoController class via WMI to identify their hardware. E.g.,

wmic PATH Win32_VideoController GET *

You could specify Name, PnPDeviceID, or DeviceID instead of * if you want to minimize the amount of data you collect.

Note that while this is a command line utility, WMI is exposed for application use; you do not need to rely on the native utility if you'd rather query directly.

This data is readable by locally-executed applications by default, and WMI permissions are rarely hardened due to their widespread use by regular applications as well as 3rd-party management tools.

DoubleD
  • 3,862
  • 1
  • 6
  • 14
  • 2
    If the client reports back the computer has a NVIDIA 2080 Ti, how can we know whether that is really the case? Maybe the client has been tampered with, or maybe the user directly sends a fake message to the server. – Sjoerd Aug 07 '19 at 19:39
  • 1
    You have to compromise the OS pretty severely, and WMI data is a live repository, so there are stability/availability issues if it is tampered with. Anyone who can intercept and answer/redirect WMI calls is likely able to bounce your queries/commands to a remote sandbox for execution/analysis as well. The question is interesting as it relates to fingerprinting, but the approach is unnecessarily complicated for a legitimate, authorized application. – DoubleD Aug 07 '19 at 19:53
  • I'm with @Sjoerd here, one does not need to compromise the OS at all to send us a fake message. It would be a trivial attack to snoop on messages between the client and our server and send false information. – Tim Clancy Aug 07 '19 at 20:24
  • You say the attacker has fully compromised the client. So not only wmi can be messed with, but also any cpu test. It is quite ridiculous to try to protect against this scenario. – user2679290 Aug 07 '19 at 20:57
  • In this scenario, you can only trust public encrpytion schemes where the private key is outside the reach of the attacker. For example, data protected by credguard. But anyway, it seems that the topic was overstretched – user2679290 Aug 07 '19 at 20:59
  • That is my point exactly; if local WMI is compromised, then there isn't going to be anything you can trust. It is pointless to try to outmaneuver an "attacker" with system privileges. Either discard the data, or make reasonable inferences---but reliable hardware detection is impossible in this scenario. – DoubleD Aug 07 '19 at 21:02
  • @TimClancy You cannot trust the client. **Ever.** If 99% of your users are honest and 1% are dishonest, then you can just ignore them. And if they are dishonest in a way that is statistically significant (e.g. reporting they have 2^128 graphics cards, for example), you can just filter them out that way. –  Aug 08 '19 at 09:02