Tokenization and Your Private Data (5)
04 Jul 2014Recapping (last time):
- (Day 1) The government is interested in using the salesforce.com CRM and other USA cloud applications, but the BC FOIPPA Act does not allow it.
- (Day 2) So, the BC CIO has recommended “tokenization” systems to make personal information 100% obscured before storage in USA cloud applications.
- (Day 3) But, using truly secure tokenization renders CRMs basically useless, so software vendors are flogging less secure forms of tokenization hoping that people won’t notice the reduced security levels because they still call it “tokenization”.
- (Day 4) And, the BC Freedom of Information & Privacy Commissioner distinguishes between “encryption” (which is considered inadequate protection for personal information held outside Canada) and “tokenization” (which is considered adequate (but only where the “tokenization” itself is “adequate” (which seems to mean “fully random”))).
While this series on tokenization has been a bomb with regular folks (my post on the BCTF and social media got 10x the traffic) one category of readers have really taken notice: tokenization vendors. I’ve gotten a number of emails, and some educational comments as well. (Hi guys!)
For the love of the vendors, I’ll repeat yesterdays postscript. I think I have been overly harsh on the cloud security vendors, because there are really two questions here, which have very different answers:
- Is less-than-perfect tokenization better than nothing? Yes, it’s a lot better than nothing. Even with less-than-perfect tokenization, employees of the cloud software companies can’t just casually read records in the database, and an entity wanting to break the security of the records would need to extract a pretty big corpus of records to analyze them to find information leaks and use them to break in.
- Is less-than-perfect tokenization acceptable for BC? No, because of the FOIPPA law, and because the Commissioner has already set a very very very high bar by not allowing standard symmetric encryption (which can be very very secure) to be used to host personal data outside of Canada.
It’s worth re-visiting the two key phrases in the OIPC guidance, which are:
Tokenization is distinct from encryption; while encryption may be deciphered given sufficient computer analysis, tokens cannot be decoded without access to the crosswalk table.
What I take from this is that the OIPC is saying that “encryption” is vulnerable (it “may be deciphered”), and “tokenization” is not (it “cannot be decoded”). Now, as discussed on day 3, the “cannot be decoded” part is only true for a very small sub-set of “tokenization”, the kind that uses fully random tokens. And the OIPC is aware of this, though they only barely acknowledge it:
Public bodies may comply with FIPPA provided that the personal information is adequately tokenized and the crosswalk table is secured in Canada.
If you take “adequately” to mean “adequately” such that “tokens cannot be decoded without access to the crosswalk table” then you’re talking about an extremely restrictive definition of tokenization. A lot more restrictive than what vendors are talking about when they come to sell you tokenization.
The vendors who are phoning me and commenting here are worried that readers will see my critique and think “huh, tokenization is insecure”. And that’s not what I’m saying. What I’m saying is:
Practical use of tokenization in a USA cloud CRM is not consistent with the British Columbia OIPC’s incredibly narrow definition of an acceptable level of data security for personal information stored in foreign jurisdictions or under foreign control.
– Paul Ramsey, Just Now
If you’re just looking for a reasonable level of surety that your data in a cloud service cannot be easily poked and prodded by a third party (or the cloud service itself), and you don’t mind adding the extra level of complexity of interposing a tokenization service/server into your interactions with the cloud service, then by all means, a properly configured tokenization system would seem to fit the bill nicely.
YMMV.