EDIT: As drdaeman pointed out, none of what I'm describing is AES. I am describing something completely different. I am describing public key cryptography, whic

EDIT: As drdaeman pointed out, none of what I'm describing is AES. I am describing something completely different. I am describing public key cryptography, which is completely different from AES. ...but if you still want to know about asymetric public key cryptography, read on, but ignore any references to AES, because it isn't AES at all. ... Well, this is just one layer in a hypothetical system comprised of many layers. This one layer just handles storing secure data in a way that the app itself cannot understand. The iPhone app needs to be authorized to make privileged requests to the server. This would be another multi-step process of performing a handshake with the server. The server must not unlock anything for any client request, unless the client-side user agent proves that it's really a member of the secure system. This is the part where "the server is a fortress" So this exchange of sensitive data would need to occur within the scope of a handshake process, such that the server challenges the app to prove it's authenticity. Something like this might also involve a third party verification from Apple & perhaps even the service provider that the app is not running on a jailbroken iPhone, a reportedly stolen iPhone, or some nefarious evil-doer's laptop. THEORETICALLY (emphasis mine) once you encrypt data with AES, it is not merely a "token" that could be substituted for something else. It is an otherwise impenetrable object, and you can't just use the "token" itself. The token needs to be transformed into the usable data before it may be used. For example, the stored data is: 0x01B926A340F0CCC67238DD00 That data is not a password. But. A valid app that is permitted to interact with the Starbucks server can send that string over to the server, and the server will send the tranformed data back in a secure manner. The server will send to the app: "H3ll0_this_1$_a_p@ssw0rd" The app is responsible for the plaintext version of the data and MUST destroy the data after use, and never save it. The app has a PUBLIC KEY ONLY. That thing cannot unlock the data. the PUBLIC KEY cannot transform that hexadecimal string data back to the password. The app can create the impenetrable object but not unmake it. The server, on the other hand, HAS THE SPECIAL PRIVATE KEY. The private key is The Spice. He who controls The Spice controls the universe. The private key is the only thing with the power to transform that hexadecimal string back to the real token. If something has the power to ask the server to perform the transformation, then it gets the information. The server has the responsibility of never letting the private key fall into the wrong hands, and never transforming data without properly challenging the client's authority to dare ask for sensitive data.