Majutusasutus peaks nägema vaid oma kliente

Artikli juures on esitatud plaane ka kavandatava süsteemi andmekaitselahenduste kohta. Planeeritud lahenduse kohta on esitatud järgmised väited:

1. Andmetöötlus on automatiseeritud ja inimeste nimesid tuvastatud kujul ei liigu
2. Andmed anonüümitakse
3. Ainult tabamuse saanud registreerunud jõuavad politsei töölauale, kui tegu on tagaotsitava inimesega
4. Sellist asja ei saa olla, et tekib ülevaade, millises hotellis ja kellega me käime, selliseid päringuid ei saa ega tohi süsteemis teha

Detaile ei ole kahjuks jagatud, seega ei ole võimalik süsteemi täpselt analüüsida ning kõik siin arvamusloos kirjutatu on puhas fiktsioon. Küll aga võime mõtiskleda, kuidas lubatut teostada saaks. Esmalt, aga paneme paika mõned eeldused.

Vähim komplekt osapooli, kes võiks (väga lihtsustatud kujul) süsteemi töös hoida, on järgmine:

1. Majutusasutus, kuhu tuleb külastaja, kes esitab oma dokumendi. Majutusasutusel on kohustus andmed edastada elektroonse majutuskaardi vormis
2. Elektroonse majutuskaardi teenuse pakkuja, kes kogub kaarte ja võrdleb neid tagaotsitavate nimekirja(de)ga
3. Politseiametnik, kes saab teada, kui mõni tagaotsitav on kuskile majutusasutusse jõudnud

Mõned turvaeesmärgid on lihtsad sõnastada. Näiteks peaks majutusasutus nägema vaid oma kliente, midagi teenuse poolelt tagasi ei tohiks saada. Politseiametnik peaks nägema vaid seda, et tagaotsitav on kuskil majutusasutuses ja siis toetavat infot, mis aitaks teha järgmist otsust.

Aga milline peaks olema teenusepakkuja turvaeesmärk? Täna levinud tehnoloogiliste lahenduste puhul peaks teenusepakkuja nägema nii kõiki majutuskaarte kui ka kõiki tagaotsitavate loetelusid. See aga tähendaks, et teenusepakkujale tekiks ikkagi andmebaas sellest kes on kus ja kellega samas kohas ööbimas käinud. Vt joonist.

Väidetud on, et andmed on anonüümitud, seega peaks nad seda olema ka teenusepakkuja juures. Kuidas seda teha saaks?

Tavapärased anonüümimise vahendid, mille käigus eemaldatakse isikustavad tunnused nagu nimi või isikukood, ei sobi. Peame ju suutma otsingunimekirjadega teha võimalikult täpset võrdlust.

Tehnilisemalt mõeldes tundub, et abi oleks krüptograafiast, võiksime teenusepakkuja juurde kogutada andmeid räsitult või deterministlikult krüpteeritud kujul. Viimane tähendab seda, et isiku nimi on krüpteeritult alati samasugune. See on erinev tavapärasest sides või salvestuses kasutatavast krüptograafiast, kus iga kord, kui minu nimi krüpteeritakse, on tulem erinev. Paraku ka see lahendus aga ei ole antud rakenduses sobilik.

Teenusepakkuja, teades räsi- või krüptograafilist algoritmi, saab lihtsalt räsida/krüpteerida ära kõik isikukoodid (vaid 10 miljonit) või levinumad/huvitavamad nimed ning siis saadud “telefoniraamatut” oma tabelitega võrrelda. Nii õnnestuks tulem taas isikustada. Selgitus taas juuresoleval joonisel.

Abi oleks privaatsest hulkade ühisosa leidmise (inglise keeles private set intersection) tehnoloogiast. Need on täiesti olemas ja tuginevad keerukamatele krüptograafilistele algoritmidele, nagu näiteks turvaline ühisarvutus, homomorfne krüptograafia, turvalised käivituskeskkonnad. Tehnilised lahendused on olemas, kuid eeldavad, et teenusepakkujad on nõus andma ära kõigi andmete nägemise võimu.

Paraku ei ole privaatse ühisosa leidmise lahendused nii kergesti joonistel esitatavad. Seega peame nentima – süsteemi keerukus kasvab.

Kokkuvõttes, kui süsteemi käitumine on selgelt kavandatud, siis on võimalik see kavandada lõimprivaatsuse (Privacy-by-Design) põhimõtteid kasutades nii, et teenuse peamine eesmärk saab edukalt saavutatud.

Ja kui tekib hirm, et äkki moodne tehnoloogia on kallis, siis tuleks alustada hinna küsimisest ja siis võrrelda seda näiteks alternatiivsete lahenduste kuluga.