Skip to content
Snippets Groups Projects
Commit be931c72 authored by Martin Mareš's avatar Martin Mareš
Browse files

Aukční protokol hotov

parent d72f2687
Branches
No related tags found
No related merge requests found
...@@ -235,14 +235,97 @@ Ekonomové odhadují že peněz v~hotovosti a na snadno dostupných účtech ...@@ -235,14 +235,97 @@ Ekonomové odhadují že peněz v~hotovosti a na snadno dostupných účtech
je cca $8\cdot 10^{12}\;{\rm USD}$. Viz \url{https://www.rankred.com/how-much-money-is-there-in-the-world/}. je cca $8\cdot 10^{12}\;{\rm USD}$. Viz \url{https://www.rankred.com/how-much-money-is-there-in-the-world/}.
} takže stačí na částku rezervovat 13 číslic a na celou zprávu 20 znaků. } takže stačí na částku rezervovat 13 číslic a na celou zprávu 20 znaků.
\subsection{Přehrávací útoky: přidáme nonci} \subsection{Porovnávání zpráv: přidáme nonci}
\subsection{Porovnávání zpráv: nonce podruhé} Překvapivě i po této úpravě z~protokolu prosakují informace: Šifrování je deterministické,
takže pokud Alice pošle podruhé tentýž příkaz, vznikne stejná zašifrovaná zpráva. Útočník přitom
vidí v~televizním přenosu, jak Bob zareagoval na kterou zašifrovanou zprávu, takže si může vytvářet
slovník známých zpráv s~jejich významy.
Pomoc je snadné: Před šifrováním ke zprávě přidáme nějakou nonci, třeba náhodný 64-bitový
řetězec. Pak už bude velmi nepravděpodobně, že by útočník potkal tutéž zašifrovanou zprávu
vícekrát.
\subsection{Přehrávací útoky: hodí se sériová čísla}
Co kdyby útočník zkusil nějaké zprávy vyrábět?
Pokud si nějakou úplně vymyslí, nejspíš po dešifrování nebude dávat smysl. Daleko snazší
je zopakovat nějakou autentickou zprávu a tím přimět Boba, aby zopakoval jeden z~předchozích
příkazů.
Nonce už tomu teoretický brání: Bob si může pamatovat množinu všech noncí, které už potkal,
a~když se nějaká zopakuje, ví, že se jedná o~duplikát zprávy, takže ho bude ignorovat.
Nepraktické je, že na to potřebuje spoustu paměti. Zprávy proto doplníme \em{sériovým číslem} --
počáteční zpráva má sériové číslo~0, každá další pak o~1 větší. Bob si pamatuje, jaké poslední
sériové číslo viděl, a~nová zpráva nemá ostře větší, zahodí ji. (Všimněte si, že nevyžaduje přesně o~1
vyšší, takže ho nezmate vynechaná zpráva.)
\subsection{Modifikace zpráv: podepisujeme} \subsection{Modifikace zpráv: podepisujeme}
Další ošklivost, kterou by nám mohl útočník provádět, je obsah zpráv upravovat.
Může se zdát, že pokud zašifrovanou zprávu jakkoliv změníme, způsobí to po dešifrování
naprosté rozbití zprávy. To překvapivě často není pravda a z~obecných požadavků
na bezpečnost šifer to neplyne. Například pro všechny proudové šifry (TODO) platí, že
překlopíme-li jeden bit v~zašifrovaném textu, změní se bit na stejné pozici v~dešifrované zprávě.
S~tím se dá tropit nejrůznější neplecha. Především můžeme libovolně měnit sériové číslo:
jeho původní hodnotu snadno známe (to je počet zpráv od počátku komunikace), takže víme,
které bity změnit, abychom dostali o~1~vyšší číslo. Tím pádem sériová čísla vůbec nechrání
proti přehrávání zpráv. Nebo můžeme sériové číslo nahradit nějakým hodně velkým (třeba překlopit
jeho nejvyšší bit), takže Bob napříště zahodí všechny autentické zprávy od Alice.
Také můžeme upravovat částky. Pokud uhodneme, kolikamístnou částku Alice poslala (to se dá
podle průběhu dražby tipovat), můžeme následující mezeru změnit na nulu a tím částku vynásobit
deseti. Navíc první číslice bude často jednička\foot{Pravděpodobně se i zde uplatňuje tzv.
\linkurl{https://cs.wikipedia.org/wiki/Benford\%C5\%AFv_z\%C3\%A1kon}{Benfordův zákon}.}
a pokud si to útočník správně tipne, může ji změnit na jakoukoliv jinou číslici.
Konečně můžeme zkusit změnit {\tt PRIHOD} na {\tt KONEC\sp} a tím donutit Boba odejít z~dražby.
Na to bychom ale potřebovali, aby Bob ignoroval přebytečné číslice za příkazem {\tt KONEC}.
Nebo pokud bychom uhodli, že Alice chce skončit, mohli bychom naopak z~konce udělat jakékoliv
přihození.
Všechny tyto problémy jsou důsledkem toho, že šifra nezaručuje nic o~integritě zpráv.
Přidáme proto ke každé zprávě ještě podpis. Jelikož obě strany už sdílí společné tajemství,
můžeme podepisovat symetricky, tedy MACem. Podepisovat budeme až zašifrovanou zprávu.
\subsection{Hotový protokol} \subsection{Hotový protokol}
Pojďme shrnout celý protokol. Zprávy budou vypadat takto:
\tightlist{o}
\:zašifrovaná část:
\tightlist{o}
\:nonce (64 bitů)
\:sekvenční číslo (64 bitů)
\:text příkazu dopadovaný mezerami na 20 znaků
\endlist
\:podpis zašifrované části
\endlist
Alice si bude udržovat počítadlo zpráv a podle něj nastavovat sekvenční číslo.
Nonce bude generovat náhodně.
Bob si bude pamatovat poslední přijaté sekvenční číslo.
Když mu přijde zpráva, nejdříve ověří podpis a pokud nesouhlasí, zprávu zahodí.
Jinak zprávu dešifruje, porovná její sekvenční číslo s~posledním přijatým, a~pokud
nové není větší, zprávu zahodí.
Pokud zpráva prošla i~tímto textem, Bob ji považuje za autentickou a provede příkaz.
\subsection{Překvapení na závěr} \subsection{Překvapení na závěr}
Alice je spokojená -- vydražila svého milovaného Tuxe všem nepřátelům navzdory.
Tak se při příští dražbě pokusí osvědčený protokol použít znovu. Ale ouha, nepřátelům
se najednou daří postrkávat příkazy, které Alice neposílala.
Co je špatně? Inu, sériová čísla sice brání přehrávání zpráv v~rámci jedné instance protokolu,
ale už ne kopírování zpráv z~jedné instance protokolu do druhé.
Náprava je snadná: Do každé zprávy přidáme ještě identifikátor instance protokolu
(třeba datum a čas začátku dražby) a budeme zahazovat všechny zprávy, které nepatří
k~aktuální instanci.
Identifikátory instance dokonce ani nemusíme posílat -- stačí, když je započítáme
do podpisu. Jakmile se pak objeví zpráva z~jiné instance, prostě jí nebude souhlasit
podpis.
\endchapter \endchapter
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment