2

I am trying to figure out a secure way to store secret keys used in the hashing of social security numbers.

The idea is for de-identification of research subjects yet still permitting follow-ups over time by hashing a secret key concatenated with the SSN and using that as the unique identifier.

The steps I conceived of is the following:

  1. At time 0, when data on subject A is collected, randomly generate a secret key and concatenate it with the SSN before hashing it.
  2. Replace the SSN with the hash value. This de-identified record will be used for research purposes.

  3. Store the SSN and generated secret key somehow.

  4. At time 1, when further data of subject A is collected, we want to append this new data to the data collected previously. Search for the secret key using the SSN and then hashing again to get the required hash value.

I am struggling in Step 3 and looking for best practices in such a scenario. It seems that if I were to just store the SSN together with the secret key in a text file then the risk for reidentification is high once the intruder gets access of the file.

Any help is greatly appreciated!

Improve this question
10
  • How would the hashing improve security? You could just generate (securely) a random number every time and use that as the new identifier - one less step to worry about. You still need to store the mapping from the SSN to the new identifier somewhere secure.
    – Erwin Bolwidt
    Jun 6, 2018 at 7:46
  • 2
    If you use a different secret key for hashing each SSN then you could use the key instead of the SSN without the need for hashing. The common way is to use a single secret for all SSN instead and then you just need to limit access to this single secret. The efforts needed to protect this secret then depend on the actual requirements, but could also be done hardware-based with the help of a smart card or similar. Also note that what you are doing is not de-identification but only pseudonymization, i.e. given enough pseudonymized data it might still be possible to identify the subject.
    – Steffen Ullrich
    Jun 6, 2018 at 7:47
  • @ErwinBolwidt I can’t do that because I still want to be able to identify the 2 data as belonging to the same person using some value, just that it is not via SSN. I thought that using a hash value instead would be good.
    – GAN
    Jun 6, 2018 at 7:51
  • @SteffenUllrich Thanks for pointing out the difference between de-identification and pseudonymizatiom. is there no added benefits in using a different key for each user? Also are there non-hardware based method in protecting the secret key?
    – GAN
    Jun 6, 2018 at 7:58
  • @GAN: Again, if you have a single unpredictable secret per SSN then you don't need hashing the SSN but just use the key directly. With the same key instead for hashing many SSN you can instead concentrate of securing access to this (small) key. As I said, hardware based method is just one of several options to secure the key. To actually recommend a specific method one first need to know your requirements, i.e. a risk analysis of what kind of attacker you expect and how much risk you are willing to accept. The more capable an attacker is the harder (and more costly) the protection will be.
    – Steffen Ullrich
    Jun 6, 2018 at 8:12

1 Answer 1

Reset to default
1

All I can think of is....

1) Use a lookup table to map SSNs to salts (or random identifiers for the persistent anonymized data) but keep this a long way away from the persistent, anonmyzed data. Both the datasets need to be compromised to resolve the data.

2) as per 1 but key the random value/random salt by a hash of the SSN (and keep the lookup table seperate). This adds some Security value over 1, but not a lot. Both datasets need to be compromized for the data to be resolved.

3) as per 2 but hash the SSN key using a static salt (i.e. storing hash($ssn, "staticsalt")->secret). Ideally keep the satic salt somewhere other than the 2 existing data stores. Once again this only adds a little Security value

4) use other information about the subject (if available) to increase the amount of entropy in the data used to create the hash. This would make it more difficult to deanonymize the data but doesn't impact the ability to find an individual in the dataset if their details are known.

Improve this answer

You must log in to answer this question.

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