[Interest] TLS/SSL XML encryption security

[Roland Hughes]

On 10/7/19 5:00 AM, Thiago Macieira wrote:
> You do realise that's not how modern encryption works, right? You do 
> realise
> that SSL/TLS rekeys periodically to avoid even a compromised key from going
> further? That's what the "data limit for all ciphersuits" means: rekey after a
> while.
yeah.
> You're apparently willfully ignoring the fact that the same cleartext will not
> result in the same ciphertext when repeated in the transmission, even between
> two rekey events.

No. We are working from two completely different premises. It appears to 
me your premise is they have to be able to decrypt 100% of the packets 
100% of the time. That's not the premise here.

The premise here is they don't need it all to work today. They just need 
to know that a Merchant account service receives XML/JSON and responds 
in kind. The transaction is the same for a phone app, Web site, even 
when you are standing at that mom & pop retailer physically using your 
card. They (whoever they are) sniff packets to/from the IP addresses of 
the service logging them to disk drives.

The dispatch service hands 100-1000 key combinations out at a time to 
worker computers generating fingerprints for the database. These 
computers could be a botnet, leased from a hosting service or machines 
they own. The receiver service stores the key results in the database.

A credit card processing service of sufficient size will go through a 
massive number of salts and keys, especially with the approaching 
Holiday shopping season. 1280 bytes "should" be more than enough to 
contain a credit card authorization request so this scenario is only 
interested in fast cracking a single packet. Yes, the CC number and some 
other information may well have additional obfuscation but that will 
also be a mechanical process.

Periodically a batch job wakes up and runs the sniffed packets against 
the database looking for matching fingerprints. When it fast cracks one 
it moves it to a different drive/raid array, storage area for the next 
step. This process goes in steps until they have full CC information 
with a transaction approval, weeding out the declined cards.

When the sniffed packet storage falls below some threshold the sniffer 
portion is reactivated to retrieve more packets.

This entire time workers are adding more and more entries to the 
fingerprint database.

These people don't need them all. They are patient. This process is 
automated. They might even configure it to send an email when another 
100 or 1000 valid CCs so they can either sell them on the Dark Web or 
send them through the "buying agent" network.

Yeah, "buying agent" network might need a bit of explanation. Some of 
you may have seen those "work from home" scams where they want a 
"shipping consolidation" person to receive items and repackage them into 
bulk packs for overseas (or wherever) shipping. They want a fall person 
to receive the higher end merchandise which they then bulk ship to 
someone who will sell it on eBay/Amazon/etc.

The CC companies constantly scan for "unusual activity" and call you 
when your card has been compromised. This works when the individuals are 
working with limited information. They have the CC information, but they 
don't have the "where you shop" information. The ones which have the 
information about where you routinely use the card can have a better 
informed "buying agent" network and slow bleed the card without tripping 
the fraud alert systems. If you routinely use said card at say, Walmart, 
2-3 times per week for purchases of $100-$500 they can make one more 
purchase per week in that price range until you are maxed out or start 
matching up charges with receipts.

The people I get asked to think about are playing a long game. They 
aren't looking to send a crew to Chicago to take out $100 cash advances 
on a million cards bought on the Dark Web or do something like this crew 
did:

https://www.mcall.com/news/watchdog/mc-counterfeit-credit-cards-identity-theft-watchdog-20160625-column.html

Or the guy who just got 8 years for running such a ring in Las Vegas. 
That's the most recent one turning up in a quick search.

Maybe they are looking to do just that, but are looking for more 
information?

At any rate, the "no-breach" scenario is being seriously looked at. Yes, 
the Salt will change with every packet and the key might well change 
with every packet but these players are only looking to crack a subset 
of packets. Most organizations won't have the infrastructure to utilize 
a billion compromised credit cards. They can handle a few hundred to a 
few thousand per month.

In short, they don't need _everything_. They just need enough to get 
that much

> And don't forget the Initialisation Vector. Even if you could compute the
> fingerprint database, you still need to multiply it by 2^128  to account for
> all possible IVs.

Perhaps. A few of those won't be used, such as low-values and 
high-values. That also assumes none of the desalination chatter pans 
out. Maybe it does and maybe it doesn't. One thing is certain. We now 
have the storage and computing power available to create the database or 
2^128 database tables if needed.

The people I get asked to think about are playing a very long game. If 
they are using a botnet the machines to generate the database content 
cost them nothing. They are only on the hook for a bit of coding and 
what is becoming cheaper by the month storage.

https://venturebeat.com/2014/07/13/hackers-only-need-to-get-it-right-once-we-need-to-get-it-right-every-time/

  

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog