Ask HN: Trusted Computing, iPhone, and unique identifiers
3 comments
NSString *UUID = [[UIDevice currentDevice] uniqueIdentifier];
However, this won't stop people from screwing around with your app still. If people want to act silly and stupid, they will.
no, the iPhone doesn't provide a "non-forgable UUID"
The [UIDevice currentDevice] uniqueIdentifier isn't going to work because it is trivial to spoof the deviceIdentifier.
You could potentially design your own authentication mechanism and implement the appropriate client-code and server-code to verify (over ssl) that the server request really came from the client that you implemented and from a valid user/subscriber. If your client-code can only run on the iPhone, that may be sufficient to prove that the client is an iPhone and that the user is a valid subscriber.
You could potentially design your own authentication mechanism and implement the appropriate client-code and server-code to verify (over ssl) that the server request really came from the client that you implemented and from a valid user/subscriber. If your client-code can only run on the iPhone, that may be sufficient to prove that the client is an iPhone and that the user is a valid subscriber.
What kind of app are you building that this is a concern?
I'm building an iPhone app. It talks to a server. I want each iPhone to only be able to have _one_ account on the server -- I don't want people creating lots of separate accounts and having them collude.
Now, my iPhone app and my server are talking to each other over TCP/IP. In theory, anyone can build a computer program that fakes the protocol my iPhone app uses (not very hard -- just download the app, log the packets, reverse engineer the API; I can encrypt my traffic, but they can run the app under a VM / extract the key).
So, although I'm generally not a big fan of Trusted Computing -- does the iPhone support anything like this? Where my server can remotely detect "is this device an iPhone?" + "give me a non-forgable UUID" (even if I force the device to be an iPhone, the attacker can still create another iPhone app and have it talk via the same API).
Thanks!
(Sorry: I realize the business man in me says "err, build the product first, worry about this later"; but I'm kind of curious -- both from a technical perspective and a design perspective -- if I know that creating each account requires purchasing an iPhone / iPod touch, I can know up front that people are less likely to create silly accounts & try to screw around).