Důvěra při prvním použití (TOFU neboli TUFU, ) je ověřovací schéma používané klientským softwarem, které potřebuje navázat vztah důvěryhodnosti s neznámým nebo dosud nedůvěryhodným koncovým bodem. V modelu TOFU se klient pokusí vyhledat identifikátor koncového bodu, obvykle buď veřejný klíč koncového bodu, nebo otisk uvedeného klíče, ve své lokální databázi důvěryhodnosti. Pokud pro koncový bod dosud neexistuje žádný identifikátor, klientský software buď vyzve uživatele k potvrzení, že ověřil, že údajný identifikátor je autentický, nebo pokud se v protokolu nepředpokládá, že by ruční ověření bylo možné, klient jednoduše důvěřuje zadanému identifikátoru a zaznamená vztah důvěryhodnosti do své databáze důvěryhodnosti. Pokud je v následném připojení od protilehlého koncového bodu přijat jiný identifikátor, klientský software jej bude považovat za nedůvěryhodný.
Implementace TOFU V protokolu SSH většina klientského softwaru (i když ne všechny) po připojení k dosud nedůvěryhodnému serveru zobrazí otisk veřejného klíče serveru a vyzve uživatele k ověření, zda jej skutečně ověřil pomocí ověřeného kanálu. Klient poté zaznamená vztah důvěryhodnosti do své databáze důvěryhodnosti. Nový identifikátor způsobí blokovací varování, které vyžaduje ruční odstranění aktuálně uloženého identifikátoru.
V aplikaci Signal koncové body zpočátku slepě důvěřují identifikátoru a při jeho změně zobrazují neblokující varování. Identifikátor lze ověřit buď naskenováním QR kódu nebo výměnou desetinné reprezentace identifikátoru (nazývané bezpečnostní číslo) přes ověřený kanál. Identifikátor lze poté označit jako ověřený. Tím se změní povaha varování před změnou identifikátoru z neblokujících na blokující.
Např. v Jami a Ricochet je identifikátorem samotná volací značka uživatele. ID lze vyměňovat přes jakýkoli kanál, ale dokud není identifikátor ověřen přes ověřený kanál, je v podstatě slepě důvěryhodný. Změna identifikátoru vyžaduje také změnu účtu, takže MITM útok pro stejný účet vyžaduje přístup k soukromému klíči koncového bodu.
V komunikátoru WhatsApp koncový bod zpočátku slepě důvěřuje identifikátoru a ve výchozím nastavení se při změně identifikátoru nezobrazuje žádné varování. Pokud uživatel prokáže vůli a schopnost ověřit koncové body přístupem k otisku klíče (tzv. bezpečnostnímu kódu), klient ho vyzve k povolení neblokujících varování při změně identifikátoru. Klient WhatsAppu uživateli neumožňuje označit identifikátor jako ověřený.
Ve volitelných tajných chatech komunikátoru Telegram koncové body slepě důvěřují identifikátoru. Změněný identifikátor vyvolá nové okno tajného chatu namísto zobrazení varování. Identifikátory lze ověřit porovnáním vizuální nebo hexadecimální reprezentace identifikátoru. Klient Telegramu neumožňuje uživateli označit identifikátor jako ověřený.
V PKI databázi Keybase si klienti mohou vzájemně podepisovat klíče, což znamená, že důvěryhodnost jednoho identifikátoru umožňuje ověření více identifikátorů. Keybase funguje jako důvěryhodná třetí strana, která ověřuje propojení mezi účtem Keybase a podpisovým řetězcem účtu, který obsahuje historii identifikátorů. Identifikátor použitý v Keybase je buď hash kořene podpisového řetězce uživatele nebo název účtu Keybase, který je s ním svázán. Dokud uživatel neověří pravost kořenového hashe podpisového řetězce (nebo účtu Keybase) přes ověřený kanál, je účet a s ním spojené identifikátory v podstatě slepě důvěryhodné a uživatel je náchylný k útoku MITM.
Zařízení Apple používají model TOFU pro schválení certifikátu při připojování k Wi-Fi sítím pomocí protokolu IEEE 802.11X (např. projekt eduroam). V systému Android je možnost využití TOFU volitelná.
Silné a slabé stránky modelu Největší silnou stránkou jakéhokoli modelu typu TOFU je, že člověk musí nejprve ověřit každou interakci. Běžnou aplikací tohoto modelu je použití uživatelů typu „bot“ ssh-rpc mezi počítači, kdy jsou veřejné klíče distribuovány skupině počítačů pro automatický přístup z centralizovaných hostitelů. Aspekt TOFU této aplikace nutí správce systému (nebo jiného důvěryhodného uživatele) ověřit identitu vzdáleného serveru při prvním připojení.
Pro end-to-end šifrovanou komunikaci umožňuje model TOFU ověřené šifrování bez složitého postupu získávání osobního certifikátu, který je zranitelný vůči kompromitaci CA. Ve srovnání s Web of Trust má TOFU menší režijní náklady na údržbu.
Největší slabinou TOFU, která vyžaduje ruční ověřování, je jeho neschopnost škálovat se pro velké skupiny nebo počítačové sítě. Náklady na údržbu spojené se sledováním identifikátorů pro každý koncový bod se mohou rychle škálovat nad možnosti uživatelů.
V prostředích, kde nelze pravost identifikátoru dostatečně snadno ověřit (například IT personál pracoviště nebo vzdělávacího zařízení může být obtížně dostupný), mají uživatelé tendenci slepě důvěřovat identifikátoru opačného koncového bodu. Náhodně schválené identifikátory útočníků mohou být také obtížně detekovatelné, pokud útok typu „man-in-the-middle“ pokračuje.
Protože nový koncový bod vždy zahrnuje nový identifikátor, nezobrazuje se žádné varování před potenciálním útokem. To vedlo k mylné představě mezi uživateli, že je bezpečné pokračovat bez ověření pravosti původního identifikátoru, bez ohledu na to, zda je identifikátor uživateli předložen, či nikoli.
Únava z varování donutila mnoho aplikací pro zasílání zpráv odstranit blokovací varování, aby se zabránilo návratu uživatelů k méně bezpečným aplikacím, které nepoužívají end-to-end šifrování.
Mechanismy ověřování identifikátorů mimo dohled snižují pravděpodobnost, že uživatelé odhalí a přijmou bezpečné ověřovací postupy.
První známé použití termínu První známé formální použití termínu TOFU nebo TUFU provedli výzkumníci z CMU Dan Wendlandt, David Andersen a Adrian Perrig ve svém výzkumném článku „Perspektivy: Zlepšení ověřování hostitele ve stylu SSH pomocí vícecestného sondování“, publikovaném v roce 2008 na výroční technické konferenci Usenix.
Moxie Marlinspike zmínila Perspectives a termín TOFU v rámci DEF CON 18 s odkazem na komentáře Dana Kaminského během panelové diskuse „Otevřený dopis, výzva k akci“. Z publika byl vznesen návrh naznačující nadřazenost modelu infrastruktury veřejných klíčů (PKI) SSH nad modelem PKI SSL/TLS – na což Moxie odpověděla:
Související práce na toto téma Práce na vytváření vizuálních reprezentací hashů „otisků prstů“ certifikátů serveru byla implementována do OpenSSH ve formě ASCII Art. Záměrem je, aby uživatelé vizuálně rozpoznali „grafický“ obrázek namísto dlouhého řetězce písmen a čísel. Původní výzkumnou práci napsali Adrian Perrig a Dawn Song z katedry informatiky Carnegie Mellon University . Tvůrce zkratky „TUFU“ popisoval inspiraci pro plugin „Perspectives Firefox Plug In“, který byl navržen k posílení modelu SSL/TLS PKI kontaktováním síťových notářů vždy, když se váš prohlížeč připojí k webu HTTPS.
Předchozí práce Témata důvěry, validace a nepopiratelnosti jsou zásadní pro veškerou práci v oblasti kryptografie a digitální bezpečnosti .
Odkazy
Reference
Související články Útok typu „man-in-the-middle“ Koncové šifrování (E2EE)
Externí odkazy „Harmonogram DEF CON 18, otevřený dopis – výzva k akci“ Rozšíření pro Firefox, které kontaktuje notáře v síti vždy, když se váš prohlížeč připojí k webu s protokolem HTTPS. Vizualizace hash v OpenSSH
Kategorie:Údržba:Články s nekontrolovanými překlady Kategorie:Počítačová bezpečnost