Ĉu WhatsApp estas vere sekura? La problemo de la finoj kiujn vi ne kontrolas
Serio pri WhatsApp, 2/2. En la unua artikolo mi rakontis kiel mi preskaŭ perdis dek unu jarojn da mesaĝoj pro sekurkopio kiun WhatsApp ne sciis restaŭri. Kiam mi petis la ŝlosilon de mia propra dosiero, la subteno respondis al mi per la reklamo de la fin-al-fina ĉifrado: «nadie más, ni siquiera WhatsApp» povas legi viajn mesaĝojn. Pri tiu frazo temas ĉi tiu artikolo.
TL;DR — Mi ne havas tempon por legi tiel longan tekston nun
WhatsApp ripetas ke niaj konversacioj estas protektataj per "fin-al-fina ĉifrado" kaj ke, sekve, "eĉ ne WhatsApp" povas legi ilin.
La fin-al-fina ĉifrado estas reala kaj estas tre grava protekto. Sed tiu aserto kaŝas fundamentan kondiĉon:
la ĉifrado protektas la komunikadon inter la finoj, sed ne garantias ke la finoj mem estas fidindaj.
Kaj "la fino" ne estas ĝuste vi. Ĝi estas la programo kiu ruliĝas en via telefono aŭ komputilo.
Se la provizanto kontrolas tiun programon, povas ĝisdatigi ĝin, povas decidi kiuj versioj plu funkcias kun ĝia servo, kaj vi ne povas sendepende revizii la binaron kiun vi rulas, tiam vi plu bezonas fidi la provizanton.
La tezo de ĉi tiu artikolo estas do:
Neniu E2EE-sistemo povas doni fortan garantion kontraŭ la provizanto mem se la uzanto ne povas scii precize kiun kodon rulas la finoj, kontroli ĝin kaj, en la plej postulema modelo, kompili ĝin kaj regi kiam ĝi ĝisdatiĝas.
Tio ne pruvas ke WhatsApp spionas niajn mesaĝojn nek ke ekzistas malantaŭa pordo por registaroj aŭ sekretaj servoj.
Ĝi pruvas ion pli modestan sed gravan:
Ni ne povas transformi la aserton "WhatsApp diras ke ĝi ne povas legi ilin" en la teknikan econ "WhatsApp ne povus igi nian finpunkton transdoni ilin".
La diferenco estas inter fido kaj kontrolo.
"Eĉ ne WhatsApp povas legi viajn mesaĝojn"
Unu el la ĉefaj privatecaj promesoj de WhatsApp estas la fin-al-fina ĉifrado, kutime mallongigita E2EE, el la angla "end-to-end encryption".
La principo estas bonega.
Kiam Alico sendas mesaĝon al Bernardo, la mesaĝo devus esti ĉifrata en la aparato de Alico kaj ne malĉifrata ĝis ĝi atingas rajtigitan aparaton de Bernardo.
Simpligante:
Figura 1
Tio protektas kontraŭ tre gravaj minacoj.
Persono kiu interkaptas la trafikon ne devus povi legi ĝin. Enrompo en certajn servilojn ankaŭ ne devus doni rekte la enhavon de ĉiuj konversacioj. Kaj la servilo kiu transportas la mesaĝojn ne bezonas koni la plaintext.
WhatsApp asertas krome, en sia privateca politiko, ke la transdonitaj mesaĝoj estas forigataj de ĝiaj serviloj kaj ke la ankoraŭ ne transdonitaj estas konservataj, ĉifritaj, dum maksimume 30 tagoj.
Ĉio tio estas grandega sekureca plibonigo.
La problemo komenciĝas kiam ni transformas ĉi tiun aserton:
"La serviloj de WhatsApp normale ne disponas pri la enhavo nek pri la ŝlosiloj necesaj por malĉifri ĝin."
en ĉi tiun alian:
"WhatsApp ne povus akiri miajn konversaciojn."
Ĝi ne estas precize la sama aserto.
Kio vere estas "la fino"?
En nia imago, E2EE signifas:
mi <====================> vi
E2EESed, teknike, ĝi pli similas al:
Figura 2
La ĉifrado ne komenciĝas rekte en mia cerbo nek finiĝas rekte en la via.
Ĝi komenciĝas kaj finiĝas en programoj.
Tial, post demandi:
"Ĉu la komunikado estas ĉifrita?"
ni devus tuj demandi:
"Kiu kontrolas la programon kiu konstituas ĉiun finon?"
Tiu dua demando estas ĝuste tiu kiu preskaŭ ĉiam malaperas el la reklamo pri E2EE.
Iam la mesaĝo devas esti klara
Estas neevitebla limigo.
Se mi povas legi mesaĝon sur la ekrano, mia aparato devis malĉifri ĝin.
Tial, iam ni havas:
Figura 3
La kriptografio finis sian laboron.
De tiu momento la sekureco dependas de la finpunkto.
Kaj tio signifas ke hipoteze malica aplikaĵo ne bezonus rompi la kriptografian protokolon.
Ĝi ne bezonus malkovri ŝlosilon per kruda forto.
Ĝi ne bezonus matematike ataki la Signal-protokolon.
Koncepte, sufiĉus ke ĝi faru:
decrypt(message)
display(message)kaj, krome:
send_copy(message)Tio estas:
Figura 4
La E2EE-protokolo povus resti senmakula.
La servilo povus plu ne scii malĉifri la ciphertext.
La ŝlosiloj povus eĉ plu ne formale forlasi la aparaton.
Sed la plaintext jam estis akirita de la aplikaĵo.
La ĉifrado ne estis atakita. La fino estis atakita.
Kaj se la provizanto mem kontrolas la finon?
Jen aperas la interesa koncepta konflikto de WhatsApp.
WhatsApp diras al ni:
"Nia servilo ne povas malĉifri viajn mesaĝojn."
Sed estas la sama provizanto kiu distribuas la programon kiu:
- generas aŭ administras la ŝlosilojn;
- ricevas la mesaĝojn;
- malĉifras ilin;
- atingas ilian enhavon;
- konsultas la lokan datumbazon;
- montras la konversaciojn;
- kaj komunikas kun siaj serviloj.
Tial:
Figura 5
La E2EE malhelpas ke la servilo rekte ataku la kriptografian kanalon.
Sed ĝi ne garantias per si mem kion faros morgaŭ la programaro kiu alvenas al unu el la finoj.
"Sed la aplikaĵo estas subskribita"
Jes.
Kaj tio estas tre grava kontraŭ malsama kontraŭulo.
La kriptografia subskribo de aplikaĵo helpas malhelpi ke nekonato kreu modifitan APK kaj facile prezentu ĝin kiel legitiman ĝisdatigon de WhatsApp.
Sed la subskribo respondas proksimume al:
"Ĉu ĉi tiu programaro venas de la rajtigita ĉeno?"
Ĝi ne respondas al:
"Ĉu ĉi tiu programaro faras precize la samon kiel la antaŭa versio?"
Se estas la sama rajtigita programisto kiu publikigas novan version, la nova programo plu estos perfekte subskribita.
Figura 6
Subskribo kaj funkcia fido estas malsamaj konceptoj.
"Do mi ne ĝisdatigos WhatsApp"
Unuavide tio povus ŝajni solvo.
Se mi fidas version 2.X kaj mi ne volas ke iu ŝanĝu ĝin, mi malŝaltas la ĝisdatigojn.
La problemo estas ke tio donas al vi nur partan kontrolon.
Vi povas provizore malhelpi ke Google Play aŭtomate instalu novan version, sed vi ne kontrolas la servilon nek la protokolon de WhatsApp.
La provizanto povas modifi:
- la akceptatajn protokolojn;
- la minimumajn kompatiblajn versiojn;
- la registriĝajn postulojn;
- la funkciojn kiuj bezonas subtenon de la servilo.
Tial vi ne havas garantiitan la eblon uzi senfine malnovan version kiun vi decidis frostigi.
Tiu diferenco estas esenca:
"Mi povas malŝalti la aŭtomatajn ĝisdatigojn" ne egalas al "mi kontrolas kiu versio de la kliento plu funkcios".
En sistemo vere sub via kontrolo vi povus decidi:
Figura 7
En centralizita servo, la servilo ĉiam havas la lastan vorton pri kio plu estas kunfunkciebla.
Ĉu ili povus sendi specialan version nur al unu persono?
Estas ebleco kiu postulas nuancojn.
Google Play disponas pri "staged rollouts", tio estas, laŭgradaj disvolvoj kie nova versio atingas komence nur procenton de la uzantoj.
Sed laŭ la dokumentado de Google, en la ordinaraj laŭgradaj disvolvoj la uzantoj estas elektataj hazarde ene de la responda procento. Ne estus do korekte diri ke la normala sistemo de Play permesas simple ordoni:
"Instalu ĉi tiun specialan APK precize al la telefonnumero X."
Sed tio ne solvas la ĝeneralan problemon.
Programo povas enhavi funkciojn kies konduto ŝanĝiĝas laŭ informo provizita de la servilo:
- "feature flags";
- fora konfiguro;
- A/B-eksperimentoj;
- laŭgradaj aktivigoj;
- parametroj asociitaj al la konto.
Figura 8
Kompreneble, fora konfiguro povas aktivigi nur funkcion kiun la programo jam kapablas plenumi.
Kaj ni ne havas evidentecon ke WhatsApp enhavas mekanismon destinitan sekrete elflui konversaciojn.
Ne tion mi asertas.
La punkto estas alia:
Reviziái la E2EE-protokolon ne diras al ni aŭtomate ĉion kion la kliento povas fari.
Ankaŭ ne necesus ŝteli la ŝlosilon de la datumbazo
Foje ni imagas ege komplikan atakon:
- ŝteli la lokan datumbazon;
- ĉerpi el ĝi la ŝlosilon;
- sendi ĝin al la servilo;
- malĉifri tie la konversaciojn.
Sed hipoteza malica versio de la kliento verŝajne havus multe pli simplan eblon.
La legitima aplikaĵo jam bezonas legi siajn proprajn datumojn.
Se WhatsApp povas montri al vi konversacion de antaŭ ses monatoj, iu parto de la kliento havas atingon al tiu informo en uzebla formo.
Tial:
Figura 9
La ĉifrado "en ripozo" estas tre utila kontraŭ aliaj programoj, kontraŭ certaj fizikaj atingoj aŭ kontraŭ la rekta kopiado de la dosieroj.
Sed ĝi ne protektas la datumojn kontraŭ la programo mem kiu legitime bezonas malĉifri ilin.
Kaj, en la kazo de WhatsApp, la ŝlosilo de la normala sekurkopio eĉ ne apartenas nur al la telefono: kiel mi rakontas en la unua artikolo, WhatsApp konservas ĝin en siaj serviloj kaj transdonas ĝin al iu ajn telefono kiu kontrolas la numeron. Al la aplikaĵo, jes. Al la uzanto, ne.
Kaj eĉ ne necesus sendi ĉion
Hipoteza celita atako ankaŭ ne bezonus transdoni 30 GB da fotoj, filmetoj kaj sonregistraĵoj.
Teksto estas tre malmultekosta.
Oni povus elekti, abstrakte:
- la lastajn mesaĝojn;
- unu konkretan konversacion;
- nur tekston;
- mesaĝojn de post certa dato;
- datumojn de certa kunparolanto;
- certajn metadatumojn.
Tio gravas ĉar hipoteza bone limigita atako kontraŭ la finpunkto povus generi tre malmultan trafikon kompare kun la ordinara trafiko de mesaĝ-aplikaĵo.
WhatsApp Web multiplikas la finojn
La situacio estas eĉ pli interesa de kiam WhatsApp disponas pri reala multaparata arkitekturo.
WhatsApp Web ne plu estas simple ekrano kiu permanente dependas de la ĉefa telefono.
En la multaparata arkitekturo, ĉiu ligita aparato havas sian propran identecan ŝlosilon kaj tenas sendependajn E2EE-sesiojn. Kiam aparato estas ligata, la ĉefa telefono sendas al ĝi ĉifrita parton de la lastatempa historio, kaj poste la aparato tenas sian propran lokan datumbazon.
Tial:
Figura 10
Tio estas tre komforta.
Sed el la vidpunkto de la minacmodelo ĝi signifas ke ni ne plu havas nepre unu solan finpunkton.
Ni havas plurajn aparatojn kun:
- propraj ŝlosiloj aŭ kriptografia stato;
- lokaj datumoj;
- akreditiloj;
- kapablo ricevi kaj malĉifri mesaĝojn.
Tial WhatsApp permesas konsulti la ligitajn aparatojn kaj forigi sesiojn.
La ĝenerala leciono estas:
E2EE tre reduktas la fidon necesan al la servilo, sed ĉiu rajtigita aparato fariĝas nova loko kie la enhavo ekzistas klara.
"Sed WhatsApp diras ke ĝi ne povas doni la mesaĝojn eĉ al la polico"
Kaj efektive WhatsApp publike prezentas tiun pozicion.
Sed ĝi havas pordon rezervitan al la aŭtoritatoj. Laŭvorte: la Law Enforcement Online Request System de WhatsApp estas portalo kie povas eniri nur agentoj de la ordoprotektaj fortoj por peti datumojn en la kadro de oficiala enketo aŭ de urĝo. Meta havas alian ekvivalentan por Facebook kaj Instagram.
Ĝi havas sian humuron: ekzistas ekskluziva giĉeto por peti informon al firmao kiu diras ke ĝi ne havas la informon. Ĝi ne estas kontraŭdiro, ĉar tio kion ĝi transdonas estas kontodatumoj kaj metadatumoj, ne la konversacioj. Sed ĝi bone ilustras ke «ni ne havas viajn mesaĝojn» ne signifas «ni havas nenion».
La funkciadon ili mem klarigas:
- La paĝo de WhatsApp por la ordoprotektaj fortoj: ene de oficiala krima enketo, WhatsApp konservas la datumojn de konto dum 90 tagoj dum alvenas la formala juĝa postulo.
- La gvidlinioj de Meta distingas tri specojn de peto: konservada (90 tagoj), urĝa (tuja danĝero por minoro aŭ risko de morto aŭ de gravaj vundoj, per la sama portalo) kaj registra, kiuj postulas la respondan juran proceduron.
Kaj la volumeno ne estas anekdota. En novembro de 2024, en la kazo Shabana v. Govt of NCT of Delhi, la Supera Kortumo de Delhio kolektis tion kion Meta mem klarigis al ĝi. Ĝia petosistemo (LEORS) ricevis pli ol cent mil petojn de datumoj en unu jaro (2023), kaj la urĝajn ĝi respondas en demando de minutoj: 18 aŭ 30, en kazoj de malaperintaj minoroj. WhatsApp ankaŭ ricevas «substancan nombron» de ordinaraj kaj urĝaj petoj. Ĝi eĉ transdonis informon pri terorista aktiveco 12 minutojn post ricevi la peton. Tio kion ili transdonas, laŭ la kortumo, estas la baza informo de la abonanto: nomo, retpoŝto, telefono kaj dato de registriĝo.
En Eŭropo, la raporto SIRIUS de 2024 de Eurojust kaj Europol kalkulas WhatsApp, krom Meta, inter la provizantoj kiuj havas propran portalon por la policaj petoj.
Tio havas nenion eksterordinaran: la grandaj teknologiaj firmaoj kutime disponas pri proceduroj por respondi al juraj postuloj.
Laŭ la publika modelo de WhatsApp, tio kion ili povas provizi dependas de la datumoj kiujn ili efektive posedas.
La interesa demando por ĉi tiu artikolo estas alia.
Ni povas distingi:
A) "WhatsApp asertas ke ĝiaj serviloj ne povas
malĉifri la E2EE-konversaciojn."
B) "Ni povas sendepende kontroli ke neniu kliento
regata de WhatsApp povus akiri la plaintext."A ne implicas aŭtomate B.
Ĉu ni devas kredi tion?
Jen estas grave ne konfuzi skeptikon kun akuzo.
Mi ne havas evidentecon ke WhatsApp distribuas specialajn versiojn destinitajn permesi ke sekreta servo legu konversaciojn.
Tial, estus malresponse aserti ke ĝi faras tion.
Sed ankaŭ ne estas racie transformi:
"Ni ne havas pruvojn ke ĝi faras tion"
en:
"Estas teknike pruvite ke ĝi ne povus fari tion."
Estas tri malsamaj epistemologiaj gradoj:
Figura 11
Bona sekureca arkitekturo provas antaŭeniri kiel eble plej multe de la fido al la kontrolebla garantio.
Ne ĉar iu ajn firmao estas nepre malica.
Sed ĉar sekura sistemo provas minimumigi la aferojn kiujn ni devas kredi per pura fido.
Jen aperas la diferenco inter "sekura" kaj "kontrolebla"
WhatsApp povas esti eksterordinare sekura kontraŭ multaj kontraŭuloj.
Ekzemple:
- iu kiu subaŭskultas Wi-Fi-reton;
- telekomunika operatoro;
- atakanto kiu kaptas trafikon;
- certa enrompo en servila infrastrukturo;
- certaj internaj administrantoj.
La problemo de ĉi tiu artikolo estas multe pli specifa:
Kiun garantion ni havas kontraŭ la provizanto mem kiu kontrolas nian finpunkton?
Kaj jen la situacio estas malsama.
Ni povas resumi ĝin:
| Eco | E2EE | Reviziebla kaj kontrolebla kliento |
|---|---|---|
| Protektas la trafikon kontraŭ interkapto | Jes | Ne estas ĝia ĉefa funkcio |
| Evitas ke la servilo rekte malĉifru | Jes | Ne estas ĝia ĉefa funkcio |
| Montras kion faras la kliento kun la plaintext | Ne | Povas fari tion |
| Permesas kontroli la rulatan kodon | Ne nepre | Jes, per reprodukteblaj kompiloj |
| Permesas persone kompili la finpunkton | Ne nepre | Jes |
| Reduktas la fidon necesan al la provizanto | Parte | Multe pli |
Signal: publika kodo kaj reprodukteblaj kompiloj
Signal ofertas bonan ekzemplon de pli kontrolebla modelo.
La Android-kliento havas publikan kodon kaj subtenas reprodukteblajn kompilojn.
La oficialaj instrukcioj klarigas kiel:
- akiri precize la kodon respondan al versio;
- reprodukti la kompilan medion;
- kompili ĝin;
- ĉerpi la APK-ojn instalitajn en la aparato;
- kompari ilin.
La deklarita celo estas ĝuste kontroli ke la versio elŝutita de Google Play respondas al la publikigita fontkodo.
Tio estas grandega diferenco.
Ne necesas ke ĉiu uzanto de Signal estu programisto.
La fakto ke iu ajn sendependa esploristo povas kontroli tion jam faras multe pli malfacila masive distribui binaron kiu ne respondas al la publikaj fontoj.
Nu, eĉ tio havas gravan limon.
Se via minacmodelo inkluzivas eksterordinare selektan atakon nur kontraŭ vi, la plej forta estus kontroli vian propran instalitan APK.
La skalo estus:
Figura 12
Ĉiu paŝo forigas parton de la blinda fido.
Delta Chat: ankoraŭ alia maniero apartigi fidon
Delta Chat estas libera programaro.
En Android estas krome interesa kazo kiam oni instalas ĝin el F-Droid: la F-Droid-fiŝo indikas ke ĉiu versio estas kompilita kaj subskribita de F-Droid mem kaj ke estas garantiite ke ĝi respondas al la publikigita fontpako.
Tio enkondukas apartigon:
Figura 13
Ĝi ne forigas ĉian fidon.
Vi devas fidi ankaŭ F-Droid, ĝian infrastrukturon, Android, ktp.
Sed ĝi evitas almenaŭ la plej simplan modelon de:
"La sama firmao skribas la kodon, kompilas opakan binaron kaj transdonas al mi precize tion kion ĝi volas."
Telegram: aparte interesa komparo
Telegram bezonas gravan distingon.
Ĝiaj nubaj babiloj ne estas E2EE. Laŭ la oftaj demandoj de Telegram, ili uzas kliento-servilan ĉifradon kaj estas konservataj ĉifritaj en la nubo de Telegram por ke ili estu disponeblaj en ĉiuj aparatoj.
La sekretaj babiloj, male, ja uzas fin-al-finan ĉifradon.
Tial, Telegram ne estas "pli privata" ol WhatsApp defaŭlte.
Sed ĝi estas interesa por la demando kiu okupas nin ĉar ĝiaj klientoj havas publikan kodon kaj Telegram publikigas instrukciojn por kontroli ke la versioj de App Store kaj de Google Play respondas al la publikigita kodo.
Krome, TDLib permesas konstrui proprajn klientojn, kaj ĝi ankaŭ subtenas la sekretajn babilojn.
Tio ebligas modelon kiel:
Figura 14
Telegram povus ŝanĝi la protokolon.
Ĝi povus fine rifuzi vian klienton.
Ĝi povus ĉesi servi vin.
Sed se vi kontrolas la ruleblan dosieron kiun vi rulas, la servilo ne povas simple reskribi ĝin fore por ke ĝi faru ion alian.
Tio estas grava diferenco.
La E2EE estas ankaŭ tre konvena por WhatsApp
Estas alia aspekto kiu maloften estas komentata.
La kutima rakonto prezentas E2EE kvazaŭ ĝi estus koncesio kiun la firmao faras ekskluzive por la profito de la uzanto.
Sed arkitekturo en kiu la provizanto normale ne konservas legeblan kopion de ĉiuj konversacioj estas ankaŭ eksterordinare profitdona por la provizanto.
Kiel ni vidis, WhatsApp diras ke la transdonitaj mesaĝoj estas forigataj de ĝiaj serviloj kaj ke la pendantaj estas konservataj provizore en ĉifrita formo.
Tio havas tre favorajn komercajn konsekvencojn:
Figura 15
Tio ne pruvas ke WhatsApp adoptis E2EE pro tiuj motivoj.
Ni ne povas atribui al ĝi tiun intencon.
Sed la objektivaj avantaĝoj ekzistas.
"Tiun informon ni ne havas" estas tre komforta pozicio
Imagu ke eldonejo malkovras ke certaj uzantoj sendas al si piratitajn librojn per WhatsApp.
Aŭ ke aŭtoritato volas koni la enhavon de malnova konversacio.
Se WhatsApp vere ne konservas tiun enhavon kaj la normala arkitekturo malhelpas al la servilo malĉifri ĝin, ĝi povas respondi:
"Tiun informon ni ne havas."
Tio estas bona novaĵo por la privateco.
Sed ĝi estas ankaŭ tre konvena situacio por la provizanto.
Ĝi ne bezonas:
- sisteme decidi kio estas leĝa ene de ĉiu privata konversacio;
- teni sistemojn kiuj inspektas ĉiujn dosierojn;
- konservi dum jaroj la enhavon;
- respondi al ĉiu peto transdonante datumojn kiujn ĝi ne plu posedas;
- gardi eksterordinare kompromitan centran datumbazon.
Mi ne uzus ĉi tie la vorton "neigeblo", ĉar ĝi havas specifajn teknikajn signifojn en kriptografio kaj povus konfuzi.
Mi parolus prefere pri ne-gardado de la enhavo.
La sama karakterizo kiu diras:
"WhatsApp ne povas vidi ĝin"
diras ankaŭ:
"WhatsApp ne devas gardi ĝin."
Kaj, kiel mi mem sperte konstatis, ĝi ankaŭ permesas diri: «no podemos ayudarte a restaurar tus chats».
Sed WhatsApp ne estas blinda
Ni ankaŭ ne devus iri al la alia ekstremo.
Ke la enhavo de konversacio estas E2EE ne signifas ke WhatsApp ne disponas pri informo rilata al la uzo de la servo.
Ĝia privateca politiko priskribas, inter aliaj aferoj:
- informon de la konto;
- informon de la aparato kaj de la konekto;
- protokolojn kaj diagnozon;
- informon necesan por funkciigi la servon.
Ĝi diras ankaŭ ke ĝi konservas informon rilatan al la transdono, kiel la numeron, la daton kaj la horon de mesaĝo aŭ la daŭron de telefonvoko, dum necesas por transdoni la komunikadon, funkciigi la servon aŭ plenumi jurajn devojn.
Tial:
Figura 16
"E2EE" ne signifas "WhatsApp scias nenion pri mi".
Ĝi signifas specifan econ pri la enhavo.
La provizanto povas transdoni la datumojn kiujn ĝi efektive posedas. Tio kion ĝi ne devus povi transdoni, laŭ la publikigita arkitekturo, estas la plaintext de E2EE-konversacio kiun ĝi ne konservas.
La demando de ĉi tiu artikolo restas, tamen:
Ĉu tiu nekapablo estas eco kiun ni povas sendepende kontroli en la finpunkto, aŭ eco kiu dependas ankaŭ de fidi la klienton kiun WhatsApp provizas al ni?
Kaj tie ni revenas al la komenco.
Ne estas same "ili ne faras tion" kaj "ili ne povas fari tion"
Ĉi tio estas verŝajne la plej grava distingo de la tuta artikolo.
Ni povas havi tri situaciojn:
1. La provizanto diras ke ĝi ne faras tion
Ĝi estas aserto.
2. Ni ne havas evidentecon ke ĝi faras tion
Ĝi estas observo pri tio kion ni scias.
3. La sistemo estas konstruita tiel ke ni mem povas kontroli ke ĝi ne povas fari tion silente
Tio estas multe pli forta teknika garantio.
Figura 17
La libera programaro ne estas magie sekura.
Propra kompilo ankaŭ ne estas magie sekura.
Sed ĉiu tavolo de kontrolebleco reduktas la nombron de asertoj kiujn ni devas akcepti senkondiĉe.
Eĉ ne persone kompili ĝin forigas ĉian fidon
Ni povus daŭrigi malsupren senfine.
Se mi mem kompilas la aplikaĵon, mi plu fidas:
- la fontojn;
- la kompililon;
- la dependecojn;
- la operaciumon;
- la kernon;
- la mikroprogramaron;
- la aparataron.
Figura 18
Nula fido ne ekzistas.
La utila demando estas:
Kiom da fido mi povas anstataŭigi per kontrolo?
Kaj en tiu senco ne ĉiuj sistemoj estas ekvivalentaj.
Do ĉu WhatsApp estas malsekura?
Ĉi tiu demando estas malbone formulita.
Necesas demandi:
Malsekura kontraŭ kiu?
WhatsApp kun E2EE povas esti tre sekura kontraŭ persono kiu kaptas la trafikon de la reto.
Ĝi povas esti tre sekura kontraŭ kurioza telekomunika operatoro.
Ĝi povas eksterordinare bone protekti kontraŭ certa enrompo en servilon.
Sed se via minacmodelo inkluzivas:
"Mi ne volas devi fidi la provizanton mem de la servo"
tiam la kontrolo de la kliento fariĝas fundamenta.
Kaj la E2EE, per si sola, ne plu sufiĉas.
Kaj kial mi plu uzas Telegram por malmulte sentemaj aferoj?
Ĝuste ĉar la sekureco ne ekzistas en vakuo.
Ĝi dependas de tio kion vi provas protekti.
Telegram permesas al mi:
- havi la tutan historion sinkronigita;
- uzi multajn aparatojn facile;
- tuj reakiri la konversaciojn;
- konservi grandegan kvanton da datumoj en la nubo;
- atingi ilin sendepende de la konkreta aparato.
La nubaj babiloj de Telegram ne estas E2EE, kaj Telegram klarigas tion malkaŝe: ĝi konservas ilin en sia nubo por ke ili estu atingeblaj el iu ajn aparato.
Sed por paroli pri:
- gramatiko;
- esperanto;
- klasoj;
- hobio;
- kunveno;
- ordinara socia aktiveco;
mi povas perfekte konkludi ke tiuj ecoj estas pli valoraj por mi ol forigi riskon kiun, por tiu konkreta informo, mi konsideras malmulte grava.
Tio ne signifas ke Telegram estas pli sekura.
Ĝi signifas apliki proporcian minacmodelon.
Por tre sentema konversacio, mi elektus malsamajn garantiojn.
Por diskuti ĉu la akuzativo en esperanto konvenas aŭ ne post certa konstruo, verŝajne ne.
Kion devus postuli sistemo kun tre fortaj garantioj?
Se ni vere volus redukti maksimume la fidon al la provizanto, ni serĉus almenaŭ:
- publikan kaj revizieblan kriptografian protokolon;
- kompletan publikan kodon de la kliento;
- reprodukteblajn kompilojn;
- eblon kompari nian binaron kun la fontoj;
- eblon mem kompili la klienton;
- kapablon regi kiam ni ĝisdatigas;
- eblon uzi alternativajn realigojn;
- travideblecajn mekanismojn kontraŭ selektaj traktadoj;
- minimumigon de metadatumoj;
- operaciumon kaj kompilan ĉenon ankaŭ racie kontroleblajn.
Ne ĉiuj popularaj sistemoj plenumas ĉion tion.
Sed estas kvalita diferenco inter:
"La fabrikanto certigas al mi ke ĝi ne povas fari tion."
kaj:
"La konstruo de la sistemo permesas al mi sendepende kontroli ke ĝi ne povas fari tion en la maniero kiun ni konsideras."
La korekta demando: al kiu apartenas la finoj?
Kiam aperas la konata pendseruro de WhatsApp, la kutima demando estas:
"Ĉu la konversacio estas ĉifrita?"
Jes.
Ĝi estas grava demando.
Sed ni devus tuj fari alian:
"Al kiu apartenas la finoj?"
Ĉar la korekta prezento ne estas:
mi <============= E2EE =============> vised:
Figura 19
La E2EE protektas bonege la vojon inter B kaj C.
Sed ĝi ne atestas B nek C.
Kaj se B kaj C estas programoj kiujn la sama provizanto povas disvolvi, distribui kaj modifi, la fido al tiu provizanto ne malaperis.
Ĝi simple translokiĝis.
Konkludo
La fin-al-fina ĉifrado de WhatsApp ne estas falsa nek senutila.
Male: ĝi estas gravega sekureca rimedo.
La problemo estas transformi konkretan econ:
"niaj serviloj ne bezonas povi malĉifri la mesaĝojn"
en absolutan aserton:
"ni neniam povus akiri la mesaĝojn".
Tio postulus fidi ankaŭ la konduton de la finpunktoj.
Kaj la finpunktoj estas programaro.
Programaro kiun iu skribas.
Programaro kiun iu kompilas.
Programaro kiun iu distribuas.
Programaro kiun iu ĝisdatigas.
Programaro kiu, fine, havas la plaintext antaŭ si.
Tial, antaŭ iu ajn aplikaĵo kiu fanfaronas pri E2EE, mi ne plu kontentiĝus per demandi:
"Ĉu ĝi estas fin-al-fine ĉifrita?"
Mi demandus ankaŭ:
"Ĉu mi povas legi la kodon de la finoj?"
"Ĉu mi povas pruvi ke la instalita binaro respondas al tiu kodo?"
"Ĉu mi povas mem kompili ĝin?"
"Ĉu mi povas decidi kiam mi ŝanĝas version?"
"Ĉu mi povas plu uzi tiun version sen ke la provizanto devigu min anstataŭigi ĝin?"
"Ĉu la servilo povas selekte modifi la konduton de mia finpunkto?"
Kaj precipe:
"Ĉu la fino estas vere mia, aŭ ĝi plu estas sub la kontrolo de la provizanto?"
La pendseruro de la E2EE diras al ni ke la vojo inter la finoj estas protektita.
Ĝi ne diras al ni, per si sola, al kiu ni devas fidi kiam ni alvenas al la finoj.