Device ID and Privacy
Unique, hardcoded device IDs are bad for privacy. We hate them. Our friends hate them. So its nice to see that Microsoft is making it harder to get to them:
GetDeviceUniqueID attempts to address these issues and to reduce applications dependency on the precious device id. Firstly GetDeviceUniqueID can be called from the trusted or untrusted code group, but the code returned is not the same as a call to KernelIoControl, its a 20 byte code not a 16 byte code. GetDeviceUniqueID takes an additional parameters of an application defined char array, and uses a one way hash to combine the real device id and the char array parameter to generate the new 20 byte code. This means that an application will always get the same 20 byte code if it calls GetDeviceUniqueID on the same device, with the same char array. It also means there is no practical way of asserting the true device id from the 20 byte key an application uses.
(From the Windows Mobile Security Blog, “GetDeviceUniqueID.”) If you’re going to have a unique device ID, then a boundary between the real device ID and the one applications use is a good idea, and one I haven’t seen implemented before. Kudos to Microsoft for doing, and documenting this.
I do find the application-determined salting to be a little odd, and even slightly worrisome. Admittedly, there are 2^32 salts there, but why have the salt (entirely) determined by the app? Why not call GetDeviceUniqueID, and have the returned structure include a salt? I don’t have a particular attack in mind, but if the threat model includes the app, then taking this out of the control of the app feels right to me.
If the salt weren’t completely specified by the app, the app wouldn’t get the same value for “uniqueid” if it called the function multiple times. This would surely lead to problems in apps that didn’t expect this behaviour.
I suppose you could add a call like “Does this uniqueid match the current device?” which would hash the device id with the salt in the uniqueid, and return boolean, but that could complicate a lot of things.
I was thinking the OS could mix in something about the app that was hard to change, if you’re concerned about guessing attacks by other apps on the same device.
So the big question is, should you be? I don’t have a good reason for that, and engineering without a good threat model isn’t engineering, it’s pretending.
On the other hand, letting the app determine the salt could means that we’ll probably have non-crypto trained coders generating salts right? In which case won’t we run into a host of bad IV type attacks like we’ve seen with WEP?
Hi Adam,
The salt doesn’t need to be cryptographically special. It’s just additional bits that get stirred into the hash. It’s entirely expected to use the name of your app, or your dog’s name, or whatever. The reason the app gets to determine it is so that it will be consistent for that app. If we just made up a salt for your app and handed it back to you, then GetDeviceUniqueID wouldn’t necessarily return the same value for you across a cold boot, and that’s part of the contract of the API.
Hi Scott,
Is there a particular threat model you’re concerned about that caused you to add the feature?
This API is callable from untrusted code and the previous method was not. That caused problems for ISVs on Smartphone platforms.
The salt is mainly for privacy concerns. Giving different salts to different applications makes it more unlikely that information about a specific device can be aggregated or tracked by that ID alone.
I’m having a problem with mobile 5 smartphones, if I pass the same salt (app name) so far all 3 different smartphones return the same ID. On the other hand, mobile 5 CE devices seem to work correctly, that’, they all return unique IDs. Has anyone had this problem? Thanks.
I’m having a similar problem, Scott. I’ve got Pocket PC’s that are being used as Sprint phones. They all return the same device ID. This is a big issue for me as we have an enterprise application that uses the device ID to determine what data needs to be sent to the device. If the device ID is the same for all devices, we must send all data to all devices. Not good!