Vlákno názorů k článku Jak EET vidí ajťák aneb Draze zaplacená vražda uživatelské přívětivosti od anonym - Pánové, kdyby někdo doufal v součinnost GFŘ, tak...

Pánové, kdyby někdo doufal v součinnost GFŘ, tak tady je jejich odpověď:

Předmět: RE: Dotaz z kontaktního formuláře
Datum: Sun, 26 Jun 2016 17:51:30 +0200
Od: ePodpora (GFŘ) <epodpora@fs.mfcr­.cz>
Komu: Král Karel

Dobrý den,
o zveřejnění vámi požadovaných „příkladů/šablon zpracování EET v různých vývojových jazycích“ v současné době Finanční správa neuvažuje.

S pozdravem

Radek Korčák
Generální finanční ředitelství
Technická podpora aplikací
Daňového portálu www.daneelektronicky.cz
E-mail: epodpora@fs.mfcr.cz

Od:
Odesláno: 25. června 2016 21:49
Komu: ePodpora (GFŘ)
Předmět: Dotaz z kontaktního formuláře

Údaje odeslané z kontaktního formuláře:
Checkboxy: Technický dotaz
Jméno: Karel
Příjmení: Král

E-mail:

Dotaz: Dobrý den, nebylo by možné z vaší strany připravit nějaké šablony pro komunikaci s EET systémem v nejběžnějších programovacích nástrojích? Stačí jednoduché příklady, ušetřilo by to tisíce hodin práce. Vámi zvolené řešení nepoužívá zrovna jednoduché postupy co se týká podpisování zpráv. Doporučil bych příklady pro C# Microsoft .NET a Java.
Změnit zprávu

Ano, to já ani netvrdil, že se vylučují. Pouze, že preferuji soubory.

Jinak neexportovatelný klíč mít můžete, ale kdokoliv zkušenější jej stejně může získat.

http://stackoverflow.com/questions/3914882/how-to-export-non-exportable-private-key-from-store

Použití systémového úložiště certifikátů a záloha privátního klíče v souboru se nevylučují. Naopak, vhodně se doplňují – privátní klíč máte zazálohovaný v souboru na nějakém externím médiu, které je bezpečně uložené, a pro běžné použití máte privátní klíč v systémovém úložišti certifikátů, kde ho označíte jako neexportovatelný. Nebo ještě lépe máte privátní klíč na nějakém tokenu nebo čipové kartě.

Já Vám rozumím a samozřejmě vím, co to úložiště certifikátů je a jak se s ním pracuje. A přesto, že jsem uživatelem OS Windows, tak úložiště certifikátů nepreferuji, preferuji mít certifikát v souboru, minimálně pro případ zálohy.

Znalost práce s úložištěm je možná základní znalost, nicméně rozhodně se nejedná o základní znalost programátora a použití úložiště by mělo být volbou, nikoliv nutností.

Odkaz, který jste poslal a na který jsem se podíval má několik problémů: 1) Používá SHA512 managed (což by se ještě pro účely EET dalo změnit) a za 2) Řeší se tam podpis celého XML dokumentu, což není případ výpočtu BKP... Tam se podepisuje pouze složený string z několika údajů o tržbě, tudíž díky za tip, ale nepoužitelné

Mám použitelné řešení, ale to Vám bohužel nabídnu pouze za $$$ (nebo CZK).

GFŘ by si celý proces zjednodušilo, kdyby uveřejnilo příklady zdrojových kódů pro .NET, Javu a C, tedy dnes nejpoužívanější jazyky pro tvorbu pokladních systémů. :-)

Nejprve bych chtěl autorovi poděkovat za přínosný článek, skutečně jsem při vývoji v .NET narazil na určité problémy s generováním BKP.

Nicméně:

Není pravdou, že nelze standardními cestami vytvořit digitální podpis pomocí RSA a SHA256 v .NET snadným způsobem. Ve svém software (treek's cryptographic messenger) jsem se zabýval ověřením původce zprávy a právě tuto metodu jsem aplikoval.

Ve skutečnosti jde o cca 8 řádků zdrojového kódu a to včetně definice funkce. Průšvih vidím jinde (alsepoň u .NET4) RSACryptoServi­ceProvider má jen metody From/ToXMLString, takže snadno můžete certifikát (priv. klíč) načíst jen z XML formátu, který se používá jen u .NET. Dle vyjádření GFŘ (ptal jsem se mailem) nebudou poskytovat certifikáty v XML, takže se vývojář musí poprat s úložištěmi certifikátů, jejich volbou a bůhvíčím ještě. Případně použít externí komponentu a převést formát certifkátu.

Výše uvedené platí, pokud budete skutečně stačit vzít zdrojový text, z něj udělat SHA256 hash a ten poté podepsat (jinak se snad ani nepodepisuje vzhledem k omezenosti velikosti dat, se kterými může během jedné kryptooperace RSA pracovat). Z manuálu zveřejněného GFŘ to není úplně jasné a studovat, co se myslí přesně tím RSAwithSHA256 (tedy číst 500 stran ryze odborných) se mi nechtělo.