2

I did check out the previous postings and didnt find what I was looking for- apologies if this is a repetition.

I am working on an analytics engagement for a customer and he needs to share access to his customer sales transactions for me to do my work. The idea was to create a encryption routine whereby details such as SSN and Zip would be anonymized so that I wouldnt have access to PII data. When I present the findings, he needs to have the ability to see the original data back from the garbled text I work with.

From a definition perspective, I understand masking/ obfuscation would hide the details and possibly impact referential integrity. I read on tokenization and believe it is quite a complex model. I am probably missing a nuance here...

I really don't care for the process time for encrypt/ decrypt- that is not relevant and processing cost can be ignored. Just need a way for SSN : 123-45-6789 to be encrypted consistently to say, A467YuGHT, so I can work unimpeded and the customer is comfortable that no data that he has shared with me violates customer PII. When I submit a report stating that A467YuGHT is a potential churn, he deciphers it back to 123-45-6789 [there are too many such PIIs for me to create alternate identifiers]

I was thinking of a private key(which customer retains) /public key to do this- Am I missing something here? Any open source tool that does this

Improve this question

4 Answers 4

Reset to default
2

I understand your issues, but one of the fundamental maxims of cryptography is that you shouldn't reinvent the wheel and create your own encryption algorithm, primarily because it will be nowhere near as secure as an established one.

Is this data going to be accessible over the Internet or transmitted over unencrypted channels? If the answer to either of those is yes, the risk factor rises exponentially. If you use your own home-baked efforts at obfuscation, all it takes is a determined hacker to find this out and they will have all of your SSN details.

How could they find it? What if you customer leaves something lying around telling him how to decrypt? What if your email gets hacked? What if you server isn't as secure as you thought it was?

You really need a solution where if any of those things happen an adversary still couldn't decrypt the data, and really that only comes with established public-key infrastructure. Sure there are ways to defeat that, but unfortunately the reality is that they are a lot more difficult than it would be to compromise a home-grown encryption algorithm.

Improve this answer
1
  • the channel is encrypted- so the only risk is with someone laying their hands on the private key which hopefully is secure!! would you recommend something like this, based on RSA algorithm goldenpackagebyanuj.blogspot.in/2013/10/…
    – raghu
    Commented Jul 3, 2014 at 21:29
2

I recommend you to keep it simple. You could simply AES the fields you need to protect.

Independently of the encryption method you use you must encrypt together some fields:

  • Name + Surname
  • Date of birth
  • State + Street number + Street name *...

Otherwise you could try statistical analysis against the data.

Improve this answer
2
  • I understand AES is symetric. Isn't there a potential risk that I decrypt and access PII. For my customers to have full comfort, should we use asymetric keys(RSA)
    – raghu
    Commented Jul 4, 2014 at 0:23
  • 1
    The only way you could do that is by cracking the AES key, which is infeasible
    – miniBill
    Commented Jul 4, 2014 at 6:33
0

Most if not all database engines support 'encrypted columns' which securely stores the data, so in this way yes there are tools that do this for you.

Next you have the issue of searching based on those encrypted columns.

https://dba.stackexchange.com/questions/23908/how-to-search-a-mysql-database-with-encrypted-fields

The quick explanation is that you store a hash of the data alongside the encrypted data. You can query and join on that column only if you know what that column contains, so this technique is only feasible for data that the user explicitly knows for the entry point (input parameters) of the query, but after that you should be able to join but only on exact matches, as even a whitespace encoding mismatch will cause an avalanche effect on the hash.

Improve this answer
0

Why don’t use just use a tool like IRI FieldShield (works on any DB and flat-file via Eclipse or command line) and apply AES-256 format-preserving encryption as a rule across the SSN and ZIP code columns across your sources? That preserves realism, referential integrity, restricted access, and reversibility all at the same time.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .