3 ms·
Not really. It goes like something like this: 1. Starbucks' server has the private key, the iPhone app has the public key. 2. The app locks the pla
by curmudgeoned 13y ago
Not really.
It goes like something like this:
1. Starbucks' server has the private key, the iPhone app
has the public key.
2. The app locks the plaintext up in AES with the public
key, local to the phone, and keeps the locked data,
and sends a copy to the server. The server has the
private key, and can unlock the data locked up with
the public key anytime, even though the app (in
possession of the public key only) cannot unlock the
data by itself.
3. The app needs network access to operate properly,
because honestly, why is Starbucks attempting to
transact without a network connection, so if there's
no network access and the protected data can't be
accessed, oh well. Oh, and by the way, if the app
really needs the plaintext, why not just ask the user?
Oh right, thinking is hard. Don't ask a lazy user to
do anything.
4. Each time the app needs to unlock the protected data
and use it locally, it sends a GET request to the
server via HTTPS. Maybe it sends XML, maybe it sends
JSON. Who cares, as long as it's not keeping and using
the plaintext.
5. Based on the nature of the request, the server decides
whether it needs to send the plain text back over
HTTPS, or whether the app is just asking the server to
do something server-side involving sensitive data. If
the app *REALLY* needs the locked data sent back in
plaintext, the server sends it back for one time use
via HTTPS (still protected from interception, even
though it's being sent over network), to be nulled out
after the process or function returns complete.
6. The server is a fortress, and has the private key
(...somewhere). It does not store the sensitive data
in plain text. It too only stores the locked data, but
is capable of unlocking the data on the fly, per
request, each request, every time. The server should
actively garbage collect the plaintext data, and not
leave stale copies lying around.
7. The server *NEVER* give an app a copy of the private
key. NEVER, EVER. The iPhone app can rot in hell if it
can't get the data unlocked. If it has to wait, it
waits. Find something else to do. Mine bitcoins,
unfold some proteins, whatever.
Yes. This demands a server infrastructure with high performance and high availability, according to the popularity of the app (many millions of concurrent users). It will be expensive and complicated to execute something like this. One would not JUST AES it.
But hey, lazy users can't be bothered to type passwords and such. Gee whiz! Isn't this Starbucks app easy to use? How did they do that?
- eli 13y agoI didn't really follow that. Doesn't that still leave a token (the encrypted password that is sent with each request) that I can steal from your phone and use to log in to your account and impersonate you? Sounds like a complicated way of saying "don't store anything on the phone and remember a token instead of the password"
- curmudgeoned 13y agoEDIT: 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.