Cybercrime: could tokenization and blockchain help end data theft?

For a while now, America has been a hotbed of credit card fraud and data hacks. In terms of credit card fraud, big data analytics has come to the forefront in efforts to fight fraud, which was a $7 billion dollar problem in 2013 alone. Data scientists create algorithms that analyze user habits, and use machine learning to predict the probability of whether a transaction is fraudulent.

For a while now, America has been a hotbed of credit card fraud and data hacks. In terms of credit card fraud, big data analytics has come to the forefront in efforts to fight fraud, which was a $7 billion dollar problem in 2013 alone. Data scientists create algorithms that analyze user habits, and use machine learning to predict the probability of whether a transaction is fraudulent.

In terms of data hacks, half of the data records that cybercriminals steal are financial. These records include credit card information and account details. According to the University of Cincinnati there were nearly 700 billion records stolen or lost in 2014, a rise of more than 100 billion from 2013.

There are multiple points at which cybercriminals can steal financial information. If data are not encrypted as they’re sent, they’re vulnerable then. And, they’re vulnerable at either end, whether it’s in the POS, or in the hands of the bank or credit card company.

One method of securing credit card data is through tokenization.  

You’ve probably heard about Mobile Wallet, which uses Near Field Communication (NFC) to send information to a payment processor. But do you use it? For me, the idea of uploading credit card information onto a smartphone, where it becomes data that could potentially fall into the hands of cybercriminals, just wasn’t that alluring when I first heard about it.

But what I didn’t know until I did some research is that NFC Mobile Payment uses tokenization. This renders credit card data dynamic and constantly changing—at least, that’s what it does to the data on your smartphone. In essence, it makes the data dead.

When you upload card information, the smartphone sends it to your bank. The bank then replaces that information with meaningless, token data that represent your card. The token data go back to your phone, where they’re housed for payment. That way, someone can’t hack into your phone—as the FBI did with the iPhone. They can’t steal your credit card information directly.

The problem with tokenization at that juncture—once the token is housed on the phone and used repeatedly—is that the token might as well be the credit card data. A second set of token data, unique to each transaction and specific to a single card/device, can then secure the first set of data. This second set of data is always changing randomly.

NFC sprung up from RFID (Radio-Frequency Identification), which is a primary driver of the Internet of Things. RFID is just another means of transmitting information, like WiFi. NFC and tokenization aren’t effective unless end-to-end encryption exists to begin with.

Initially, the phone must encrypt data before sending it to the bank. There, the bank decrypts card data and replaces it with the token. When the token goes from your phone back to the bank to signal a payment, the bank detokenizes it. The credit card data is sitting there in the bank. And that, as we’re finding out, is the point at which it’s highly vulnerable. It’s vulnerable in the interbank messaging system.

Proper tokenization is incredibly hard, if not impossible, to crack. Why aren’t the banks using something like tokenization for the messaging system? First, let’s get into what’s going on here.

Hackers stole $81 million from Bangladesh’s central bank account with the Federal Reserve Bank. They used SWIFT’s credentials. SWIFT is the system through which thousands of banks transfer money and send messages. Although the hack already happened, SWIFT’s system is still vulnerable. But SWIFT blames Bangladesh, and says any bank using the system “is responsible for the security of its own systems interfacing with the SWIFT network and their related environment.”

SWIFT says banks have to lock down their own security as it relates to the transfer system, but how are they going to do that? It’s quite possible that a Bangladesh employee working from the inside helped hackers break SWIFT and transfer the funds to the Philippines. When there’s human error or malfeasance involved, bank databases will always be vulnerable. It’s just that simple.

Here’s the interesting thing: According to Blythe Masters, a champion of the technology behind Bitcoin, blockchain is a superior option for securing money transfers.  

Blockchain is essentially an encrypted cloud of computers that store financial information. This information represents money, but there’s no actual money involved. It would be extremely hard to break down the encryption of so many computers. The problem with converting banks to blockchain is that the data on a blockchain database are not backed by fiat money or hard cash. Banks don’t have a way of working with a system that is completely intangible and abstract.

Why not employ tokenization? The actual financial data, the stuff that has true value to banks and consumers in our current system, could be stored on the blockchain. All this data could be tokenized in the banks’ native systems. That way, banks could maintain their current systems. If a hacker taps into a bank’s system, the hacked information is meaningless because it’s a token. Detokenization would happen in the blockchain. If the hacker tries to hack the blockchain to get the real data, that hacker has to deal with thousands of encrypted computers.

The problem for banks is that they want immediate control and ownership of our financial records. This is what gives banks value as institutions. Putting financial records on the blockchain removes that centralized control, leaving banks with nothing but a token of what they once had. But do banks deserve to have centralized control of our records if they can’t keep them secure? The answer is assuredly ‘no.’