curmudgeoned

I believe these sorts of people are also referred to as warez d00dz.

Whoops! Looks like your right... AES doesn't use public key exchange, and public/private key pair generation at all! I was entirely confusing it with other completely different things.

Ha ha! Sorry...

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

   "H3ll0_this_1$_a_p@ssw0rd"

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.

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.

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?

Because the author does seem to care about defining what COW means, because "atomic cow" doesn't readily google to its proper meaning, and because it doesn't seem to be otherwise mentioned here:

COW: Copy-On-Write

http://en.wikipedia.org/wiki/Copy-on-write

How many personnel does it require to physically compromise 100,000 machines?

1,000 people gaining access to 100 machines a piece? 100 people, breaking into 1,000 machines? Is that per year or in general?

If one targeted individual owns 10 machines, then it's 10,000 people targeted by the program.

If this includes organizations, bussinesses, institutional computer labs and offices, then maybe it's 1,000 offices with 100 work stations each.

So, perhaps a rough estimate of the scope of the program 100 to 1,000 staff attacking between 20,000 and 1,000 targets?

This model of investment is one tactic. But in my opinion, it's not the one at play here.

Another majorly significant tactic of investment is to buy your potential competitors early and often. Find the upstarts that pose a threat to your business and make them an offer.

Does anyone remember Friendster and MySpace? (stupid question, I know)

But before Facebook opened itself to non-edu TLD email addresses (read: enrolled college students only), these were the only two major ground-breakers in terms of social media (or what I prefer to refer to as public AOL Buddy Lists).

There was a major difference between Friendster and MySpace though, and it's a big one that was hugely ignored:

  Friendster actually provided real social network graphs,
  that showed you your own Kevin Bacon relationship with every user 
  page you viewed.

  MySpace blindly declared that "EVERYONE" was in your network,
  because YAY! WE ALL USE MYSPACE, SO WE'RE ALL FRIENDS IN ONE BIG
  NETWORK: MYSPACE! SQUIDDLEY DOO! (especially wrt our big 
  buddy: "Tom")

Meanwhile, technically competant scrapers, could still build out the actual Kevin Bacon degrees of separation for MySpace by scraping the public pages and re-compiling and aggregating the data themselves, but still... friendster gave it to everyone, and understood the significance of degrees of separation between people, but no one seemed to care.