> Komunikace mezi námi a Turrisem je šifrovaná, k čemuž využíváme hardwarový čip s uloženými klíči. Samozřejmě v tomto světě nic není stoprocentní, ale máme tak velkou míru jistoty, že jsou data autentická a že nejsou podvržena
Zaprvé mě mrzí, že je na každého účastníka projektu pohlíženo jako na potenciálního podvodníka, který chce manipulovat s nějakými statistikami. A i kdyby se takový našel, tak bude mít malou váhu v souhrnných výsledcích.
Data se šifrují proto, aby si je nikdo nepřečetl. A vzhledem k ochranně klíče HW prostředky jde hlavně o to, aby nebylo snadné ověřit (uživatelem), co vlastně Turris odesílá za data. Pro odposlech někde uprostřed stačí běžné SW šifrování, resp. s dostupnými klíči. Pro ověření autenticity se používá _podepisování_ (místo šifrování). Tedy k původním datům se přidá ještě podpis.
CZ-NIC všude prohlašuje, jak v rámci zabezpečení soukromí bojuje naprostou otevřeností. Ale zveřejňování (pro daného účastníka) odesílaných dat odmítlo udělat. Na routery distrubuuje binárky, u kterých nelze ověřit, z jakých zdrojáků pochází apod. Odesílaná data jsou šifrována tak, aby je účastník nemohl dešifrovat (není reálný důvod, proč by nemohl dostat dešifrovací klíč). Prostě ona otevřenost je jen v prohlášeních, ale reálně to vypadá úplně jinak. A odpověď bude zřejmě v tom smyslu, že pokud jim někdo nevěří, tak se nemá projektu účastnit. Nejhorší na tom je, že řada lidí věří v to, že lze opravdu snadno ověřit, co se vlastně odesílá za data a slepě věří, že to ověří někdo jiný. I když ani to by nepomohlo, protože CZ NIC má v podmínkách, že každému může do routeru nainstalovat něco jiného - na míru upraveného pro něj. A ani o tom nemusí účastníka informovat.
Poznámka: Ověřit, co se odesílá, samozřejmě teoreticky lze - před zašifrováním. Ale to je dost komplikované, protože nějaký proces data vytvoří a zašifruje, tedy nestačí něco jako TCPDUMP. Jde tedy spíše o jakousi "obfuskaci". Stejně tak to teoreticky nebrání podvrhování dat, protože s pomocí toho HW modulu lze zašifrovat reálná i podvržená data.
To ale směřujete do opačného extrému. Pak se ukáže, že je tam zkreslení dat a lidé jako vy se budou ptát "no a to vám nebylo od začátku jasné, že se vždycky najde někdo, kdo to zkusí sabotovat?" A budete se pohoršeně ptát, proč se to nešifruje.
A co se podepisování týká tak sice máte v zásadě pravdu, že šifrováním se nepodepisuje, jenže v praxi je to často technicky ta samá operace. Nejdříve to zašifruju veřejným klíčem druhé strany a pak soukromým klíčem mým. Dvakrát ta samá funkce, jen jiný klíč. První zajistí, že to přečte jen druhá strana, druhé zajistí, že každý může ověřit, že jsem to poslal já. Podpis se nepřidává. Proto se to v "laické obci" už moc nerozlišuje.
Uživatel může zjistit, co se odesílá. Jsou k tomu zdrojáky, může si to odchytávat. To je ostatně ten důvod, proč se dá předpokládat, že si někdo "firmware" pozmění a bude si s tím hrát a posílat "nesprávná" data.
Na routery distrubuuje binárky, u kterých nelze ověřit, z jakých zdrojáků pochází apod.
Víte o nějakém řešení, jak prokázat, že binárka vznikla pouze z daných zdrojáků? Obávám se, že tenhle problém není možné nijak vyřešit prostě proto, že zatím nikdo takové řešení neobjevil.
Odesílaná data jsou šifrována tak, aby je účastník nemohl dešifrovat
Ale kdeže. Šifrování dat zajišťuje samostatný proces socat, který propojuje své stdio s TLS soketem. Pokud vás opravdu zajímá, co na vás ucollect bonzuje, sniffnout nešifrovaná data z příslušné stdio komunikace není vůbec žádný problém (například pomocí strace). Porozumět protokolu je možné například studiem zdrojáků klientské i serverové části.
Kupodivu se to jmenuje postup kompilace, a zcela bezne se to zverejnuje. Pokud to kdokoli aplikuje, tak za predpokladu stejneho kompilatoru a stejnych soucasti, musi zakonite dojit k totoznemu vysledku.
A, jak prekvapive, pokud nekomu sejde na bezpecnosti vic nez trochu, tak se zcela bezne overuje, ze binarka odpovida (auditovanemu) zdrojaku.
Tudiz reseni davno objeveno je, a je navic technicky zcela trivialni.
A teď tu o Karkulce, prosím :)
Více třeba zde: https://blogs.kde.org/2013/06/19/really-source-code-software
Jenomže je tady ještě technická stránka věci. A sice, že každý router potřebuje vlastní klíče.Ty musí být někde uloženy. Ideálně tak, aby si nemohl potenciální útočník jendoduše hrát se souborem. A další věc je, že pokud se bavíme o dlouhým klíči a malým zařízení, jsou nároky na šifrování docela velký, měřeno na procenta výkonu procesoru. Crypto hardware může za malý peníz nahradit další jádra a paměti za větší peníz. Tak proč to nepoužít?