Towards A Tokenized Data World: A New World Is Being Created
The number of data hacks seems to increase by the day, and where we find bad practices being applied in places that we assumed would have been secure. The BA hack, thus, puts large question marks over the way that our data is being handled, and we need a change soon, and put the control of data back into the hands of those who really matter … the citizen.
Old world of data
We have built a very simple data world doesn’t look that different to the one we created in the 1980s. We still use relational databases and still use SQL commands to interrogate them. Okay, we have now moved the cloud, but the methods we use to access them. Surprisingly the move to actually secure them has often been met with silence from the Dev Ops teams, as any encryption within them is likely to either slow the whole data infrastructure down or will break the running of the code.
- Why do we still blindly pass our sensitive data without encryption, and assume that if we secure the tunnel we will be okay?
- Why do we still personally identifiable data in a plaintext format?
- Why do we still use pseudo-anonymizers can easily be resolved into actual people? Whether it’s the CHI number in Scotland or the SSN identifier in the US, we basically protect individuals using simplistic identifiers.
So should we encrypt data at every move? Yes. That must our objective! But … the industry is bad at encryption, and the lack of knowledge in doing it properly would probably cause more problems than it fixes. Any company who is serious about security will take this tack, and build new infrastructure which does not have any legacy. But for the rest — the vast majority — we need to find ways to keep our existing systems running, but secure the data.
The move towards tokenization
And so many see tokenization as the solution to make of our data security problems. With tokenization, we map our original data object and replace it with a data token. The token then does not contain and sensitive elements, but these elements have the same format as the original data and which cannot be linked back to the original data.
In the following Bob has a data object which contains personally identifiable information (PII), and we then convert this data into a token, which cannot be resolved back to him:
The main difference here with encryption is that we still have data which keeps the same basic format as the original data, and thus our database systems will not complain. For example, our systems may detect that we are dealing with a valid credit card number, and checks if the number begins with a ‘3’ (Am Ex), a ‘4’ (Visa) or a ‘5’ (MasterCard). In this case, we can leave the ‘4’ at the start of Bob’s credit card number, and then replace the rest of it with another value. We also do not perform complex encryption but have a randomization process to create the converted values. The advantages over traditional encryption are thus:
- Non-mathematical approach replaces sensitive data with non-sensitive substitutes of the same type and data length.
- Provides compatibility with the legacy system (eq databases).
- Part of the data can be revealed (as required).
- Requires less processing than traditional encryption.
If we use complex encryption, it is normally the mobile device or the browser which will struggle to perform actions within reasonable time limits. With a token, all the device has to do, is to protect the token with biometrics, and so that it cannot be accessed by malicious entities.
The process involves Bob requesting a token from a trusted tokenization server, such AlicePay. He will then pass his credit card details in a secure way, and prove his biometrics and PIN code in order to get the token. AlicePay will then generate a random number, and then convert his details into a token which has valid look values for this card ID and CVV2 number. They will then delete all of Bob’s details, and just register the ID of the token and the random value. AlicePay will then sign the token with their private key and apply an expiry date for the token, and send to Bob. AlicePay will not keep this token.
Bob then goes online and purchases an Amazon Echo for $100, and gives the token details to the Merchant. They then send it to the Merchant Acquirer (the Merchant’s trusted bank), and the Merchant acquirer reads that it is AlicePay, so sends the token off to the trusted tokenization server. It will then resolve the details back, and resolves the details from the ID, and checks that the transaction is valid. If it is, the tokenization server sends back an “Okay” to the Merchant acquirer, who then sends a “Payment accepted” to the Merchant, and Bob gets his Amazon Echo:
To close the loop, the tokenization server also sends a “Successful payment” back to Bob, and he and the Merchant are happy. We now keep logs all of the accesses, and where all the parties can prove the complete route of the transaction, but where no sensitive details have been passed. Eve can be sitting listening to the communications between Bob, the Merchant, and the Tokenization server, and she will not be able to determine Bob’s credit card details. In this way, we isolate the key areas of risk, such as in the registration process, and make sure that this is strongly protected.
Isolating and segmenting risk
The tokenization service, too, would be well protected, and only use good cryptography for the storage of details, and where any accesses will be logged and monitored. The creation of the token will also be protected and highly trustworthy. Along with this, the revocation service of a token will allow Bob to cancel the token, and for any accesses to it, to be monitored and traced (to a potential hacker who has his device). We also apply strong protection on the access to the token for Bob, and where he must provide his fingerprint, face or any other ID method that he trusts. Now, Bob owns his own ID. Even if Eve gets the token, she will not be able to reverse back the details of his information. The level of encryption applied into the token can also depend on the risk involved.
The model of tokenization is gaining massive traction in many areas, including financial payments, exam results, and health care. For Bob, he always knows that he holds the key to his information — his tokens — and that AlicePay will protect them. If he finds out that AlicePay has been compromised, he cancels them and moves to another token provider. For AlicePay, they need to make sure they run a trustworthy business, as they will not get any business if they do not. And so they have a whole bunch of people who know their cryptography inside-out, and a team who constantly monitor everything that they are involved with. They then become the core of the security of the infrastructure, as they can see strange events (in the same way the Monzo detected the Ticketmaster hack).
Format Preserving Encryption
One method that can be used in creating the mapping is FPE, and which is defined in a NIST standard. Here is the method:
Format Preserving Encryption (FPE)
Format Preserving Encryption (FPE) as a way to protect credit card details. The industry does seem to be worried, but…
Well, we are setting up a world’s first identity research lab — in collaboration with Blockpass — and we see a much more trusted world being developed, and we want to focus on building it, and making sure that every single part of it is focused on the citizen, and protecting their identity, their rights and their consent.
We see a tokenized and a citizen-focused world clearly, and for us to dump our legacy of the past, and take us to the next level, which will be to run a more trusted world within the untrusted world that we have created. We would like to see every government service tokenized in some way, and where the identity of citizens can be proven and their details masked. AlicePay, of course, could be a government provider of tokens, if we trust them.
Tokenization is thus the first part of our journey, and keeps all of our systems happy, and has compatibility with our existing systems. The next stage will then build a completely trusted world … yes, there’s blockchain and lots of cryptography involved … but that will be the end point.
YOU are the centre of this new world … and it is your rights that the Internet will respect. Come and help us build it … we must NOT end up with a world where AlicePay is just the finance and health care sector doing the same old thing as they have done for the past few decades.