Šifrované hovory ZRTP a Odorik
Napsal: pát 03. srp 2012 16:30:14
Dobrý den.
Rád bych zde popsal možnosti a úskalí šifrování hovorů, tak jak se mi je podařilo nastudovat z různých zdrojů (Google) a RFC, dostupných na internetu
a dále bych zde chtěl ukázat způsob, jak kdokoliv z uživatelů Odoriku může realizovat šifrovaný hovor mezi svými linkami.
Tímto článkem bych chtěl odstartovat veřejnou diskuzi na toto téma a předem upozorňuji, že se nepovažuji za odborníka na tuto problematiku a také bych
tímto chtěl poskytnout návod na to, jak nastavit svého klienta pro šifrování hovorů.
Protokol ZRTP, co se šifruje, co se nešifruje - teorie kolem
Pokud Vás nezajímá teorie kolem a chcete rovnou instantní řešení pro svoje šifrované volání s Odorikem, pak tento odstavec přeskočte.
Protokol ZRTP je určen k šifrování pouze RTP paketů, tj. audio, případně video, které se přenáší mezi dvěma koncovými body. Tímto protokolem se
nešifruje řídící provoz, tj. SIP pakety, takže lze zjistit například kdo koho volá. SIP protokol se však nepoužívá k ustanovení šifrovaného RTP spojení.
Protokol ZRTP také nabízí mechanizmy k detekci a ochraně před útokem Man In the Middle, tedy, kdy mezi bodem A a B se objeví aktivní útočník, např. nějaká
PBX jako Asterisk, Freeswitch, nebo něco podobného. Na začátku přímého spojení mezi dvěma útočníky dochází k výměně veřejných klíčů pomocí algoritmu
Diffie-Hellman. Oba účastnící si díky tomuto algoritmu vypočtou i své vnitřní klíče, které se na přenosové cestě nikdy neobjeví. Veřejné a vnitřní klíče tedy vždy vznikají na začátku hovoru a zanikají s ukončením hovoru. Z tohoto důvodu tedy musí útočník pro každý hovor, chce-li jej dekriptovat a má-li jej například wiresharkem zachycený, spoustu práce s tím, prolomit vnitřní klíče. Tento fakt je výhodou oproti prostému šifrování SRTP, kdy klíče, certifikáty a věci kolem
jsou předem dány a nemění se.
Jak již jsem zmínil, protokol ZRTP nabízí způsob, jak zjistit aktivního útočníka Man In the Middle a to tak, že na začátku
spojení si oba účastnící hovoru vymění tzv. Short Authentication String (v suché teorii uváděno zkráceně SAS). Tento řetězec je dle RFC určen k tomu, aby
jej VoIP klienti uživateli zobrazili, přičemž po zahájení spojení oba účastníci (lidé) si tento řetězec přečtou a navzájem si jej zdělí. Pokud SAS účastníků neodpovídá, je pravděpodobné, že konverzaci odposlouchává aktivní útočník. Je-li řetězec stejný, pak je vše v pořádku. V okamžiku kdy proběhla výměna veřejných klíčů, pomocí algoritmu Diffie-Hellman, je zahájeno šifrování RTP paketů a to s pomocí symetrické blokové šifry - AES 128 bit, případně až AES 256 bit. AES 128bit používá například můj linuxový klient Twinkle. Dle toho, co jsem dále vypátral, je třeba k prolomení šifry AES 128 bit v nejlepším případě 2^126 operací, což je hodnota, která vzhledem k aktuálnímu vývoji hardware znamená nemožné. V dohledné době je tak stále jedinou nadějí nasazení kvantových počítačů, což je stále teorie budoucnosti. Nemluvě o úsilí, které by bylo třeba k prolomení šifry AES 256 bit. Případný pasivní sniffer, který například s wiresharkem zachytí celé vaše spojení, tak má pramalé šance, že kdy hovor dešifruje. Přitom samotný fakt, že zachytil veřejné klíče mu mnoho nepomůže.
RFC je možné implementaci ZRTP doplnit také o tzv "Preshared mode", kdy se veřejné klíče mezi klienty přenesou při úplně prvním spojení a dále platí, že vnitřní klíče klientů se nemažou, ale částečně se cachují a slouží k výpočtu šifry pro 2. až n-tý hovor. Význam "preshared mode" je dle RFC ale spíše v tom, ušetřit výpočetně slabším CPU od výpočtů spojených s Diffie-Hellman při každém začátku hovoru a jak jsem zjistil, mnoho klientů jej nepodporuje.
Co potřebuji, abych mohl volat mezi Odorik linkami šifrovaně ?
* 1) Potřebujete VoIP klienty s podporou protokolu ZRTP, který začíná být poměrně rozšířený.
Pro android například csipsimple, pro Linux twinkle, pro windows - prosím uživatele o doplnění (jako Linuxák nemám zkušenosti)*
* 2) Pokud jde o nějaké zvláštní nastavení Vašich voip klientů - žádné není, pouze se ujistěte, že máte zapnutý ZRTP
(v twinkle kliknete na Upravit/Uživatelký profil/zabezpečení/Aktivovat ZRTP/SRTP šifrování)
* 3) Při volání mezi linkami odoriku je pak třeba linku druhého účastníka vytočit ne s jednou hvězdičkou, ale s hvězdičkami dvěma, například **123456.
Pokud hovor vytočíte pouze s jedinou hvězdičkou, hovor šifrován nebude.
Závěr
Tento článek je shrnutím mých poznatků, které jsem načerpal v souvislosti s problematikou šifrování hovorů, popisuje fakta tak jak jsou.
Pokud jsem se v některé části zmýlil, prosím zkušenější uživatele o nápravu, kterou vřele přivítám. Pro uživatele, kteří chtějí Odorik použít
pro šifrované hovory s minimální šancí na odhalení je tento článek spíše návodem.
Zdroje:
http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-22
http://zmsoft.cz/sifruj/difhell.html
http://cs.wikipedia.org/wiki/Advanced_E ... n_Standard
http://cs.wikipedia.org/wiki/D%C3%A9lka_kl%C3%AD%C4%8De
http://en.wikipedia.org/wiki/ZRTP
J. Marák
Rád bych zde popsal možnosti a úskalí šifrování hovorů, tak jak se mi je podařilo nastudovat z různých zdrojů (Google) a RFC, dostupných na internetu
a dále bych zde chtěl ukázat způsob, jak kdokoliv z uživatelů Odoriku může realizovat šifrovaný hovor mezi svými linkami.
Tímto článkem bych chtěl odstartovat veřejnou diskuzi na toto téma a předem upozorňuji, že se nepovažuji za odborníka na tuto problematiku a také bych
tímto chtěl poskytnout návod na to, jak nastavit svého klienta pro šifrování hovorů.
Protokol ZRTP, co se šifruje, co se nešifruje - teorie kolem
Pokud Vás nezajímá teorie kolem a chcete rovnou instantní řešení pro svoje šifrované volání s Odorikem, pak tento odstavec přeskočte.
Protokol ZRTP je určen k šifrování pouze RTP paketů, tj. audio, případně video, které se přenáší mezi dvěma koncovými body. Tímto protokolem se
nešifruje řídící provoz, tj. SIP pakety, takže lze zjistit například kdo koho volá. SIP protokol se však nepoužívá k ustanovení šifrovaného RTP spojení.
Protokol ZRTP také nabízí mechanizmy k detekci a ochraně před útokem Man In the Middle, tedy, kdy mezi bodem A a B se objeví aktivní útočník, např. nějaká
PBX jako Asterisk, Freeswitch, nebo něco podobného. Na začátku přímého spojení mezi dvěma útočníky dochází k výměně veřejných klíčů pomocí algoritmu
Diffie-Hellman. Oba účastnící si díky tomuto algoritmu vypočtou i své vnitřní klíče, které se na přenosové cestě nikdy neobjeví. Veřejné a vnitřní klíče tedy vždy vznikají na začátku hovoru a zanikají s ukončením hovoru. Z tohoto důvodu tedy musí útočník pro každý hovor, chce-li jej dekriptovat a má-li jej například wiresharkem zachycený, spoustu práce s tím, prolomit vnitřní klíče. Tento fakt je výhodou oproti prostému šifrování SRTP, kdy klíče, certifikáty a věci kolem
jsou předem dány a nemění se.
Jak již jsem zmínil, protokol ZRTP nabízí způsob, jak zjistit aktivního útočníka Man In the Middle a to tak, že na začátku
spojení si oba účastnící hovoru vymění tzv. Short Authentication String (v suché teorii uváděno zkráceně SAS). Tento řetězec je dle RFC určen k tomu, aby
jej VoIP klienti uživateli zobrazili, přičemž po zahájení spojení oba účastníci (lidé) si tento řetězec přečtou a navzájem si jej zdělí. Pokud SAS účastníků neodpovídá, je pravděpodobné, že konverzaci odposlouchává aktivní útočník. Je-li řetězec stejný, pak je vše v pořádku. V okamžiku kdy proběhla výměna veřejných klíčů, pomocí algoritmu Diffie-Hellman, je zahájeno šifrování RTP paketů a to s pomocí symetrické blokové šifry - AES 128 bit, případně až AES 256 bit. AES 128bit používá například můj linuxový klient Twinkle. Dle toho, co jsem dále vypátral, je třeba k prolomení šifry AES 128 bit v nejlepším případě 2^126 operací, což je hodnota, která vzhledem k aktuálnímu vývoji hardware znamená nemožné. V dohledné době je tak stále jedinou nadějí nasazení kvantových počítačů, což je stále teorie budoucnosti. Nemluvě o úsilí, které by bylo třeba k prolomení šifry AES 256 bit. Případný pasivní sniffer, který například s wiresharkem zachytí celé vaše spojení, tak má pramalé šance, že kdy hovor dešifruje. Přitom samotný fakt, že zachytil veřejné klíče mu mnoho nepomůže.
RFC je možné implementaci ZRTP doplnit také o tzv "Preshared mode", kdy se veřejné klíče mezi klienty přenesou při úplně prvním spojení a dále platí, že vnitřní klíče klientů se nemažou, ale částečně se cachují a slouží k výpočtu šifry pro 2. až n-tý hovor. Význam "preshared mode" je dle RFC ale spíše v tom, ušetřit výpočetně slabším CPU od výpočtů spojených s Diffie-Hellman při každém začátku hovoru a jak jsem zjistil, mnoho klientů jej nepodporuje.
Co potřebuji, abych mohl volat mezi Odorik linkami šifrovaně ?
* 1) Potřebujete VoIP klienty s podporou protokolu ZRTP, který začíná být poměrně rozšířený.
Pro android například csipsimple, pro Linux twinkle, pro windows - prosím uživatele o doplnění (jako Linuxák nemám zkušenosti)*
* 2) Pokud jde o nějaké zvláštní nastavení Vašich voip klientů - žádné není, pouze se ujistěte, že máte zapnutý ZRTP
(v twinkle kliknete na Upravit/Uživatelký profil/zabezpečení/Aktivovat ZRTP/SRTP šifrování)
* 3) Při volání mezi linkami odoriku je pak třeba linku druhého účastníka vytočit ne s jednou hvězdičkou, ale s hvězdičkami dvěma, například **123456.
Pokud hovor vytočíte pouze s jedinou hvězdičkou, hovor šifrován nebude.
Závěr
Tento článek je shrnutím mých poznatků, které jsem načerpal v souvislosti s problematikou šifrování hovorů, popisuje fakta tak jak jsou.
Pokud jsem se v některé části zmýlil, prosím zkušenější uživatele o nápravu, kterou vřele přivítám. Pro uživatele, kteří chtějí Odorik použít
pro šifrované hovory s minimální šancí na odhalení je tento článek spíše návodem.
Zdroje:
http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-22
http://zmsoft.cz/sifruj/difhell.html
http://cs.wikipedia.org/wiki/Advanced_E ... n_Standard
http://cs.wikipedia.org/wiki/D%C3%A9lka_kl%C3%AD%C4%8De
http://en.wikipedia.org/wiki/ZRTP
J. Marák