Com el govern català utilitza l’IPFS per frenar el bloqueig judicial d’Espanya

Article original set-2017

Autor: Marc Pujol. (Basis Informatica)

Catalunya té una llarga història de moviments independentistes i fins i tot s’ha declarat independent en diverses ocasions al llarg de la història. Actualment, l’ambient polític està molt caldejat. Una majoria dels catalans volen convocar un referèndum per a la independència, amb una part important de la població declaradament independentista.
Resumint, Catalunya va acabar organitzant unilateralment un referèndum sobre la seva independència per al dia 1 d’octubre del 2017. Els tribunals espanyols han declarat el referèndum il·legal, i el govern central està fent tot el possible per aturar-lo. Una de les accions d’Espanya per intentar frenar la votació ha estat bloquejar totes les webs a favor del referèndum. Això ha inclòs l’assalt dels ISP per part dels agents de la Guàrdia Civil, embargant les webs que ofereixen informació sobre el referèndum, i fins i tot processant als qui les han clonat.

On votar?

Generalment, als ciutadans se’ls informa sobre on han d’anar a votar mitjançant una notificació oficial per correu postal. En aquest cas, com que Correus està controlat per l’Estat, les notificacions serien requisades tan bon punt el govern català les enviés.
Si les webs relacionades amb el referèndum estan tancades i no hi ha cap possibilitat per al correu postal, com se suposa que el govern català ha de notificar a les persones els seus col·legis electorals assignats?

 

La resposta de Catalunya

La solució de Catalunya implica l’IPFS, una mica de criptografia i d’enginy. Aquest és el lloc web resultant (del 27 de setembre): Referèndum 2017. Vegem com funciona!

Una web emmagatzemada a l’IPFS

La web es publica a través de https://ipfs.io, que té diversos avantatges per a aquest propòsit:

1. L’ús d’un TLD internacional fa difícil que Espanya pugui exigir una redirecció del domini cap als seus propis servidors (cosa que ha estat fent en els dominis .cat).
2. El propietari del domini no està relacionat amb la “causa independentista” de cap manera. Això encara fa més difícil justificar jurídicament les accions empreses contra el domini, i més encara quan aquestes accions les haurien de dur a terme les autoritats del Regne Unit (perquè el TLD .io opera des del territori del Regne Unit).
3. Òbviament, és una web https, i això dificulta la manipulació dels continguts mitjançant atacs MitM a través dels ISP. El govern pot obligar els ISP a bloquejar tot el trànsit cap a/des de les adreces IPFS, però no pot obligar els ISP a mostrar un altre lloc web sense que es disparin avisos de certificats incorrectes en els navegadors.
4. Si Espanya tallés totes les connexions cap a/des de ipfs.io, encara es podria accedir al contingut (i clonar-lo) perquè ipfs.io és un proxy per al sistema de distribució de continguts IPFS. Qualsevol pot descarregar el client IPFS i obtenir accés a tot el contingut que s’hi emmagatzema en qualsevol moment.

 

El primer avantatge d’IPFS és que la distribució de continguts es fa d’igual a igual (peer-to-peer), que significa que els usuaris connectats s’envien la informació directament entre ells, sense que hi hagi cap punt central susceptible d’ésser atacat. Per tant, és gairebé impossible que qualsevol actor pugui bloquejar l’accés a aquest contingut perquè es reprodueix per la xarxa utilitzant connexions xifrades entre usuaris, que serien molt difícils d’identificar i bloquejar a nivell d’ISP. Potser la Xina podria fer-ho, però definitivament Espanya no té aquesta capacitat.

L’altre avantatge d’IPFS és que els continguts són adreçats pel seu contingut (content-addressed). Això vol dir que l’adreça per accedir a un contingut és derivada del propi contingut. És a dir, si canviés el contingut, l’adreça canviaria també. Això soluciona qualsevol possible manipulació: els responsables catalans poden distribuir l’adreça de la pàgina d’inici, i tothom pot estar segur que tot el contingut enllaçat des d’aquest fitxer ha estat publicat per les autoritats catalanes, sense haver estat alterada per ningú altre.

Amb tot, hi ha un repte important quan es fa servir aquest esquema: per ser eficaç, tota la informació que la web utilitza ha de ser pública (perquè qualsevol persona pot accedir a tots els continguts emmagatzemats a l’IPFS). Altrament, caldrien servidors per mantenir la informació no pública, i els adversaris podrien atacar-los i fer que la qualitat de l’IPFS no fos efectiva.

Per tant, el govern català havia de compilar d’alguna manera una base de dades que es pogués distribuir dins l’IPFS i consultar fàcilment utilitzant URL directes o com a màxim un javascript (codi que s’executa en el navegador dels usuaris). Vegem com ho van fer.

 

Una base de dades estàtica

En altres eleccions, els ciutadans podien comprovar el seu col·legi electoral assignat en una pàgina web del govern. Per fer-ho, havien d’introduir una part limitada de la seva informació personal (data de naixement, DNI i codi postal actual) i, si era correcta, obtenien el col·legi electoral assignat.
Aquesta solució no és ideal, ja que es pot utilitzar per “omplir els buits” d’informació sobre qualsevol ciutadà. Si saps la data de naixement d’algú i la zona on viu, pots obtenir el seu DNI procedint per tempteig en aquella web. Per descomptat, amb una web estàndard aquest problema es pot mitigar: el servidor pot implementar controls de velocitat, bloquejar adreces IP, etc., per tal que aquests tipus d’atacs no siguin factibles.
Tanmateix, en aquest cas Catalunya no pot utilitzar servidors, perquè això facilitaria el camí a les autoritats espanyoles per fer la web inoperant. La web ha de ser totalment estàtica i la base de dades s’ha de distribuir amb ella. Per veure com ho van fer, primer considerem de quina manera la web demana aquesta informació. A la pàgina on votar?, es requereix que s’introdueixin aquestes dades:

DNI: format per 8 dígits +1 lletra de control. Tot ciutadà espanyol té el seu DNI. Amb tot, la web només utilitza els darrers 5 dígits i la lletra de control, per tant, la forma és sempre [0-9]{5}[A-Z].
Data de naixement: en format AAAAMMDD.
Codi postal: un número de cinc dígits.

Aquesta informació es combina per formar una clau que s’utilitzarà per buscar el corresponent punt de votació. Això planteja un tema de privacitat potencialment enorme, perquè, si aquestes claus es publiquessin en text simple, s’exposarien les dades personals de tots els ciutadans catalans!. Bé … com ho van fer?

Aquí entra la criptografia

Adaptat perquè s’entengui d’una manera més senzilla, el codi que busca el punt de votació és el següent:

 

function lookup(dni, birth, zip, callback) {
  var key = dni + birth + zip;
  var passkey = sha256_times(key, 1714);
  var search = sha256(passkey);
  var dir = search.substring(0, 2);
  var file = search.substring(2, 4);
  var path = db_path + dir + "/" + file + ".db";
  var lines = readfile(path).split("\n");

  lines.forEach(function(line) {
    if (line.substring(0,60) == search.substring(4)) {
      found = true;
      var plaintext = decrypt(line.substring(60), passkey);
      callback(plaintext.split('#'));
    }
  })
  if (!found) {
    callback("not-found");
  }
}

 

Hi ha tres funcions criptogràficament interessants aquí. Comprovem-ne el codi per entendre què fan exactament. Cal tenir en compte que les funcions crypto. vénen directament del paquet crypto del node:

 

function sha256(text) {
return crypto.createHash(‘sha256’)
.update(text)
.digest(‘hex’);
}

function sha256_times(text, times) {
var result = text;
for (var x=0; x < times; x++) {
result = sha256(result);
}
return result;
}

function decrypt(text, key) {
var decipher = crypto.createDecipher(‘aes-256-cbc’, key);
var dec = decipher.update(text, ‘hex’, ‘utf8’);
dec += decipher.final(‘utf8’);
return dec;
}

 

No és gaire complicat. Bàsicament, el codi executa un còmput sha256 1714 vegades per obtenir una contrasenya per al desxifrat i una altra vegada per obtenir la clau de cerca. Llavors, aquesta clau de cerca s’utilitza per localitzar una o més línies coincidents, i la contrasenya es fa servir per desxifrar el contingut d’aquesta línia (el resultat de la qual es la informació sobre el punt de votació).

No sóc un expert en criptografia i, per tant, aquí no puc identificar cap error obvi. Em sembla que la informació personal només es pot recuperar per força bruta. Però quant costaria de fer, això? Calculem-ho sobre la base del que disposem.

 

  • La part del DNI té 10^5 * 23^1 combinacions possibles (només hi ha 23 lletres possibles).
  • La part de la data de naixement té aproximadament 365 * 100 (suposem que ningú té més de 100 anys).
  • Pel que fa al codi postal, les possibilitats es poden reduir si suposem que la gent viu a Catalunya. Això s’explica perquè els codis postals espanyols estan formats pel codi de la província de 2 dígits (2-digit) més els tres dígits (3-digit) del municipi. A Catalunya només hi ha 4 províncies i, per tant, només hi poden haver 4 * 10^3 codis postals possibles. Encara ho podríem reduir més perquè realment no es fan servir tots els codis postals i qualsevol persona pot obtenir fàcilment una llista completa dels codis vàlids, però, per fer una estimació, això ho ignorarem.
  • Combinant-ho tot, tenim aproximadament 10^10 * 23 * 365 * 4 = 33580*10^10 combinacions possibles. Per tant, l’espai de la clau és d’uns 48 bits.

 

Això sembla molt baix. Amb hardware modern sembla que s’hauria de poder transformar tota la base de dades en una base de dades de text sense format, si es té paciència i prou diners. Si suposem que hem de calcular 1715 sha256 hashes per comprovar si una clau generada es troba en la base de dades revisant tot l’espai requeriria 575897 * 10^12 hashes. Fent servir el bitcoin wiki com a referència, podem trobar alguns números

 

 

Maquinari    | Hashes/s    | Temps aproximat    |
AntMiner S9    | 28 * 10 ^ 9    | 238 dies    |
AMD 7970    | 825 * 10 ^ 3    | 20870 anys    |
Nvidia Tesla S2070    | 749 * 10 ^ 3    | 24381 anys    |

 

Amb aquestes xifres, no sembla viable per a un hacker solitari com jo, però sí que seria possible per a un atacant amb prou recursos. A més, considerem que aquest és l’esforç que caldria per construir tota una base de dades de text sense format. Si sabeu el DNI d’algú i on viu, probablement podreu descobrir la seva data de naixement només amb el vostre portàtil i sense necessitar gaire temps.

 

Què en podem aprendre?

Hi ha una cosa que tots els programadors hauríem de saber, però no sempre en fem cas: busqueu un expert abans d’usar tècniques criptogràfiques. És massa fàcil cometre errors en aquests temes, i els resultats solen ser catastròfics.
En aquest cas, l’errada ha estat en usar la funció de hash sha256. Aquesta funció hash està dissenyada per verificar informació, on l’objectiu és poder-la calcular el més ràpid possible! Òbviament això ha anat en la nostra contra, ja que és el que permet que, amb el hardware adequat, un atacant pugui arribar a desxifrar tota la informació.
Enlloc d’usar un hash de verificació criptogràfica (com sha256), hauríem d’usar un hash de la família de les funcions de derivació de claus (key-derivation functions) com ara pbkdf2. Aquestes funcions hash estan dissenyades específicament per ésser costoses de computar, inclús a nivell de hardware. D’aquesta manera, els temps que hem vist amb GPUs aplicarien a qualsevol tipus d’atacant, sense importar la quantitat de recursos dels que disposés. Una petita errada de concepte que els ha fet la feina 20.000 cops més fàcil als nostres adversaris!

 

Temes oberts

Ja hem vist que és possible (tot i que difícil) reconstruir tota la base de dades en text pla. Això significa que el govern català ha revelat potencialment una base de dades que conté part de la identificació dels ciutadans, dates de naixement, codis postals i col·legis electorals. Cap d’aquestes dades és crucial (se suposa que els DNI espanyols no són secrets), però si aquestes tècniques es van fent més comunes, això podria acabar malament (especialment quan la gent comenci a creuar diferents bases de dades).

Finalment, hi ha un possible “problema polític” sobre tot l’enfocament per com evitar el bloqueig d’Espanya. El sistema IPFS garanteix més o menys la disponibilitat de la informació, però no garanteix l’anonimat. Tingueu en compte que Espanya ja està instant la imputació de càrrecs contra almenys 10 persones que van clonar aquesta web. Aleshores, podrien afegir fàcilment un node IPFS que recollís els IP dels ciutadans que la compartissin a través de l’IPFS i imputar-los també.

En definitiva, creieu que la jugada de Catalunya ha esta bona o dolenta? Què podrien haver fet d’una altra manera? Aquest enfocament és sòlid per a tots els qui intenten evitar tota mena de censura estatal?
Quins dies més emocionants per a un hacker català!