13

Seeing the Sony Personal data kerfuffle unfold has gotten me thinking about the encryption and securing of personal data - obviously credit cards can (and should) be encrypted, making data breaches of this sort much less of an issue for the end user. That said even if customer credit card details are secure, the other personal data which can be leaked is potentially just as damaging. In this case the data leaked was:

  • Your name
  • Your address (city, state, and zip)
  • Country
  • E-mail address
  • Birthday

In fact, in some cases this information can be more damaging - you can cancel your credit card with a single phone call, but the above combination of information still leaves you open to many forms of identity theft and it is far more difficult to change your address or name.

Hence my question: Is it feasible to protect customers personal details using encryption in the same way that credit cards are protected? (So that the effect of the entire database being compromised in this way are mitigated).

What about applications where searches are performed against this customer data? (for example to look up a customer by their name and address) Can the data be encrypted in a way that still makes searching possible and isn't prohibitively expensive in development costs?

Update: To clarify, I'm interested to know if there are techniques that can be used to securely encrypt personal details so that they are still "usable". For example it is a common requirement to be able to search for customers by their name or addresses, however this is potentially difficult to do if these personal details are encrypted. (Is it possible to reliably search on securely encrypted data?)

D.W.
  • 98,420
  • 30
  • 267
  • 572
Justin
  • 458
  • 1
  • 4
  • 12

5 Answers5

7

Simple answer - yes, it is feasible - if by that you mean 'can it be done?' as you can encrypt pretty much everything stored.

However the extra computational overhead (especially on encrypted databases) is usually looked on unfavourably, as is the cost to recode, updating procedures etc etc. Obviously you can't just hash if you want to allow partial searches on names, addresses etc., so everything has to be encrypted to a key, which then needs to be protected etc.

Before regulation such as PCI-DSS, many organisations didn't want to encrypt credit card data, due to the costs involved, and even now, PCI hasn't managed to persuade every handler/storer of credit card data to do this correctly.

So the long answer is - No, it is not going to get any budget until it is mandated.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • 3
    "However the extra computational overhead (especially on encrypted databases) is usually looked on unfavourably" which is, as I expect you know, bunk. Computers are cheap and are there to do our bidding: spending cycles on encryption is not wasted effort or money. Indeed it usually costs more trying to change the direction of a recalcitrant C*O than to actually run the encryption algorithms. –  Apr 29 '11 at 08:41
  • @graham you spotted my choice of words then:-) – Rory Alsop Apr 29 '11 at 14:02
  • 1
    aye, I just wanted to make that point explicit :) –  Apr 29 '11 at 15:18
4

I'm interested to know if there are techniques that can be used to securely encrypt personal details so that they are still "usable".

This is what the field of Homomorphic encryption is all about. It is already possible, via end-to-end voting systems like Helios to publicly store votes in an encrypted fashion, so that the public can add them up to confirm the totals, and to also check that their own vote was indeed included in the total. Without giving someone a 'receipt' that they can use to sell their vote. Surprising, but true.

We now have more advanced forms of homomorphic encryption that are suitable for storing data encrypted in the cloud, and allowing a not-very-highly-trusted server to directly do useful computation on it. They are still too slow for many uses, but progress is being made.

The ways of cryptography are often counter-intuitive, and asking basic questions like this is always a good thing - thanks!

We've been doing somewhat similar things for decades with passwords. You left out the fact that Sony said that the "PlayStation Network/Qriocity password" was stolen also - clearly this is personal information intended to remain a secret. And of course a competent site should indeed be able to both store something useful, and protect the actual password via standard hashing/salting/iteration techniques that have been in use since 1979 at least. Their press release seems to be evidence that Sony didn't properly handle them.

nealmcb
  • 20,544
  • 6
  • 69
  • 116
2

the above combination of information still leaves you open to many forms of identity theft

Does it? If so then the obvious question is: why?

All this information is part of the public record. Why in 2011 do we still pretend that it is secret at all never mind top secret? Who is building the brain damaged systems that depend on the pretence that public information is secret?

Our name and address is so need-to-know-basis-only secret that we print it on the outside of envelopes and give it away on business cards.

obviously credit cards can (and should) be encrypted

Just as the information that is embossed on the plastic cards themselves is encrypted.

Oh, wait.

Well at least we never let those cards out of our sight. Or hand them to complete strangers. Or read them out over the phone.

Oh.

Again - how did the credit card companies manage to convince people that these things are secrets?

frankodwyer
  • 1,907
  • 12
  • 13
  • 3
    Having a database with millions of addresses and CC numbers is not quite the same thing as having data for hundreds of people you've met physically. It's a bit like the difference between sending a ping packet to test connectivity and sending a million pings per second from a botnet: it's not just about what you do but how much you do it. – Gilles 'SO- stop being evil' Apr 28 '11 at 15:50
  • 1
    sorry, no it isn't. the idea that the information is secret in the first place is nonsense. it's not even a little bit secret. and a million of them aren't (shouldn't be) more secret than one of them. – frankodwyer Apr 28 '11 at 16:37
  • And dont *even* get me STARTED on SSNs... really, it is ridiculous. – AviD Apr 30 '11 at 22:23
  • +1: The more often this information is kept secret, the more people will base security assumption on the idea that it *should be* secret, which only makes things worse. SSNs are a great example of a bit of absolutely public data that has taken on a *password* role. – tylerl May 12 '11 at 02:41
2

Not if it's going to be of any use at all.

Encrypted data is a binary blob that cannot be examined or used in any meaningful way until it is decrypted. That means you can't index it, you can't sort it, you can't look it up, or anything else you would normally do with information.

One way to have data technically encrypted but still usable is to use whole-drive encryption (such as TrueCrypt) on the storage medium. The data is nominally encrypted, because it isn't stored on the disk in plain-text form (nothing on the drive is), but then again, the encryption doesn't offer any protection at all within the on-line server, since the system automatically decrypts everything on-the-fly. An intruder wouldn't even know it was encrypted.

Credit card data is encrypted because the merchant agreement demands it be so. But the encryption keys are almost always stored right next to the data itself, so that it can be decrypted for use. The whole situation is arguably a bit farcical, but since it's mandated, it's practiced. Note that credit card data differs significantly from personal data in that it is an opaque value that is used only occasionally. The average company never has to sort credit card numbers, or arrange them in groups, or use them for lookups, or other operations that you would expect with things like names or addresses.

So while you could encrypt the rest of the dataset, it would have to be immediately decrypted before the database could perform any useful function, just as credit card data must be decrypted before it can be used in a transaction.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • " the encryption doesn't offer any protection at all within the on-line server, since the system automatically decrypts everything on-the-fly" - which is generally true of any 'encrypt-data-at-rest' solution. no need to break crypto when you can simply ask the system to decrypt for you. – frankodwyer Apr 29 '11 at 16:01
  • This seemed true until homomorphic encryption was invented. Now it's just slow and difficult.... – nealmcb May 10 '11 at 02:31
  • @nealmcb: homomorphic encryption only allows for basic math operations on the cipher text, and is by necessity write-only. It wouldn't be particularly useful except in very specific scenarios. – tylerl May 12 '11 at 02:38
  • I'm not claiming that I know of a lot of general applications now, or that we can be sure they will ever be practical. But "basic math operations" are all you need to compute *any* "computable function" - Turing completeness. So if they get more efficient FHE systems, who knows where it will end up. See [Homomorphic encryption - Wikipedia](http://en.wikipedia.org/wiki/Homomorphic_encryption). What do you mean by "write-only"? – nealmcb May 12 '11 at 05:06
  • You can't have a *zero* function with a system based on homomorphic encryption, so it can't be turing complete. You can increment existing symbols, but you can't interpret the results or create fresh symbols. You can't write, you can't read, you can only modify. This is a very limited computational system, and cannot be made turing complete. In practical terms, you can use this cryptosystem for things like tallying votes, but you can't use it for things like sorting, lookups, set comparisons, etc. – tylerl May 12 '11 at 07:24
  • Well, all the cites I've seen say you can get turing-completeness. I'm not the right person to continue this discussion, but if you do think some top-notch crypto folks are wrong (and have some edits for the Wikipedia article), I suggest responding to their on-topic answers here: [In what ways does Full or Partial Homomorphic Encryption benefit the cloud?](http://security.stackexchange.com/questions/3728) – nealmcb May 12 '11 at 21:22
0

Tyler's answer above is excellent, in that it makes a distinction between encrypting data and using data. Any time you want to use the data, it has to be decrypted. That means you can encrypt the customer data, but anyone who needs to use it has to decrypt it, and at that point, you have non-encrypted data again.

Hackers can take advantage of this by hacking the system where decryption takes place, or where the data is accessed from, and accessing it from there. So encrypting data is definitely not a good defence against hackers, it's more of a defence against physical thieves, for example if your laptop is encrypted to a password only you know, the thief can steal the laptop, but they won't get your password.

I wrote a blog post about this very issue a while back that goes into a bit more detail, if anyone wants to read more: https://intruder.io/blog/posts/why-encryption-is-not-the-answer

chwallis
  • 1