As you may know, there is an ongoing struggle in Catalonia for self-determination. The Catalan government is planning to hold a referendum on independence on October 1st 2017. The Spanish government, on the other hand, is determined to prevent this referendum because they consider it illegal. As a result, it has taken the following measures to thwart the vote: it has censored websites, seized millions of ballot papers, used military police to intercept mail with information on where voters can cast their vote, put people in jail, etc.
However, in this post rather than focusing on politics, I want to highlight how the Catalan government is using a rather unorthodox but interesting method to inform its citizens on where to go to vote. I will walk through the information the voter needs to provide, how it is handled in order to give back the relevant data to the voter and the pros and cons of that method.
The Catalan Government launched a website so that voters could check where to cast their vote on October 1st. In that website the user is asked to enter the following information:
After the user enters this data an async request takes place, and when it finishes, if there is a match the user is provided with the information about where they should vote.
Pretty standard stuff, right? However, there is one important detail: the data entered by the user never leaves the browser. The request that takes place when the user hits the submit button is a
fetch request that looks like this:
X is a hexadecimal digit. The response contains between 70 and 100 lines of what it seems to be encrypted records.
I admit that when I first saw that I freaked out a little. It seemed pretty obvious that the whole database was being exposed in little chunks. And yep, I looked at the JS code and that’s exactly what is happening. There are 65,536(
0xFFFF) different DB chunks publicly accessible to anyone.
My concern was whether a user would be able to decrypt just their data or the whole database. As I dug into the code I realized that in fact things are not as bad as they initially looked. On the contrary, this is what actually happens when the user hits the submit button:
My hypothesis is they did this for two reasons:
First off, even if a malicious user is able to “decrypt” the whole DB the only info that they could obtain would be the last 6 characters of the national ID, with a DOB and a postal code. I’m having a hard time coming up with possible malicious uses of that information. There are no names, no addresses, no social insurance numbers, etc.
The only data that’s a bit sensitive is the national ID number and the first 3 digits are trimmed. So, if a malicious user could get a hold of a few records using a brute-force attack they wouldn’t get much. It’s worth pointing out that case, because the last digit of the National Id is a letter that gets computed using the
mod(23) of the numbers. So, the attacker would be able to narrow it down to a list of ~43 possible candidates, rather than a thousand.
What if an attacker wants to get a hold of all, or most of that data, using a brute-force attack? How many samples would they need to run it against?
(75 – 18) * 365 = ~20,805
Therefore, in order to “decrypt” most of the data the attacker would need to use a brute-force attack against ~54,837,819,000,000 keys. It would take ~850 years for my current computer to be able to process all those keys.
Of course, it would be possible to try brute-force attacks for the “low hanging fruit”: postal codes with higher population while narrowing down the age ranges between 30–50. So, yep, it’s possible to get a hold of a few records. Although, it is probably not very useful.
Mainly because I think that this is interesting and I would like to know your opinions on this method.
Full disclosure: I’m not a nationalist, but I’m pro-independence. I would like for the referendum to take place, but I do value privacy and security. So, for me ensuring that this method is safe is paramount.