TLS: Bezpečnost naostro

Transport Layer Security verze 1.0 je protokol definovaný v RFC 2246. Umožňuje bezpečnou komunikaci po internetu způsobem...


Transport Layer Security verze 1.0 je protokol definovaný v RFC 2246. Umožňuje
bezpečnou komunikaci po internetu způsobem, který zamezuje odposlouchávání
spojení, jeho úpravy, nebo dokonce náhradu jedné ze stran spojení.
Protokol TLS má několik zajímavých vlastností, které jej staví nad rovinu
ostatních šifrovacích protokolů. Předně kombinuje kompresi se šifrováním, dále
má (konečně) transparentní handshake a definuje jasný seznam doporučených šifer.

Šifrování
Šifrování v TLS si můžeme představit jako prostou operaci XOR, aplikovanou na
každý přenášený bit. Operace XOR je binární operace, která převrátí zdrojový
bit, pokud druhý zdrojový bit je 1. Zde je třeba si všimnout důležité
vlastnosti pokud provedeme XOR podruhé, získáme opět původní hodnotu. To
znamená, že operace dešifrování je totožná s operací šifrování. Oběma stranám
spojení tedy stačí mít identický řetězec bitů, se kterým provádí operaci XOR a
po cestě se spojení jeví jako datový šum. Samozřejmě musí takto vytvořený
řetězec mít pořádnou dávku entropie, aby sám "na pohled" vypadal jako šum.
Když si ale představíme jako příklad komunikace zadání jednoho tisíce
bankovních operací, kde jedna operace zabere řekněme jeden kilobajt, tak
potřebujeme tajný řetězec o délce jednoho megabajtu. Bylo by samozřejmě velmi
nepraktické, aby se obě strany musely dohodnout pro každé spojení na novém
megabajtovém řetězci, a proto se používá metoda generování těchto řetězců, kde
se obě strany dohodnou na nějakém počátečním iniciačním vektoru, kterým
inicializují své algoritmy na generování řetězce potřebného k provedení operace
XOR. Samozřejmě se také musí dohodnout na použitém algoritmu.
To, co bylo popsáno v předchozích dvou odstavcích, je systém symetrických
šifer, které jsou použity k vlastnímu přenosu dat. Celý systém má však jedno
úskalí, a tím je výměna iniciačního vektoru mezi oběma stranami. Respektive
výměna dvou iniciačních vektorů jedním šifruje strana A pro stranu B a druhým
naopak. Důvodem je, že žádný z řetězců pro operaci XOR by neměl být použit
predikovatelně vícekrát a použít jej pro oba směry spojení by bylo dvojnásobné
použití. Tak by se mohlo usnadnit použití matematických prostředků na
rozšifrování celého spojení.

Zahájení komunikace
Klíčová část TLS spojení, která zajistí možnost ověření identity obou stran a
výměnu iniciačního vektoru pro symetrické šifrování, se nazývá handshake,
potřesení rukou. Při handshaku se pro přenos citlivých dat používá asymetrická
kryptografie.
Nastiňme si, oč se jedná, na příkladu uzamykatelné truhly se dvěma otvory pro
klíč. Do jednoho otvoru můžeme vložit klíč A a otočit jím doleva a tím truhlu
uzamkneme. Do druhého pak můžeme vložit klíč B a otočit jím doprava, čímž
truhlu odemkneme. Klíčem A tedy můžeme truhlu uzavřít a klíčem B otevřít. Nikdy
však opačně. Jediné co je ještě potřeba pro plně funkční systém, je vztah mezi
klíči A a B. Ten, kdo má schopnost truhlu odemknout, by měl mít i schopnost
truhlu uzamknout, proto z klíče B musí být možné vypočítat klíč A.
Převeďme nyní tento příklad z roviny truhel se zámkem do roviny matematické
klíče jsou čísla, zámky jsou také čísla, proces odemknutí a zamknutí jsou
funkce. Nebudeme zde rozebírat jaké funkce a jaká čísla, jen si řekněme, že
klíč, kterým dešifrujeme asymetrickou šifru, se nazývá privátní, a klíč, kterým
šifrujeme, je klíčem veřejným. Každý má tedy možnost zašifrovat zprávu, ale jen
vlastník privátního klíče ji může dešifrovat.
Při procesu handshake si obě strany vymění své veřejné klíče, obdrženým klíčem
zašifrují požadovaný symetrický klíč a pošlou jej nazpět. Poté si svými
privátními klíči rozšifrují symetrické klíče (iniciační vektory), a spojení
může začít. Ještě je možné v tomto bodě aplikovat ověření identity obou stran.

Implementace
V případě, že se jedná o privátní informace a o bezpečnost obecně, je velmi
jednoduše dokazatelné, že bez zveřejněných zdrojových kódů je jakákoliv
aplikace nedůvěryhodná. Důvod? Uživatel musí mít možnost zkontrolovat, co se
děje s jeho privátním klíčem.
V případě použití softwaru bez možnosti vlastní kompilace a kontroly zdrojových
kódů je možné, že dodavatel softwaru si posílá privátní klíče uživatelů a
vesele je archivuje pro "pozdější použití". To není nijak zvlášť paranoidní
scénář, poslat privátní klíč někam pryč je v dnešní době jedna řádka přidaná do
programu.
Ono teoreticky stačí použít open source implementaci, ale tento druh softwaru
má jednu drobnou nevýhodu licence může zaručovat, že máte přístup ke zdrojovým
kódům, ale může uvalovat restrikce na použití daného softwaru. Preferována by
tedy měla být free software implementace a firmy mající zájem na používání
těchto technologií by měly zvážit případný sponzoring některého projektu typu
OpenSSL či GNUTLS.
Problematikou šifrování, bezpečné komunikace, ale i free softwaru a open source
v praktickém použití se bude zabývat akademická konference OpenWeekend,
konající se ve dnech 15. a 16. března 2003 v prostorách ČVUT v Praze
6-Dejvicích.
Dominik Pantůček je odborníkem na problematiku šifrovaných komunikačních
vrstev.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.