Machine ID for Mac OS?

Erik's suggestion of system_profiler (and its underlying, but undocumented SystemProfiler.framework) is your best hope. Your underlying requirement is not possible, and any solution without hardware support will be pretty quickly hackable. But you can build a reasonable level of obfuscation using system_profiler and/or SystemProfiler.framework.

I'm not sure your actual requirements here, but these posts may be useful:

Store an encryption key in Keychain while application installation process (this was related to network authentication, which sounds like your issue)
Obfuscating Cocoa (this was more around copy-protection, which may not be your issue)

I'll repeat here what I said in the first posting: It is not possible, period, not possible, to securely ensure that only your client can talk to your server. If that is your underlying requirement, it is not a solvable problem. I will expand that by saying it's not possible to construct your program such that people can't take out any check you put in, so if the goal is licensing, that also is not a completely solvable problem. The second post above discusses how to think about that problem, though, from a business rather than engineering point of view.

EDIT: Regarding your request to require a reboot, remember that Mac OS X has kernel extensions. By loading a kernel extension, it is always possible to modify how the system sees itself at runtime without a reboot. In principle, this would be a Mac rootkit, which is not fundamentally any more complex than a Linux rootkit. You need to carefully consider who your attacker is, but if your attackers include Mac kernel hackers (which is not an insignificant group), then even a reboot requirement is not plausible. This isn't to say that you can't make spoofing annoying for the majority of users. It's just always possible by a reasonably competent attacker. This is true on all modern OSes; there's nothing special here about Mac.

Spoofing network cards is easy isn't it?

samoz 2009-06-26 17:54:38

@alan, samoz: Unfortunately, yes.

Pedro d'Aquino 2009-06-26 17:59:31

@samoz: After searching a bit, it looks like spoofing them are easy. You are right.

Alan Haggai Alavi 2009-06-26 17:59:58

Yeah, I've been experimenting with that. The thing is that I have no idea whatsoever where system_profiler get its data from, so I'm hesitant to rely on it - I worry it may be too fragile.

Pedro d'Aquino 2009-06-26 18:05:41

But if you make a hash it shouldn't really be a problem, because given a hash, its computationally infeasible to recreate the object that was hashed.

samoz 2009-06-26 18:08:09

@samoz: I must have expressed myself badly. Imagine this scenario: My app is used to identify clients of a website (say a bank). When the user first logs in the website, I install my app on the user's computer, run system_profiler and hash the output. Suppose that the next time he logs in, I want to see if its the same computer as before, so I once again run system_profiler. But if he spoofed something, say his disk serial number, the output of system_profiler will be different and he will have broken my system. Encryption is irrelevant in this scenario.

Pedro d'Aquino 2009-06-26 18:13:41

@Pedro: how does that make things any more secure? What if the user has more than one computer? What if he or she upgrades their hardware or gets a new computer? Don't try too hard to be smarter than your users are. Or, if this is a particularly security-intensive use, you might want to look at things like RSA SecurID tokens for two-factor authentication.

Joe 2009-06-27 02:25:57

@Pedro: if the user wants to spoof you, and is reasonably technical, this approach is doomed to insecurity. For instance, there's no way to guarantee that the app they're running is the one you installed (or asked them to install), and not a hacked variant that'll always return whatever hardware info they want it to. As Rob said, you need to do the security on the server side, because that's the only place you actually control. You cannot trust anything running on -- or coming from -- the client.

Gordon Davisson 2009-06-27 06:43:40

@Joe, Gordon: Thanks for the comments. I agree with everything you have said. This isn't the only thing we're using to prevent fraud. It's just an additional layer of identification - one our client has been using for quite some time on Windows and has been happy with the results - so much, in fact, we're porting it to other OSs. Again, thanks for all the input.

Pedro d'Aquino 2009-06-27 21:25:15

Thanks. You're obviously quite knowledgable about this subject. To make things clear, I'm not working on copy-protection. The client is a secure website with a huge fear of frauds. Do you happen to have any more information on system_profiler, e.g. where its data come from (if it polls the HW directly etc.)? I googled "SystemProfiler.framework but didn't find anything.

Pedro d'Aquino 2009-06-26 18:59:00

My response turned out to be way too long to go here. I've posted a long introduction to the topic: http://robnapier.net/blog/understanding-systemprofiler-393

Rob Napier 2009-06-26 21:26:57

Also, on the subject of fraud, are you concerned about your customers being tricked, or are you concerned about your customers being the cause of the fraud? I'm suspecting the latter case. The way you attack that problem is server-side, looking for behaviors that indicate fraud because you can never trust the client app. You also will need to determine how much fraud you're willing to just accept. Any system has some fraud in it, and the cost of getting rid of it grows exponentially. Study how Visa and banks handle these issues.

Rob Napier 2009-06-26 21:35:09

ansaurus

tags:

views:

answers:

Machine ID for Mac OS?

related questions