- Aktualizace 20.1.2016: Ministerstvo financí po měsících žádostí zveřejnilo na svém webu plnou verzi studie Specifikace projektu Elektronická evidence tržeb.
Když Michal Škop ze sdružení KohoVolit.eu v říjnu obdržel od Ministerstva financí dokument nazvaný Specifikace projektu Elektronická evidence tržeb (EET), byl nemile překvapen, že ze 192 stránek studie jich bylo zcela začerněných 139, z velké části začerněných 19, z menší části 10 a vůbec nezačerněných jen 24 stránek. 6 stránek pak bylo prázdných.
Trochu se to dalo čekat, zvláště poté, co se ANO na svém facebookovém profilu v srpnu pokusilo vyvracet lži o EET, mimo jiné o tom, že systém vzniká v utajení. Úplně se jim to nepovedlo, protože potvrdili, že ona lež je vlastně pravda. Dobrá práce.
https://www.facebook.com/anobudelip/posts/863316920405209
Inu, stalo se to, co se stát muselo… Nezačerněná verze té specifikace, pochopitelně neoficiální, se dostala ven na světlo světa a odkaz na ni se objevil například i v příspěvku od již zmíněného Michala Škopa, díky za něj. Tuto neoficiální verzi jsem si stáhl, otevřel, a začetl se. Co bych tak o víkendu mohl taky dělat jiného, na vánoční trhy můžu jít klidně i příští rok.
V prohlížeči se objevila první stránka, která mi prozradila, že dále se budu kochat “Specifikací projektu Elektronická evidence tržeb, verze 1.22 z února 2015”. Nutno dodat, že kromě té skoro celé cenzurované verze a této neoficiální necenzurované existuje ještě jedna, ve které je cenzurováno jen něco a většina je nezačerněná. Zajímavé je, že v ní jsou cenzurované i takové informace, jakože třeba něco není součástí této specifikace.
(strana 78, žluté označení je moje)
Ten začerněný text je delší, než ten původní čitelný, ale po zkopírování a vložení do textového editoru se objeví jen samá xxxxxxxxxxxxxxxxxx, jejich počet je ale jiný, než počet písmenek žlutě označené části. Někdo nejspíš jen označil text, který chtěl odstranit, stiskl klávesu X a držel ji tak dlouho, dokud to nevypadalo přibližně stejně dlouhé.
Rozpočet
Hned ze začátku v dokumentu vás překvapí základní finanční ukazatele.
(strana 12)
A tím překvapením nemyslím ty kontrolní nákupy za 30 milionů ročně. Schválně si zkuste sečíst ta čísla a zaměřte se na sloupečky s nadpisem Oracle. Jestli vám vyšlo 331 a 396, tak jste počítali správně, na rozdíl od lidí z firmy BDO, která tuto studii údajně za 199 900 Kč vyprodukovala.
Zajímám se o (nejen) webovou bezpečnost, což je také vlastně primární důvod, proč jsem tento dokument vůbec studoval, a už nějakou dobu bojuji za to, aby bezpečnost byla součástí projektu, aby to nebyla samostatná položka na faktuře, když najednou bum, ránajakzděla… tady to je zvlášť a stojí to půlku toho, co samotný vývoj.
(strana 119, žluté označení je moje)
V těch tabulkách z předběžného rozpočtu je vůbec sranda číst. Specifikace na jednom místě říká, že je požadováno dodání 4 ks SAN switchů, ale v rozpočtu už chtějí jen 2. Kdyby to psal pan Babica, tak by tam určitě byla poznámka o tom, že pokud nemáte ani ty 2 switche, tak tam dejte obyčejný vypínač.
(strana 113 a 118, žluté označení je moje)
Účtenková loterie
Když jsme u těch peněz, už jste zaslechli, že součástí projektu Elektronická evidence tržeb má být účtenková loterie? Na webu zadáte kód z účtenky a hned zjistíte, že… jste nic nevyhráli a zas musíte ráno jít bouchat kačky. Specifikace obsahuje i návrh, jak to trochu opepřit (nebo spíš vosolit). Falešné účtenky by mohly mít mnohem větší výhru, nebo dokonce samostatné losování. Prostě lidi finančně motivujeme k tomu, aby rizikové provozovny vydávající falešné účtenky práskali pěkně sami, ještě zatepla.
(strana 174 a 175, žluté označení je moje)
Zaevidování účtenky a kontrolní kódy
Možná je na čase si zjednodušeně vysvětlit, jak takové zaevidování účtenky vlastně bude vypadat.
Po zaplacení se pokladna pokusí kontaktovat servery EET a mimo jiné jim pošle dva kontrolní kódy, OKP (Off-line kód povinného subjektu) a BKP (Bezpečnostní kód plátce). Pokladna od systému EET dostane zpátky FIK (fiskální identifikační kód, jakési potvrzení o zaevidování účtenky v systému EET), ten vytiskne na účtenku společně s BKP a je to. Když z jakéhokoliv důvodu nebude fungovat připojení k serverům EET, tak pokladna žádný FIK nedostane, ale místo něj vytiskne na účtenku OKP (specifikace mluví i možné reprezentaci QR kódem) a má 48 hodin na to, aby se účtenku pokusila znovu odeslat. Bude na obchodníkovi, aby nastavil nějaký maximální časový limit, po který bude pokladna čekat na odpověď ze systému EET, ale podle specifikace má EET odpovídat do max. 2 vteřin, průměrná doba odpovědi má být 330 ms. Přijímání účtenek je dimenzováno tak, aby systém EET zvládal ve špičkách zpracovávat 4000 účtenek za sekundu.
OKP (Off-line kód povinného subjektu) jsou vybrané údaje z účtenky, podepsané soukromým klíčem obchodníka. Bezpečnostní kód plátce (BKP) je pak hash off-line kódu (OKP). Ze specifikace není zcela jasné, jaký hash to bude. Na jednom místě specifikace tvrdí, že to bude algoritmem MD5, zatímco o kus dále tvrdí, že použit bude úplně jiný algoritmus SHA-1. Podobně konzistentní je ta specifikace na více místech.
(strana 41 a 77, žluté označení je moje)
Base64
Délka bezpečnostního kódu plátce (BKP) je ovšem poměrně důležitá, zákazníci ten kód budou přepisovat do systému EET, třeba aby se podívali, že zase nic nevyhráli. Takže nesmí být moc dlouhý. Proto prý zápis na účtence nebude v klasickém hexadecimálním tvaru, ale zakóduje se do Base64, pak by ten kód měl být kratší.
(strana 78)
To samo o sobě zní dobře, jenže ten příklad v tabulce s výslednou délkou znaků 43 odpovídá tomu, že do Base64 zakódovali právě tu hexadecimální hodnotu, čímž ten kód vlastně prodloužili.
BKP počítaný pomocí MD5 v hexadecimálním tvaru má 32 znaků, v Base64 bez koncových rovnítek 22 znaků a v hexadecimálním tvaru zakódovaném do Base64 bez koncového rovnítka to má těch zmíněných 43 znaků. Jedeme zkratkou, pánové. Je to sice dál, ale zato horší cesta.
Standardní znaková sada Base64 má sice a-z, ne a-f, ale toho si snad ani nevšímejte.
SHA-1
SHA-1? Určitě jste se lekli, že jo, vždyť dnes už každý malý e-shop přechází na SHA-256 a prohlížeče hlásí chybu, když narazí na SHA-1 certifikát. EET nebude SHA-1 používat pro certifikáty, ale jen pro bezpečnostní kód plátce na účtence. Teda pokud to nebude MD5, že?
(strana 77)
HTTPS certifikáty budou používat SHA-256.
SSL 3
Komunikace mezi pokladnami a systémem EET má údajně probíhat protokolem SSL 3. Ten pochází z roku 1996(!) a dnes už by se neměl vůbec používat, moderní browsery ho už ani nepodporují.
strana 41 a 95, žluté označení je moje
No jo, ale to by specifikace o pár desítek stránek dál nesměla již mluvit o “TSSL/SSL”. Tiše předpokládám, že místo TSSL chtěli napsal TLS, což je protokol, který SSL nahrazuje a měl by se místo něj používat.
Vzhledem k tomu, co jsme viděli dříve, kdy se nejdřív píše o MD5, a najednou se z ničeho nic na scéně objeví SHA-1, tak to “SSLv3” (zvláště ve spojení s “TSSL/SSL”) tady klidně může znamenat i nejnovější TLS verze 1.2. Vzhledem k nekonzistenci celé specifikace bych toto neviděl tak černě, jako třeba Český rozhlas nebo Echo24, které zprávu ČRo převzalo.
Mimochodem, SSL 3 stále podporuje například i Google na svých serverech. Prolomit SSL 3 spojení pomocí útoku POODLE také není tak jednoduché, jak by se mohlo zdát. Útočník musí alespoň částečně ovládat i klienta a aby z přenášených dat dostal jeden nezašifrovaný bajt, tak ho musí donutit poslat průměrně 256 požadavků protokolem SSL 3. Na rozšifrování 10 bajtů potřebuje tedy poslat zhruba 2500 požadavků. A donuťte pokladnu poslat jednu účtenku tolikrát.
Byla by hloupost začínat nový projekt na 20 let starém protokolu SSL, o tom nemá cenu vůbec diskutovat, ale je také dobré vědět, že to není až tak zlé. Navrhovaný SSL/TLS terminátor IBM DataPower podporuje i moderní TLS, doufejme tedy, že se bude využívat.
Za branou
TSSL ale také klidně může znamenat “Turbo SSL”, napovídalo by tomu použití komponenty s názvem “SSL akcelerátor”.
strana 46, žluté označení je moje
Tohle ale nemyslím úplně vážně, “SSL akcelerátor” bude znamenat SSL/TLS terminátor a je to běžně používaná věc. Důležitější je, že za tímto terminátorem už je pouhé nešifrované HTTP, protože HTTPS již bylo “ukončeno”. Znamenalo by to tedy, že v datacentru systému EET budou data přenášena nešifrovaně a poněvadž datacentra pro EET mají být dvě (vzdálená od sebe více než 6 km a méně než 30 km), tak by data mohla být přenášena v čitelné podobě i mezi těmito datacentry a to i přesto, že SSL/TLS terminátor má podle nákresů být v každém datacentru. SSL/TLS terminátor má totiž sloužit jenom pro příchozí spojení z pokladen nebo z webových prohlížečů, ale už ne na šifrování replikovaných dat z jednoho databázového serveru do druhého v jiném datovém centru.
Na jiných místech specifikace se ale píše o “zabezpečené síti”, případně o demilitarizovaných zónách (DMZ), není tedy jasné, jestli přenos mezi datacentry nebude zabezpečen na jiné úrovni, než na HTTPS.
strana 44, žluté označení je moje
strana 105
Co dál?
Sepsal jsem svoje první pocity ze čtení tohoto dlouhého dokumentu. Rozhodně jsem nečetl všechno a ani nevím, jestli mám chuť se k tomuto dokumentu v tomto roce ještě vůbec vracet. Kvalita materiálu je tragická, jak po formální stránce (spousta překlepů, chyby v pravopisu, chybné součty), tak po obsahové (co je napsáno na jedné stránce, nemusí vůbec platit na další), zabezpečení celého projektu se tedy velmi špatně posuzuje.
Navíc tento dokument nepředstavuje zákon, ale “jen” specifikaci projektu se spoustou nezávazných doporučení, tedy jakousi studii. Finální verze a zákon se tedy mohou od tohoto skoro rok starého textu značně lišit. Dostali jsme ale jedinečnou šanci nahlédnout do možného fungování EET i krásný příklad toho, že některé projektové dokumentace se utajují proto, že to jsou prostě a jednoduše slátaniny, ne proto, aby byly v bezpečí. Z nejedné vysoké školy by vás za takto nekvalitní závěrečnou práci nejspíš vyhodili.
Jako slzy v dešti
Ale pojďme skončit trochu veseleji. Monolog Roye Battyho, kterým jsem začal, končí slovy “Je čas zemřít.” Už starej Benny říkal, že na tomto světě není nic jistého, kromě smrti a daní. Jistě vás tedy nepřekvapí, že IPv6 adresa Integrovaného informačního systému Státní pokladny na adrese portal.statnipokladna.cz obsahuje slova “dead face”.
Náhoda? Nemyslím si. On ten Franklin věděl, o čem mluví. Snad nějakou podobnou adresu vymyslí i pro systém EET. Mě jich pár už napadlo.
