Česká národní banka (ČNB) Jaroslav Zatloukal Verze: 0.9.20210111 ČNB Nahrazuje: N/A listopad 2017 Kategorie: Uživatelská příručka Příručka uživatele SFTP serveru HUB.CNB.CZ Status Tento dokument obsahuje informace pro uživatele, kteří zvažují zasílání obsahů předepsaných MiFID/MiFIR prostřednictvím SFTP serveru NCA ČNB. Shrnutí Tento dokument obsahuje uživatelskou příručku klienta serveru HUB.CNB.CZ (dále jen server). Server zahrnuje několik oddělených prostředí určených pro výměnu zabezpečených obsahů (respektive souborů) mezi klientem a aplikacemi na straně NCA. Server poskytuje obecné rozhraní pro vzájemné předávání souborů. Cílem jeho nasazení bylo doplnit do portfolia stávajících sběrných kanálů, kterými ČNB v současnosti disponuje, kanál splňující požadavky kladené na NCA specifikacemi ESMA. Zkratky BAH business application header (ESMA) CPoK cryptographic pair of keys DNS domain name system ESMA European Security and Markets Authority FIRDS Financial Instrument Reference Data System IPv4 Internet protocol version 4 MiFID Markets in Financial Instruments Directive MiFIR Markets in Financial Instruments Regulation N/A not applicable NCA national competent authority OS operational system RHEL Red Hat Enterprise Linux RVC revocation certificat SFTP secure file transfer protocol SSH secure shell TCP transmission control protocol URC unique registration code XML extensible markup language Pojmy E-MAIL registrovaný kontaktní e-mail server SFTP server HUB.CNB.CZ správa [serveru] skupina správců serveru pracujících pod společnou adresou XML Schema https://www.w3.org/XML/Schema ZIP formát obsahu souboru zahrnující datovou kompresi a případně zabezpečení (šifrování) Obsah Úvod 1 Přístup k serveru 1.1 Příprava na připojení 1.1.1 Úvodní kontakt se správou 1.1.2 Vytvoření kryptografického páru klíčů 1.1.3 Předání veřejného klíče správě 1.1.4 Převzetí veřejného klíče správy 1.1.5 Převzetí jména a hesla k účtu 1.1.6 Předání IPv4 adres správě 1.1.7 Převzetí IPv4 adres serveru 1.1.8 Převzetí veřejných SSH klíčů serveru 1.1.9 Vytvoření revokačního certifikátu 1.1.10 Předání revokačního certifikátu správě 1.2 Připojování 1.2.1 Úvodní připojení 1.2.2 Následná připojení 2 Uživatelský účet 2.1 Domovský adresář 2.2 Adresářový strom 2.3 Soubory 2.3.1 Jmenná konvence 2.3.2 Odesílání souboru - hlášení 2.3.3 Přijímání souboru - odezva 2.3.4 Formální chyby při komunikaci 3 Podpora komunikace v rámci MiFID/MiFIR 3.1 Specifikace ESMA a metodiky ČNB 3.2 Zásady pro zpracování obsahů 3.3 Specifický obsah BAH Reference Kontakt na správu A Parametry serveru B Formáty, rozsahy a limity C Dodatečné ověření identity {přechodné} Úvod Tento dokument popisuje jak provozovat uživatelskou komunikaci jako klient SFTP serveru HUB.CNB.CZ. Tento dokument má tři cíle: 1. Poskytnout popis funkčnosti serveru dostatečný k vědomému a bezpečnému používání uživatelského účtu klientem. 2. Řadou příkladů a podrobně popsaných postupů umožnit uživateli používat tento dokument jako příruční návod, kde bez obšírných úvodů nalezne klient konkrétní řešení. 3. Díky verzování a tím umožněné plné historizaci obsahu jak dokumentu samého tak i odkazovaných zdrojů poskytovat soustavně úplné informace o celém životním cyklu předkládaného řešení. Tento dokument je rozdělen do tří částí. První popisuje přístup k serveru, a to od úvodního kontaktu se správou až po přechod do rutinního provozu. Druhá kapitola popisuje prostředí uživatelského účtu na serveru, a to jak strukturálně (adresářový strom), tak procesně (práce se soubory). Třetí kapitola popisuje podporu, kterou server poskytuje konkrétním implementacím definovaným v rámci MiFID/MiFIR. Celý text je formálně upraven tak, aby veškeré konkrétní informace nebyly explicitně uvedeny v textu, ale byly z textu pouze odkazovány do dodatků. Příklady použité v tomto dokumentu byly vytvořeny v prostředí operačního systému RHEL 6. Použité programy pocházení z rodiny svobodného software a jsou dostupné pro i ostatní běžné OS. 1 Přístup k serveru Tato kapitola popisuje přístup k serveru z pohledu klienta. Její první podkapitola popisuje přípravu klienta na připojení. V této fázi klient komunikuje se správou. Postupně tak dojde ke vzájemné výměně informací potřebných pro zajištění bezpečnosti další komunikace. Druhá podkapitola popisuje vlastní připojování uživatele k serveru pomocí SFTP klienta. 1.1 Příprava na připojení Tato kapitola popisuje přípravu klienta na připojení. Její první podkapitola popisuje úvodní kontakt klienta se správou, druhá vytvoření kryptografického páru klíčů klienta, třetí předání veřejného klíče klienta správě, čtvrtá převzetí veřejného klíče správy klientem, pátá převzetí jména a hesla k účtu na serveru klientem, šestá předání klientských IPv4 adres správě, sedmá převzetí IPv4 adres serveru klientem osmá převzetí veřejných SSH klíčů serveru klientem, devátá vytvoření revokačního certifikátu klienta a desátá předání revokačního certifikátu správě. Komunikace mezi klientem a správou probíhá elektronickou poštou. Zprávy by měly být ve formátu prostého textu (plain text). Struktura zpráv je striktně předepsaná, uvádění jiných informací, než těch, které jsou výslovně požadovány v postupech uváděných dále, může vést k prodloužení doby zpracování příslušných požadavků. Obě strany využívají své E-MAILy. (Je-li E-MAIL zapsán kapitálkami, jde o registrovaný kontaktní e-mail.) Iniciátor komunikace uvede do předmětu zprávy strukturovaný text, který je příjemcem interpretován jako příkaz s případnými argumenty. Příjemce požadavek odbaví a zasilateli odpoví opět strukturovaným textem v předmětu. V některých případech je obdobně využíváno i tělo zprávy. 1.1.1 Úvodní kontakt se správou Tato kapitola popisuje úvodní kontakt klienta se správou serveru. Klient touto cestou předá správě LEI a E-MAIL vykazujícího subjektu. Pokud je E-MAIL shodný s adresou odesílatele, neuvádí se v příkazu. Správa odpoví (na adresu odesílatele příkazu) URC, který je s tímto LEI, v evidenci správy, trvale spojen. Pokud není odesílatel příkazu shodný s E-MAILem, uvede správa v odezvě za URC i E-MAIL. 1. Klient zašle správě příkaz "LEI[ E-MAIL] ? urc", kde za LEI a případně i E-MAIL dosadí. 2. Správa příkaz odbaví odezvou "LEI ? urc URC[ E-MAIL]", kde za URC a případně i E-MAIL dosadí. Pokud je LEI hlášeno poprvé, dojde k jeho zaevidování společně s poskytnutým E-MAILem. Tomuto LEI správa přidělí nové URC. Pokud je hlášeno LEI již zaevidované, vrátí správa jeho URC a případně i E-MAIL. URC viz Dodatek B. Příklad 1.1.1.x1: Ukázky úvodních kontaktů se správou: o Zpráva obsahující příkaz: ---------------------------------------------------------------------------- From: admin@company.com To: hub@cnb.cz Subject: 549300DS86PEHLIYB473 contact@company.com ? urc ---------------------------------------------------------------------------- o Zpráva obsahující odezvu: ---------------------------------------------------------------------------- From: hub@cnb.cz To: admin@company.com Subject: 549300DS86PEHLIYB473 ? urc 3F7 contact@company.com ---------------------------------------------------------------------------- Příklad 1.1.1.x2: o Zpráva obsahující příkaz: ---------------------------------------------------------------------------- From: contact@company.com To: hub@cnb.cz Subject: 549300DS86PEHLIYB473 ? urc ---------------------------------------------------------------------------- o Zpráva obsahující odezvu: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: 549300DS86PEHLIYB473 ? urc 3F7 ---------------------------------------------------------------------------- 1.1.2 Vytvoření kryptografického páru klíčů Tato kapitola popisuje postup vytvoření CPoK klienta ve standardu OpenPGP [1]. Tento CPoK je určen zejména k zabezpečení obsahu souborů, se kterými bude klient pracovat na serveru. Předpokladem pro vytvoření CPoK je dostupnost příslušného programu [2]. Technicky bude výsledkem činnosti, popisované dále v této kapitole, množina diskových souborů, které program uloží do domovského adresáře určeného uživatelem programu. Je nezbytné tento adresář přechovávat v bezpečném úložišti, protože obsahuje také soukromý klíč klienta. Tento klíč je sice chráněn (je doporučeno silným) heslem, ale samo odcizení tohoto klíče již znamená určité riziko. V případě, že má klient podezření na zneužití CPoK třetí stranou, měl by o tom informovat správu. Parametry CPoK: 1. Podepisování: algoritmus RSA, velikost klíče 2048. 2. Šifrování: algoritmus RSA, velikost klíče 2048. 3. Platnost CPoK by měla z organizačních důvodů pokrývat jeden kalendářní rok. Začátek platnosti CPoK je dán technicky, a to okamžikem jeho vytvoření. Typicky bude klient CPoK vytvářet ve třech případech: o Příprava na zahájení vykazování. o Kompromitace nebo vypršení platnosti. o Pravidelná příprava na další kalendářní rok. V první a druhém případě není možno datum zahájení platnosti nijak předurčovat, klient vytvoří CPoK v okamžiku, kdy jej bude potřebovat. Ve třetím případě by klient měl CPoK vytvářet v posledním čtvrtletí před začátkem kalendářního roku, pro který je CPoK určen. Konec platnosti je organizačně stanoven na 31. ledna roku, který následuje po kalendářním roce, pro který je CPoK určen. Pokud klient vytváří CPoK dříve než v posledním čtvrtletí roku, měl by jeho platnost ukončit 31. ledna příštího roku. CPoK tak pokryje období do pravidelné roční obnovy. Pokud klient vytváří CPoK v rámci pravidelné roční obnovy, tedy v posledním čtvrtletí roku, měl by jeho platnost nastavit do 31. ledna přespříštího roku. Platnost CPoK se do programu zadává jako počet dnů od okamžiku jeho vytvoření. Pro účel výpočtu neuvažujeme čas v rámci dne. Příklad 1.1.2.x1: Pro CPoK na rok 2018 vytvářený dne 4. října 2017 spočteme počet dnů platnosti jako rozdíl mezi 31. lednem 2019 a tímto datem. Vyjde nám 484 kalendářních dnů, které můžeme zadat na výzvu do programu. 4. CPoK je pro uživatele popsán identifikátorem, který je složen z těchto částí: o Název (Real name) musí odpovídat masce "AAA_KEYENC_PUB_BBBBBB_CC", kde jednotlivé segmenty mají tento význam: AAA URC KEYENC kód pro soubor obsahující (z pohledu správy) šifrovací klíč, konstanta PUB kód pro soubor obsahující (z pohledu správy) veřejný klíč, konstanta BBBBBB pořadové číslo CPoK v rámci kalendářního roku, sekvence v rozsahu 000001 až 999999 CC poslední dvojčíslí letopočtu, pro který je CPoK určen o E-MAIL (Email address). o Komentář (Comment) musí obsahovat kód typu prostředí (viz Dodatek A) následovaný mezerou (" ") a URC. 5. Zabezpečení CPoK, respektive jeho soukromého klíče, provede uživatel heslem dostatečné robustnosti. K zadání tohoto hesla vyzve uživatele program. Příklad 1.1.2.x2: Vytvoření CPoK na rok 2018 v programu GnuPG pro testovacího uživatele s URC "FFF" (výpis byl formátován a zkrácen): ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg --gen-key gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 2048 Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 465 Key expires at Thu 31 Jan 2019 01:59:38 PM CET Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: FFF_KEYENC_PUB_000001_18 Email address: contact@company.com Comment: TEST FFF You selected this USER-ID: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. ------------------- Zde očekávejte výzvu k zadání hesla. ------------------- gpg: /home/u03740/doc/hub/FFF/.gnupg/trustdb.gpg: trustdb created gpg: key EB869180 marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2019-01-31 pub 2048R/EB869180 2017-10-23 [expires: 2019-01-31] Key fingerprint = 2F8C BE62 F475 A6AA 265F A358 FA85 7B7D EB86 9180 uid FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com> sub 2048R/2742359D 2017-10-23 [expires: 2019-01-31] $ ---------------------------------------------------------------------------- 1.1.3 Předání veřejného klíče správě Tato kapitola popisuje předání veřejného klíče klienta správě. 1. Klient vyexportuje veřejný klíč z úložiště jako prostý text. Příklad 1.1.3.x1: Export veřejného klíče na rok 2018 testovacího uživatele s URC "FFF" pomocí programu GnuPG: ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg --armor \ > --export FFF_KEYENC_PUB_000001_18 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.14 (GNU/Linux) mQENBFnt6AcBCADTeBzkwI6Ps++hcm+sKddzyc8eNadaTWFkDKrr8xu9cI2bE0aX SmDvebziMwH2x0OhFIjMyF+pUc9WR11DocdpIkkMF7SVmrwA+YrdXYyuLM1baxIt qnyLpQUch9x/gAGWDIJi6RGgSi4KPjqapsgbV0Rjqovwcbfg+XXYSfJm5zAhrSlO syn05klJwgIcNZXlJCmZRJpntE9zY1/56FliBo87axpDjXJCneDBZ26HLW62wgfC hIv4d7Ea6rLJg1tJm7m2murPc8GrixTCnBRIlvCL08kpKpgPd9++rWqKpWlPlaop w8NQp1g57hj3dL/KKn8Q4HMFRq9xA5vZq8wNABEBAAG0OUZGRl9LRVlFTkNfUFVC XzAwMDAwMV8xOCAoVEVTVCBGRkYpIDxjb250YWN0QGNvbXBhbnkuY29tPokBPgQT AQIAKAUCWe3oBwIbAwUJAmUJgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ +oV7feuGkYAV3AgAkwEHUEWdopwii0swDqr24l3Xx8TwfKu5UnIjodtfNrOa7v02 MyRkOh9SCkZ0vr/qy1DWzsrMulnC24usITe3nC/x1DlKKOFVCR2iTJwoy1LAVgSe UouV3zy6EenjVmE1X71DOeafFJJQe129RBtdGW7W/bq7yGODEqlvCd41i1QiyVvp lzHcdfSSYguC2quOQ5ECmMGrVexw0tZqMh95SWlpIDrZmQvA1yAv+SfeIu67XuyM UbyOG8MqKMPaoB5S3CtSRofX21d8fitbi5SRq7JxFV0rtzNH930V2QnS0XEH6mfx bDCm0y9teEIY2Octqerqd0OAXzGVjua1OLYKGrkBDQRZ7egHAQgAwJ3DN4yZppF5 BJATs7rpZqQIArUz0WNXNU46yJPrjWUJNaFB/cELqL/lJa4YLJvcPatJ+oWamEH4 7aCZqRlYf0UUXkX5CfZ3NN2uEmupWy5ODi7HdN7f4FMHOrI17i4E0ahq42/6Z1ZS iVcQV9SFjV4aiJCS0WtJjGXVmnPkkfmMJAKpLHY4YNehT1hAP5Idpl/j2x4lTiK+ g3hCqbUZJpi9IZ8le/bigYN2pripR1UdN0HPie5zsobmwUMZp6P9kA3HfrqrRy6o 4mFpVQuliKajxyJDcky89pbebSzdNNjg1pTMdGwpLoagLbWrSNpiX2D9yrsGEAd8 hYkWvLyFswARAQABiQElBBgBAgAPBQJZ7egHAhsMBQkCZQmAAAoJEPqFe33rhpGA 4+sH/3a74mxJSO50tDvArrNEk6wqTzdAxy1cM1j0VvZXUxJylS+Rd1mpBm/a90HP kz1JM0ujLROAerXQmEhIWSLfF2GVaIuypkUZxvXTBU+S7xPsMVJY1kcpFmkZijzj X759difviFKm1b9cecDS5PNF5tqB8F5OfK1OUAyqpzAUCn++48bQVBCdAmoO9eOW xDvGfWwSIgiv3PwE7zuxIFYFlXo9020L/HKBORK4+CayviBJo3AC6kM9NYzN+F1N LX2n6ppBRHRIxbWRr6Vdd92q5fX+tSRcgBTrl2Udphk+2vuLfupIlEpKiC+5BoDm +B4wel60mA/acCXP9su30oW7kr4= =qm8A -----END PGP PUBLIC KEY BLOCK----- $ ---------------------------------------------------------------------------- 2. Klient zašle správě příkaz "KEY ! key", kde za KEY dosadí komentář (Comment) zadaný při vytváření CPoK. Do těla zprávy pak okopíruje připravený výpis veřejného klíče. Odesílatelem musí být E-MAIL URC. Příklad 1.1.3.x2: Zpráva s příkazem k převzetí veřejného klíče dle předchozího příkladu: ---------------------------------------------------------------------------- From: contact@company.com To: hub@cnb.cz Subject: TEST FFF ! key -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.14 (GNU/Linux) mQENBFnt6AcBCADTeBzkwI6Ps++hcm+sKddzyc8eNadaTWFkDKrr8xu9cI2bE0aX SmDvebziMwH2x0OhFIjMyF+pUc9WR11DocdpIkkMF7SVmrwA+YrdXYyuLM1baxIt qnyLpQUch9x/gAGWDIJi6RGgSi4KPjqapsgbV0Rjqovwcbfg+XXYSfJm5zAhrSlO syn05klJwgIcNZXlJCmZRJpntE9zY1/56FliBo87axpDjXJCneDBZ26HLW62wgfC hIv4d7Ea6rLJg1tJm7m2murPc8GrixTCnBRIlvCL08kpKpgPd9++rWqKpWlPlaop w8NQp1g57hj3dL/KKn8Q4HMFRq9xA5vZq8wNABEBAAG0OUZGRl9LRVlFTkNfUFVC XzAwMDAwMV8xOCAoVEVTVCBGRkYpIDxjb250YWN0QGNvbXBhbnkuY29tPokBPgQT AQIAKAUCWe3oBwIbAwUJAmUJgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ +oV7feuGkYAV3AgAkwEHUEWdopwii0swDqr24l3Xx8TwfKu5UnIjodtfNrOa7v02 MyRkOh9SCkZ0vr/qy1DWzsrMulnC24usITe3nC/x1DlKKOFVCR2iTJwoy1LAVgSe UouV3zy6EenjVmE1X71DOeafFJJQe129RBtdGW7W/bq7yGODEqlvCd41i1QiyVvp lzHcdfSSYguC2quOQ5ECmMGrVexw0tZqMh95SWlpIDrZmQvA1yAv+SfeIu67XuyM UbyOG8MqKMPaoB5S3CtSRofX21d8fitbi5SRq7JxFV0rtzNH930V2QnS0XEH6mfx bDCm0y9teEIY2Octqerqd0OAXzGVjua1OLYKGrkBDQRZ7egHAQgAwJ3DN4yZppF5 BJATs7rpZqQIArUz0WNXNU46yJPrjWUJNaFB/cELqL/lJa4YLJvcPatJ+oWamEH4 7aCZqRlYf0UUXkX5CfZ3NN2uEmupWy5ODi7HdN7f4FMHOrI17i4E0ahq42/6Z1ZS iVcQV9SFjV4aiJCS0WtJjGXVmnPkkfmMJAKpLHY4YNehT1hAP5Idpl/j2x4lTiK+ g3hCqbUZJpi9IZ8le/bigYN2pripR1UdN0HPie5zsobmwUMZp6P9kA3HfrqrRy6o 4mFpVQuliKajxyJDcky89pbebSzdNNjg1pTMdGwpLoagLbWrSNpiX2D9yrsGEAd8 hYkWvLyFswARAQABiQElBBgBAgAPBQJZ7egHAhsMBQkCZQmAAAoJEPqFe33rhpGA 4+sH/3a74mxJSO50tDvArrNEk6wqTzdAxy1cM1j0VvZXUxJylS+Rd1mpBm/a90HP kz1JM0ujLROAerXQmEhIWSLfF2GVaIuypkUZxvXTBU+S7xPsMVJY1kcpFmkZijzj X759difviFKm1b9cecDS5PNF5tqB8F5OfK1OUAyqpzAUCn++48bQVBCdAmoO9eOW xDvGfWwSIgiv3PwE7zuxIFYFlXo9020L/HKBORK4+CayviBJo3AC6kM9NYzN+F1N LX2n6ppBRHRIxbWRr6Vdd92q5fX+tSRcgBTrl2Udphk+2vuLfupIlEpKiC+5BoDm +B4wel60mA/acCXP9su30oW7kr4= =qm8A -----END PGP PUBLIC KEY BLOCK----- ---------------------------------------------------------------------------- 3. Správa příkaz odbaví odezvou "KEY ! key ? fp STAMP TIME", kde za KEY dosadí podle textu příkazu. Připojením "? fp" požádá správa klienta o zaslání signatury (fingerprint) předávaného klíče. Za STAMP správa dosadí pseudonáhodnou sekvenci osmi alfanumerických znaků a za TIME pak časovou značku (formát viz Dodatek B). 4. Správa může do těla zprávy vložit jednu nebo i několik instrukcí za účelem zvýšení pravděpodobnosti správného rozpoznání identity klienta. Příklad 1.1.3.x3: Zpráva s výzvou k zaslání signatury veřejného klíče dle předchozího příkladu: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ! key ? fp G7GO49mp 20171005123456 Uveďte, prosím, kolik jednotlivých LEI v naší evidenci aktuálně zastupujete? ---------------------------------------------------------------------------- 5. Klient si vypíše programem požadovanou signaturu (fingerprint) a případně připraví obsah odpovědi dle instrukcí od správy. Příklad 1.1.3.x4: Výpis signatury klíče dle předchozího příkladu: ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg --fingerprint FFF_KEYENC_PUB_000001_18 pub 2048R/EB869180 2017-10-23 [expires: 2019-01-31] Key fingerprint = 2F8C BE62 F475 A6AA 265F A358 FA85 7B7D EB86 9180 uid FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com> sub 2048R/2742359D 2017-10-23 [expires: 2019-01-31] $ ---------------------------------------------------------------------------- 6. Klient odbaví výzvu odezvou "KEY ! key ? fp STAMP TIME", kde přesně zopakuje předmět výzvy a na první řádek těla zprávy zapíše samostatně signaturu. 7. Od druhého řádku dále pak může klient zapsat případně odpovědi na instrukce od správy. Příklad 1.1.3.x5: Zpráva s odezvou na výzvu k zaslání signatury veřejného klíče dle předchozího příkladu: ---------------------------------------------------------------------------- From: contact@company.com To: hub@cnb.cz Subject: TEST FFF ! key ? fp G7GO49mp 20171005123456 2F8C BE62 F475 A6AA 265F A358 FA85 7B7D EB86 9180 1 ---------------------------------------------------------------------------- 8. Správa ověří shodu předmětu odezvy s výzvou a dále shodu doručené signatury se signaturou přikázaného veřejného klíče. 9. Správa odpoví odezvou "KEY ! key RESULT[ ERROR]", kde za KEY dosadí komentář (Comment) CPoK. Pokud jsou všechny kontrolované znaky (předměty zpráv, signatury klíčů a E-MAIL) shodné, pak správa klíč zaeviduje a za RESULT dosadí "0". Jinak dosadí hodnotu větší než "0" a za ERROR pak případně informaci o chybě. Příklad 1.1.3.x6: Zpráva uzavírající komunikaci: o varianta - vše je v pořádku: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ! key 0 ---------------------------------------------------------------------------- o varianta - chyba: použit neregistrovaný E-MAIL: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ! key 1 unregistered E-MAIL ---------------------------------------------------------------------------- 1.1.4 Převzetí veřejného klíče správy Tato kapitola popisuje postup převzetí veřejného klíče správy do prostředí klienta. Podobně jako klient používá pro každý typ prostředí samostatný CPoK, používá samostatné CPoK i správa serveru. Veřejné klíče pro jednotlivá prostředí a roky viz Dodatek A. 1. Podle typu prostředí zvolí klient veřejný klíč správy. Veřejné klíče jsou dostupné ve formě prostého textu, který klient okopíruje do souboru. 2. Připravený soubor klient importuje programem do svého úložiště klíčů. Příklad 1.1.4.x1: Import veřejného klíče správy do úložiště testovacího uživatele s URC "FFF" pomocí programu GnuPG (výpis byl formátově upraven): ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg --import CNB_KEYENC_PUB_000001_18.gpg gpg: key EE21B738: public key "CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb. cz>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) $ ---------------------------------------------------------------------------- 3. Autenticitu importovaného veřejného klíče ověří klient srovnáním signatury s předlohou uvedenou v Dodatku A. Příklad 1.1.4.x2: Výpis signatury pro klíč správy serveru pomocí programu GnuPG: ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg --fingerprint CNB_KEYENC_PUB_000001_18 pub 2048R/EE21B738 2017-10-23 [expires: 2019-01-31] Key fingerprint = C389 BF2D 258E E3B0 A1F2 4013 D745 6B16 EE21 B738 uid CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz> sub 2048R/74B6BC6D 2017-10-23 [expires: 2019-01-31] $ ---------------------------------------------------------------------------- 4. Po ověření shody signatur může klient podepsat veřejný klíč správy svým CPoK a prohlásit tak tento klíč za validní. Explicitní validita klíče zvyšuje produktivitu jeho používání. Příklad 1.1.4.x3: Postup podepsání klíče správy pomocí CPoK klienta pomocí programu GnuPG. Klient kromě výchozího volání musí dále zadat v promptu programu postupně příkaz "sign", potvrdit úmysl "y", zadat heslo CPoK a program ukončit příkazem "save". Před podpisem má klíč vlastnost "validity: unknown". Podepsáním se vlastnost změní "validity: full". (výpis byl formátově upraven): ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg \ > --default-key FFF_KEYENC_PUB_000001_18 \ > --edit-key CNB_KEYENC_PUB_000001_18 pub 2048R/EE21B738 created: 2017-10-23 expires: 2019-01-31 usage: SC trust: unknown validity: unknown sub 2048R/74B6BC6D created: 2017-10-23 expires: 2019-01-31 usage: E [ unknown] (1). CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz> Command> sign pub 2048R/EE21B738 created: 2017-10-23 expires: 2019-01-31 usage: SC trust: unknown validity: unknown Primary key fingerprint: C389 BF2D 258E E3B0 A1F2 4013 D745 6B16 EE21 B738 CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz> This key is due to expire on 2019-01-31. Are you sure that you want to sign this key with your key "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" (EB869180) Really sign? (y/N) y You need a passphrase to unlock the secret key for user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" 2048-bit RSA key, ID EB869180, created 2017-10-23 ------------------- Zde očekávejte výzvu k zadání hesla. ------------------- Command> save $ gpg --homedir ~/doc/hub/FFF/.gnupg --edit-key CNB_KEYENC_PUB_000001_18 pub 2048R/EE21B738 created: 2017-10-23 expires: 2019-01-31 usage: SC trust: unknown validity: full sub 2048R/74B6BC6D created: 2017-10-23 expires: 2019-01-31 usage: E [ full ] (1). CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz> Command> quit $ ---------------------------------------------------------------------------- 1.1.5 Převzetí jména a hesla k účtu Tato kapitola popisuje postupu převzetí jména a hesla k účtu na serveru. Postup je určen jak pro prvotní, tak pro každé případné následující převzetí těchto přístupových informací. 1. Klient zašle správě příkaz "KEY ? passwd", kde za KEY dosadí komentář (Comment) CPoK. 2. Správa příkaz odbaví odezvou "KEY ? passwd RESULT[ ERROR]", kde KEY převezme z příkazu. Pokud je odesílatelem příkazu E-MAIL příslušný k zaslanému KEY, pak správa za RESULT dosadí "0" a v těle zprávy zašle požadované informace v zabezpečené podobě. Jinak dosadí hodnotu větší než "0" a za ERROR pak případně informaci o chybě. Příklad 1.1.5.x1: o Zpráva obsahující příkaz: ---------------------------------------------------------------------------- From: contact@company.com To: hub@cnb.cz Subject: TEST FFF ? passwd ---------------------------------------------------------------------------- o Zpráva obsahující odezvu: * varianta: vše v pořádku - zpráva obsahuje šifrovanou/podepsanou přílohu s požadovanými informacemi: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ? passwd 0 Attachment: TEST_FFF_20171005123456 ---------------------------------------------------------------------------- * varianta: chyba - veřejný klíč klienta není registrován, správa nemůže požadované informace zašifrovat, přílohu nelze odeslat: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ? key 1 unregistered public key, encryption imposible ---------------------------------------------------------------------------- 3. Přístupové informace klienta jsou uživatelské jméno a heslo. o Každé jméno je jednoznačně a trvale spojeno s unikátním URC. Jméno začíná prefixem dle typu prostředí (viz Dodatek A) a končí URC klienta. Používají se jen malá písmena a číslice. o Heslo generuje správa jako pseudonáhodnou sekvenci alfanumerických (a případně i speciálních) znaků. Každé zaslání příkazu vyvolá vygenerování a nasazení nového hesla. Hesla se nikdy neopakují. 4. Připravené přístupové informace zapíše správa do textového souboru: ---------------------------------------------------------------------------- login LOGIN password PASSWORD ---------------------------------------------------------------------------- Kde za LOGIN dosadí jméno a za PASSWORD heslo uživatele. Příklad 1.1.5.x2: Přístupové informace pro testovacího uživatele s URC "FFF" zapsané do souboru: ---------------------------------------------------------------------------- login hbtfff password 57Gx39tZ ---------------------------------------------------------------------------- 5. Správa vytvoří jméno textového souboru pomocí masky "KEY_TIME.txt", kde za KEY dosadí komentář CPoK a za TIME pak časovou značku (formát viz Dodatek B). Všechny mezery (" "), případně se vyskytující v KEY, budou nahrazeny podtržítky ("_"). 6. Připravený textový soubor správa zašifruje veřejným klíčem klienta a podepíše vlastním CPoK. 7. Klient přijme zabezpečený soubor, rozšifruje jej a získá požadované informace. Příklad 1.1.5.x3: Rozšifrování a kontrola podpisu zabezpečeného souboru (výpis byl formátově upraven): ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg \ > --output TEST_FFF_20171005123456.txt > --decrypt TEST_FFF_20171005123456 You need a passphrase to unlock the secret key for user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" 2048-bit RSA key, ID 2742359D, created 2017-10-23 (main key ID EB869180) ------------------- Zde očekávejte výzvu k zadání hesla. ------------------- gpg: encrypted with 2048-bit RSA key, ID 2742359D, created 2017-10-23 "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" gpg: Signature made Thu 26 Oct 2017 06:55:50 PM CEST using RSA key ID EE21B7 38 gpg: Good signature from "CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>" $ ---------------------------------------------------------------------------- 1.1.6 Předání IPv4 adres správě Tato kapitola popisuje předání IPv4 adres, ze kterých bude klient k serveru přistupovat. 1. Klient zašle správě příkaz "KEY ! ip", kde za KEY dosadí komentář (Comment) CPoK. Do těla zprávy pak vloží jeden nebo více příkazů typu "IP +|-", a to každý příkaz na samostatný řádek. Příkazy budou provedeny v pořadí, jak budou zapsány. Příkazy jsou na sobě nezávislé, výsledek jednoho příkazu neovlivňuje způsob provedení dalších. Každý příkaz v těle zprávy představuje jeden požadavek na nastavení pravidla na IPv4 filtru serveru. Pokud klient požaduje konkrétní adresu povolit, pak za ni uvede znak plus ("+"). Pokud požaduje povolení ukončit, uvede za ni znak mínus ("-"). 2. Správa příkaz odbaví odezvou "KEY ! ip RESULT", kde KEY převezme z příkazu. Pokud odbaví všechny požadavky uvedené v těle příkazu tak, že klient bude uspokojen, pak za RESULT dosadí číslo "0". Jinak dosadí hodnotu větší než "0" a konkrétní chyby pak klient nalezne ve výsledcích zpracování jednotlivých příkazů v těle zprávy. Každý příkaz v těle zprávy je odbaven samostatně a výsledek jeho pracování je správou uveden na řádku za příkazem. Pro řádek se použije maska "IP +|- RESULT[ ERROR]", kde část odpovídající příkazu se převezme ze zprávy příkazce. Pokud je IPv4 adresa formálně správná a nastavení se podaří provést, pak se za RESULT dosadí "0". Jinak se dosadí hodnota větší než "0" a za ERROR pak případně informace o chybě. Příklad 1.1.6.x1: Přidání IPv4 adresy 193.85.3.250 do seznamu oprávněných k přístupu do testovacího prostředí: o Zpráva obsahující příkaz: ---------------------------------------------------------------------------- From: contact@company.com To: hub@cnb.cz Subject: TEST FFF ! ip 193.85.3.250 + ---------------------------------------------------------------------------- o Zpráva obsahující odezvu: * varianta: vše v pořádku: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ! ip 0 193.85.3.250 + 1 rule already exists ---------------------------------------------------------------------------- Komentář: Přesto, že zpracování požadavku neskončilo bez upozornění (RESULT větší než "0"), došlo k uspokojení všech požadavků klienta, a proto je výsledný RESULT "0". * varianta: chyba - adresa nalezena v seznamu nebezpečných adres: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ! ip 2 193.85.3.250 + 2 found in blacklist ---------------------------------------------------------------------------- 1.1.7 Převzetí IPv4 adres serveru Tato kapitola popisuje postup převzetí IPv4 adres serveru klientem. Pro každý typ prostředí může správa použít samostatnou IPv4 adresu. Aktuální IPv4 adresy serveru viz Dodatek A. 1. Klient zvolí, na základě požadovaného typu prostředí, příslušnou IPv4 adresu. 1.1.8 Převzetí veřejných SSH klíčů serveru Tato kapitola popisuje postup převzetí veřejných SSH klíčů serveru klientem. Server poskytuje možnost připojení různým typům klientských programů. Programy mohou při navazování spojení používat různé typy veřejných SSH klíčů. Volbu konkrétního veřejného SSH klíče provádí klientský program automaticky. Signatury veřejných SSH klíčů serveru v závislosti na typu prostředí viz Dodatek A. 1. Klient zvolí, na základě požadovaného typu prostředí, skupinu veřejných SSH klíčů. Signatury pak použije k ověření autenticity serveru při úvodním připojení ke svému účtu. 1.1.9 Vytvoření revokačního certifikátu Tato kapitola popisuje vytvoření RVC k CPoK. RVC je třeba vytvořit bezprostředně po vytvoření CPoK. Parametry RVC: 1. Název RVC bude obdobný názvu CPoK, zamění se pouze typ souboru z KEYENC na KEYERV. 2. Důvod revokace se použije nespecifický ("0 = No reason specified"). 3. Do popisu RVC se uvede komentář (Comment) CPoK. 4. Bezprostředně před vytvořením RVC se program dotáže na heslo k CPoK. Výstupem programu je RVC ve formátu prostého textu, který se obvykle ukládá do souboru s názvem CPoK a příponou ".gpg". Příklad 1.1.9.x1: Vytvoření RVC pro CPoK na rok 2018 testovacího uživatele s URC "FFF" v programu GnuPG (výpis byl formátově upraven): ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg \ > --output FFF_KEYERV_PUB_000001_18.gpg \ > --gen-revoke FFF_KEYENC_PUB_000001_18 sec 2048R/EB869180 2017-10-23 FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@ company.com> Create a revocation certificate for this key? (y/N) y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision? 0 Enter an optional description; end it with an empty line: > TEST FFF > Reason for revocation: No reason specified TEST FFF Is this okay? (y/N) y You need a passphrase to unlock the secret key for user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" 2048-bit RSA key, ID EB869180, created 2017-10-23 ------------------- Zde očekávejte výzvu k zadání hesla. ------------------- ASCII armored output forced. Revocation certificate created. Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others! $ ---------------------------------------------------------------------------- 1.1.10 Předání revokačního certifikátu správě Tato kapitola popisuje předání RVC klienta správě. 1. Klient zašifruje a podepíše RVC. Šifrovat bude pomocí veřejného klíče správy. Podepisovat nejlépe CPoK příslušného RVC. Výstupem bude zabezpečený soubor stejného názvu jako původní soubor s RVC (formát prostý text, přípona ".gpg"), ovšem bez přípony. Příklad 1.1.10.x1: Zašifrování RVC z předchozího přikladu: ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg \ > --default-key FFF_KEYENC_PUB_000001_18 \ > --output FFF_KEYERV_PUB_000001_18 \ > --sign --encrypt --recipient CNB_KEYENC_PUB_000001_18 \ > FFF_KEYERV_PUB_000001_18.gpg You need a passphrase to unlock the secret key for user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" 2048-bit RSA key, ID EB869180, created 2017-10-23 ------------------- Zde očekávejte výzvu k zadání hesla. ------------------- ---------------------------------------------------------------------------- 2. Klient zašle správě příkaz "KEY ! rvc", kde za KEY dosadí komentář (Comment) CPoK. Klient přiloží připravený zabezpečený soubor s RVC. 3. Správa příkaz odbaví odezvou "KEY ! rvc RESULT[ ERROR]", kde KEY převezme z příkazu. Pokud je odesílatelem příkazu E-MAIL příslušný k zaslanému KEY a zabezpečení souboru RVC odpovídá KEY, pak správa za RESULT dosadí "0". Jinak dosadí hodnotu větší než "0" a za ERROR pak případně informaci o chybě. 4. Validní RVC správa zaeviduje k CPoK. Příklad 1.1.10.x1: o Zpráva obsahující příkaz: ---------------------------------------------------------------------------- From: contact@company.com To: hub@cnb.cz Subject: TEST FFF ! rvc Attachment: FFF_KEYERV_PUB_000001_18 ---------------------------------------------------------------------------- o Zpráva obsahující odezvu: ---------------------------------------------------------------------------- From: hub@cnb.cz To: contact@company.com Subject: TEST FFF ! rvc 0 ---------------------------------------------------------------------------- 1.2 Připojování Tato kapitola popisuje způsoby připojování klienta k serveru. První podkapitola popisuje úvodní připojení, druhá pak připojování následná. Odlišnost úvodního od následných připojení spočívá v tom, že při úvodním připojení nemá klient uložen veřejný klíč serveru potřebný k zahájení SSH spojení. Proto je velmi doporučeno, aby klient v rámci úvodního připojení pečlivě překontroloval, že signatura, kterou mu (v tom okamžiku naprosto neznámý) server na základně jeho pokusu o SSH připojení nabídne, je skutečně registrovanou signaturou zamýšleného hostitele (serveru). Na základě úspěchu takové kontroly je pak možno příslušnému serveru důvěřovat a jeho veřejný klíč nechat klienta uložit do interního seznamu důvěryhodných SSH serverů. Následná připojení pak při řešení důvěryhodnosti hostitele mohou uvedený interní seznam využívat místo dotazování se uživatele. Poznámka: Klientský program připouští takové nastavení, při kterém nejsou signatury ověřovány a automaticky se jim důvěřuje. Před takovým nastavením správa serveru však důrazně varuje! K připojování potřebuje uživatel program, SFTP klienta [3]. Programu je třeba vždy zadat argumenty sloužící pro identifikaci komunikujících stran: o Hostname IPv4 adresa nebo DNS SFTP serveru. Hodnoty v závislosti na typu prostředí viz Dodatek A. o Port TCP port na kterém SFTP server očekává připojení klienta. Hodnoty viz Dodatek A. o User Uživatelské jméno klienta viz kapitola 1.1.5. 1.2.1 Úvodní připojení Tato kapitola popisuje úvodní připojení klienta k serveru. Za úvodní se připojení považuje vždy, když signatura poskytnutá ze serveru neodpovídá signatuře očekávané klientem. Klient buď signaturu pro server zatím nemá nebo na serveru došlo ke změně příslušného veřejného SSH klíče anebo se klient připojuje k hostiteli, který se za server pouze vydává. 1. Klient zahájí připojování pomocí programu, kde kromě stálých argumentů uvede navíc argument "StrictHostKeyChecking=ask", který zajistí, že pokud server poskytne dosud neevidovaný veřejný klíč, pak program vyzve uživatele k validaci jeho signatury. Validní veřejné klíče uloží program do seznamu a připojování dokončí. Příklad 1.2.1.x1: Zahájení připojování pomocí programu sftp (výpis byl formátově upraven): ---------------------------------------------------------------------------- $ sftp -oPort=6710 -oUser=hbtfff -oStrictHostKeyChecking=ask hub-t.cnb.cz The authenticity of host 'hub-t.cnb.cz (193.84.159.120)' can't be establishe d. RSA key fingerprint is 41:82:f9:64:62:c7:b6:0e:3c:89:60:8f:8c:ad:89:12. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'hub-t.cnb.cz' (RSA) to the list of known hosts. hbtfff@hub-t.cnb.cz's password: sftp> ---------------------------------------------------------------------------- 1.2.2 Následná připojení Tato kapitola popisuje následná připojování klienta k serveru. Za následné se připojení považuje vždy, když signatura poskytnutá ze serveru odpovídá signatuře očekávané klientem. Klient pak přímo použije veřejný klíč k připojení a nevyžaduje žádnou interakci od uživatele. 1. Klient se připojí pomocí programu, kde uvede jen identifikační argumenty. Příklad 1.2.1.x2: Připojení pomocí programu sftp (výpis byl formátově upraven): ---------------------------------------------------------------------------- $ sftp -oPort=6710 -oUser=hbtfff hub-t.cnb.cz hbtfff@hub-t.cnb.cz's password: sftp> ---------------------------------------------------------------------------- 2 Uživatelský účet Tato kapitola popisuje uživatelský účet klienta na SFTP serveru. První podkapitola popisuje domovský adresář uživatele, druhá adresářový strom nalézající se v tomto adresáři a třetí pak soubory, které může klient na serveru ukládat anebo si z něj kopírovat. 2.1 Domovský adresář Tato kapitola popisuje domovský adresář uživatele. Domovský adresář je výchozím adresářem po přihlášení uživatele. Každý domovský adresář je dedikován právě jednomu uživateli. Oprávnění jsou nastavena tak, aby domovský adresář (včetně všeho co obsahuje) nebyl přístupný jinému uživateli, a to žádným způsobem. Cílem je úplná vzájemná izolace jednotlivých uživatelů. Domovský adresář a jeho obsah jsou určeny jen pro čtení. Příklad 2.1.x1: Výpis cesty k domovskému adresáři: ---------------------------------------------------------------------------- sftp> pwd Remote working directory: / sftp> ---------------------------------------------------------------------------- 2.2 Adresářový strom Tato kapitola popisuje adresářový strom, který má kořen v domovském adresáři uživatele. Adresářový strom každého uživatele vypadá takto: / ├── archive │ ├── incoming │ └── outgoing ├── incoming ├── outgoing └── public Jednotlivé adresáře a podadresáře mají tento význam: o archive neobsahuje žádné soubory, obsahuje dva podadresáře, jeho účelem je krátkodobé (nízké desítky dnů) ukládání kopií souborů, pro které je uživatel příjemcem nebo odesílatelem. o archive/incoming obsahuje kopie souborů, pro které je uživatel příjemcem. o archive/outgoing obsahuje kopie souborů, pro které je uživatel odesílatelem. o incoming obsahuje soubory, pro které je uživatel příjemcem. o outgoing obsahuje soubory, pro které je uživatel odesílatelem. o public obsahuje soubory zveřejněné správou. 2.3 Soubory Tato kapitola popisuje soubory používané pro komunikaci mezi klientem a správou (serverem). První podkapitola popisuje jmennou konvenci zavedenou pro názvy souborů, druhá postup přípravy a odeslání souboru, třetí postup příjmu a zpracování souboru a čtvrtá pak formální chyby, které mohou při komunikaci vzniknout. 2.3.1 Jmenná konvence Tato kapitola popisuje jmennou konvenci zavedenou pro zapisování názvů souborů. Konvence je závazná pro všechny soubory, které se na serveru, respektive na uživatelském účtu nacházejí. V případě adresáře "public" je případná změna, po oznámení uživatelům, vyhrazena. Maska souboru "AAA_BBBBBB_CCC_DDDDDD_EE[_FFFFFFFFFFFFFF].zip" obsahuje základní masku (tedy segmenty "A" až "E") a rozšíření (segment "F") poskytované serverem k vyznačování okamžiku, kdy byl soubor na serveru zaznamenán. Segmenty mohou obsahovat jen písmena velké abecedy bez diakritiky a číslice. Přípona ".zip" je implicitní pro zabezpečené a/nebo komprimované soubory. Přípona ".xml" je pak implicitní pro otevřené formy těchto souborů. Jednotlivé segmenty masky mají tento význam: AAA URC odesílatele BBBBBB kód typu obsahu souboru viz kapitola 3.1 CCC URC příjemce DDDDDD pořadové číslo souboru v rámci aktuálního kalendářního roku, sekvence v rozsahu 000001 až 999999 CC poslední dvojčíslí aktuálního letopočtu FFFFFFFFFFFFFF časová značka (formát viz Dodatek B) 2.3.2 Odesílání souboru - hlášení Tato kapitola popisuje postup přípravy a odeslání souboru. Soubor odesílaný uživatelem na server se také nazývá hlášení. 1. Klient připraví soubor s obsahem, který odpovídá některému z typů předepsaných k odesílání a pojmenuje jej v souladu se jmennou konvencí (použije základní masku). Soubor bude vytvářen v otevřené formě, a proto bude mít příponu ".xml". 2. Hotový soubor klient zašifruje pro příjemce a podepíše za odesílatele. Jméno souboru zůstane stejné, změní se pouze přípona na ".zip". Příklad 2.3.2.x1: Příprava souboru dat typu "DATT10", odesílatel "FFF", příjemce "CNB", jde o soubor s pořadovým číslem 54 v rámci roku 2018. Byl použit program GnuPG: ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg \ > --default-key FFF_KEYENC_PUB_000001_18 \ > --output FFF_DATT10_CNB_000054_18.zip \ > --sign --encrypt --recipient CNB_KEYENC_PUB_000001_18 \ > FFF_DATT10_CNB_000054_18.xml You need a passphrase to unlock the secret key for user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" 2048-bit RSA key, ID EB869180, created 2017-10-23 ------------------- Zde očekávejte výzvu k zadání hesla. ------------------- ---------------------------------------------------------------------------- 3. Zabezpečený soubor klient uloží do adresáře "outgoing" na svém uživatelském účtu na serveru. Příklad 2.3.2.x2: Odeslání souboru připraveného v předchozím příkladu. V příkladu bude použito testovací prostředí, účet uživatele "FFF" bude tedy "hbtfff@hub-t.cnb.cz". Byl použit program sftp: ---------------------------------------------------------------------------- sftp> put FFF_DATT10_CNB_000054_18.zip outgoing/ sftp> ---------------------------------------------------------------------------- 4. Po dokončení ukládání souboru jej server přejmenuje (doplní časovou značku) a přenese do adresáře "archive/outgoing". Příklad 2.3.2.x3: Uložení souboru z předchozího příkladu do archivu: ---------------------------------------------------------------------------- sftp> ls archive/outgoing/ archive/outgoing/FFF_DATT10_CNB_000054_18_20171031130354.zip sftp> ---------------------------------------------------------------------------- 5. Obsah adresáře "archive/"outgoing" pravidelně kontroluje program běžící v interním prostředí ČNB. Nově nalezené soubory kopíruje do zabezpečeného interního prostředí, kde dále proběhne jejich zpracování. Výsledek zpracování je pro klienta zapsán do souboru odezvy. Tento soubor je vytvářen ve formátu prostého textu, použije se přípona ".xml". Následuje zabezpečení souboru šifrou pro klienta a vlastním podpisem, použije se přípona ".zip". Nakonec je do názvu souboru připojena časová značka (formát viz Dodatek B). Zabezpečený soubor program překopíruje do adresářů "incoming" a "archive/incoming". 2.3.3 Přijímání souboru - odezva Tato kapitola popisuje postup příjmu a otevření zabezpečeného souboru. Soubor přijímaný uživatelem prostřednictvím serveru se také nazývá odezva. 1. Klient nalezne zabezpečený soubor v adresáři "incoming". Technicky použije běžný výpis adresáře. Příklad 2.3.2.x1: Výpis adresáře "incoming": ---------------------------------------------------------------------------- sftp> ls incoming/ incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip sftp> ---------------------------------------------------------------------------- 2. Klient okopíruje soubor z adresáře "incoming" na serveru do svého prostředí. Ukončení kopírování detekuje program a automaticky soubor z adresáře "incoming" odstraní. Soubor je pak i nadále k dispozici v adresáři "archive/incoming". Příklad 2.3.2.x2: Kopírování souboru z adresáře "incoming" (výpis byl formátově upraven): ---------------------------------------------------------------------------- sftp> get incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip Fetching /incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip to CNB_FDBT10 _FFF_000054_18_20171031162459.zip /incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip 100% 980 9.8MB/s 00:00 sftp> ---------------------------------------------------------------------------- 3. Klient na zabezpečeném souboru může zkontrolovat podpis odesílatele, a to v rámci operace rozšifrování, jejímž výstupem je soubor s odezvou v otevřené podobě. Příklad 2.3.2.x3: Rozšifrování odezvy pomocí programu GnuPG. Program při "otevírání" souboru vypíše jak veřejný klíč, který byl odesílatelem použit k zabezpečení diskrétnosti obsahu (obsah může takto otevřít jen držitel příslušného CPoK), tak CPoK, který odesílatel použil k podepsání. Pokud by signatura nepocházela z nevalidního nebo neznámého CPoK, program by o této věci vypsal pro příjemce varování. Odezvu v otevřeném tvaru program zapíše do souboru s příponou ".xml": ---------------------------------------------------------------------------- $ gpg --homedir ~/doc/hub/FFF/.gnupg \ > --decrypt CNB_FDBT10_FFF_000054_18_20171031162459.zip \ > --output CNB_FDBT10_FFF_000054_18.xml You need a passphrase to unlock the secret key for user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" 2048-bit RSA key, ID 2742359D, created 2017-10-23 (main key ID EB869180) ------------------- Zde očekávejte výzvu k zadání hesla. ------------------- gpg: encrypted with 2048-bit RSA key, ID 2742359D, created 2017-10-23 "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" gpg: Signature made Thu 26 Oct 2017 06:55:50 PM CEST using RSA key ID EE21B7 38 gpg: Good signature from "CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>" $ ---------------------------------------------------------------------------- 2.3.4 Formální chyby při komunikaci Tato kapitola popisuje formální chyby při komunikaci. Za formální chyby při komunikaci se považují: o nedodržení jmenné konvence, viz kapitola 2.3.1: * HUB-001 chyba ve struktuře názvu, nesprávný počet nebo délka jednotlivých segmentů názvu. * HUB-002 chybný odesílatel, URC nesouhlasí s názvem klientského účtem. * HUB-003 chybný příjemce, musí být "CNB" * HUB-005 chybný kód typu obsahu souboru, viz kapitola 3.1. o HUB-006 překročení maximální velikosti souboru, viz Dodatek B. o HUB-007 překročení kvóty klientského účtu, viz Dodatek B. Nedodržení těchto pravidel blokuje normální zpracování souboru. Program v takovém případě vygeneruje soubor s typem obsahu "FBDHUB", odesílatel "CNB", příjemce určí na základě domovského adresáře, kde soubor získal, pořadové číslo souboru odezvy v rámci roku a letopočet pak vygeneruje. Do souboru zapíše zjištěné chyby. Struktura souboru odpovídá XML Schema [4]. Poznámka: Kódy HUB-XXX uvedené v seznamu výše odpovídají kódům, které v rámci systému HUB používá ESMA. 3 Podpora komunikace v rámci MiFID/MiFIR Tato kapitola popisuje způsob podpory komunikace v rámci MiFID/MiFIR. První podkapitola popisuje podporované specifikace ESMA a metodiky ČNB, druhá zásady pro zpracování obsahů, třetí pak předepsaný obsah BAH. 3.1 Specifikace ESMA a metodiky ČNB Tato kapitola popisuje specifikace ESMA a metodiky ČNB, které definují obsahy souborů podporovaných aktuální implementací serveru. V následujícím seznamu jsou pro každý obsah kromě základních identifikačních údajů uvedeny kódy typů souborů pro hlášení i odezvy a předepsané zabezpečení: o Hlášení souhrnných pozic v komoditních derivátech, povolenkách na emise a jejich derivátech * Specifikace ESMA: [4] * Metodika ČNB: MKT20180103/KOMFIM10/KOM (ČNB) 10-52 * Kód typu obsahu souboru hlášení/odezvy: DATK10/FDBK10 * Zabezpečení: šifrováno pro příjemce, podepsáno odesílatelem o Informace o obchodech s investičními nástroji podle čl. 26 MiFIR * Specifikace ESMA: ESMA/2016/1521 Technical Reporting Instructions, MiFIR Transaction Reporting [4] * Metodika ČNB: MKT20180103/TRAFIM10/FIM (ČNB) 10-97 * K typu obsahu souboru hlášení/odezvy: DATT10/FDBT10 * Zabezpečení: šifrováno pro příjemce, podepsáno odesílatelem o Informace o uzavřených, vypořádaných a zrušených obchodech a převodech * Specifikace ESMA: N/A * Metodika ČNB: MKT20180103/TRAFIM20/FIM (ČNB) 20-97 * K typu obsahu souboru hlášení/odezvy: DATT20/FDBT20 * Zabezpečení: šifrováno pro příjemce, podepsáno odesílatelem 3.2 Zásady pro zpracování obsahů Tato kapitola popisuje zásady pro zpracování obsahů. Zpracováním obsahů se v případě hlášení rozumí provedení veškerých úkonů po technickém otevření zabezpečeného souboru. V případě odezvy jsou to veškeré úkony před technickým zabezpečením souboru. Obsahy jsou z pohledu serveru nedostupné, vlastní otevření/zabezpečení provádí programy umístěné v zabezpečeném interním prostředí ČNB. Mimo tento perimetr není otevřený obsah přípustný. Interní programy pak zpracování obsahů zahajují jejich zafrontováním, a to primárně vždy podle kódu typu obsahu a sekundárně podle časové značky přidělené souboru při jeho ukládání klientem na server. Vlastní zpracování obsahu sestává typicky z těchto kroků: 1. Kontrola obsahu vůči XML Schema. 2. Uložení obsahu do databáze. 3. Provedení vstupních/synchronních kontrol dle specifikace/metodiky. 4. Nastavení stavových příznaků na jednotlivých řádcích i souboru. Stavový příznak definuje následující operace aplikovatelné na předmětné řádky či soubor. 5. Vyzvednutí výsledků asynchronních kontrol pro soubory stejného klienta doručené v předchozích dnech. 6. Spojení výsledků obou typů kontrol do společného obsahu jedné odezvy. Úspěšné dokončení každého kroku je nutnou podmínkou k zahájení kroku následujícího. Pokud obsah neprojde testem vůči XML Schema, pak obsah nelze uložit do databáze a jeho zpracování tak vlastně končí. Pokračuje se pak až sestavováním odezvy. Kromě uvedeného synchronního zpracování existuje také zpracování asynchronní, které provádí program v závislosti na splnění jiných podmínek automaticky. Jde například o validace nástrojů vůči FIRDS. 3.3 Specifický obsah BAH Tato kapitola popisuje obsah BAH, jehož stanovení spadá do kompetence národního regulátora. Doporučení pro definování předpisu plnění viz ESMA/2016/1521 [4], kapitola "6.4 Business Application Header". Předpisy plnění pro jednotlivé elementy jsou zde: o Business Message Identifier "BizMsgIdr" bude sestaven z části názvu souboru odpovídající podle jmenné konvence (viz kapitola 2.3.1) segmentům "A" až "E". Pokud nastane situace, kdy bude k jednomu hlášení nutno vytvořit postupně více odezev (jde konkrétně o vývoj stavu řádku v kontextu opakujících se (asynchronních) kontrol nástrojů vůči FIRDS) aniž by bylo v daném čase k dispozici jiné hlášení, které by poskytlo svoji odezvu jako obálku pro obsah této odezvy, pak bude shora popisovaný element, z důvodu zachování své (globální) unikátnosti, sufixován vždy jedním znakem z posloupnosti "0" až "9" a pak "A" až "Z". Příklad 3.3.x1: Ukázka elementu "BizData/Hdr/AppHdr/BizMsgIdr" pro hlášení: <BizMsgIdr>FFF_DATT10_CNB_000054_18</BizMsgIdr> Příklad 3.3.x2: Ukázka elementu "BizData/Hdr/AppHdr/BizMsgIdr" pro odezvu: <BizMsgIdr>CNB_FBDT10_FFF_000054_18</BizMsgIdr> Příklad 3.3.x3: Ukázka elementu "BizData/Hdr/AppHdr/BizMsgIdr" pro případnou první navazující odezvu: <BizMsgIdr>CNB_FBDT10_FFF_000054_180</BizMsgIdr> o Message Definition Identifier "MsgDefIdr" bude odpovídat výchozímu schématu pro daný typ obsahu, jak jej definují příslušné specifikace ESMA [4]. Žádná specifická XML Schema nebudou zavedena. Reference [1] http://openpgp.org/ [2] http://gnupg.org/download verze>=2.0 [3] https://www.openssh.com/ [4] https://www.esma.europa.eu/policy-rules/mifid-ii-and-mifir/ /mifir-reporting-instructions Kontakt na správu hub@cnb.cz www.cnb.cz Dodatek A. Parametry serveru 1. Značení prostředí: Prostředí Kód Prefix --------- ---- ------ produkční PROD hb testovací TEST hbt 2. Veřejné klíče a signatury podle prostředí a letopočtu: o produkční: * 2021/2022 $ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_21 pub 2048R/156C0D96 2021-01-12 [expires: 2023-01-31] Key fingerprint = 4F23 8820 5426 743F 465D 23AF 762D 1B69 156C 0D96 uid CNB_KEYENC_PUB_000001_21 (PROD CNB) <hub@cnb.cz> sub 2048R/62E56D62 2021-01-12 [expires: 2023-01-31] $ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_21 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBF/89ToBCADdQdEVShW20KH8X18zb42wnHT8XIqmgrRmcnE8oWmJpqHMLyW1 nfU3/xD+taloa0Uz5/nsGfM8Ja95ArD+L8Z/jPIDjdMclF+bIXtmOjskFZdvFumk 1FK8zlR+JhlLJ6oELfDUzWAdlHNueuol8jcAD60dc94PGhVD224/ZBlQ4G8eOAn8 65+71f6HGT1QZi0NltfFIGeoogmzXCzRWRNB7zwhgfy/ZInDklNTrbCoafJsfOXE F7OYGY/n0W6b1l7PtsF+67N9z0kiSv/Ivo8jNaTdaBSUDXH2BO989qAS8VqU6FqN zWhjTPbuJ7WnaKIMSEz+LmWbORxP9R46HxHfABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8yMSAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCX/z1 OgIbAwUJA9tzgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEHYtG2kVbA2W nvMH/iSEaXch/FSDU5q4/frkME19yIH1Hzv6K/OqpJbecbbxFoasuJz5+lgLWvVD dMlOI1mdRRWoY1M0U99MBxTgHmrLyfzm+ykQUxFt69OZHqGp7EXm3iSc53TFXjsA HZawurGr+PkbWwrL4T1XQ5rheJ6IRDlN/k1N0WY3Z4xykbdSRRDFfGLQs2WqM+6X FSu66cwdWNFso5X6diuRhkaHh6WctDdgbkeeE9RjvTi2h1RiDng7hfnRs9OjIkM7 Fj/Kbdidzbrl90l+zsDN4qZ/50A82XeLIabJZ8lhw3Kg6E3edlm0WJno9+xIwnUU vl/31UiAoAidhtV8kpaCNjuNQGq5AQ0EX/z1OgEIAKf4+Tu6SihAUUd0e4bdktvE ZXT53vs9rzXINep4MIHpiGrwFIo9RvNQWEkuqBZJ0/cqkHDIrLj3tE/rt0sLyw5g VGAL6ucSWvoIDCoZ2BIrrPZIZmcsxm8RCQdBWkA3umqESL9QHxk4n5km3qybcPKE wSYXiWJZm9cJlHBzMYWpwG5hdHDDAR4W1C5HKTZ/RVNbT68uSqh47tql3s/KkBIB A10zE/95W3CL0JOn80OgpMUayGFlaV0qNcJAIC5bETore9lwuCsovak9b1Yb8XaD JyGD76VQQeP65ZS+zW2q9RBR3ziHZga+J55CuW+/ZE/20R1nwStQIDjXDFdEyC0A EQEAAYkBJQQYAQIADwUCX/z1OgIbDAUJA9tzgAAKCRB2LRtpFWwNllCAB/9G5Fb3 Zb1Zr9dtjwCrZaB9HVi9hHGlwGj6y3ObbZUB9LcKyn3QwUHL9k/UnEZbWYQHWQZt aZL9M7L3lkgp+dYYYz/ReNofTJkjEIr2A3ZeK2UhIhBwlY6LoL1DkdjwnZfMoa6+ 8AQCBMB+qFx1eV/K0Q24Sce19kFIQv7zmcATZDHrUUPfW9vQPEIV/MCiXpl0V28A PdvSvw12K+so/mgR8l3W4B9NtboAsySrX72BmEnjM48XqggFG4nimzyg3HQSiaoF 4TmT132f/pw9rQcG4AnqHBj3dRckiZGLkw5HVEH0NrCxaC9+5esCs7kXQKogYjBi NdE8NMrpYf0W8bd/ =IyTc -----END PGP PUBLIC KEY BLOCK----- * 2020 $ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_20 pub 2048R/18F8F65A 2020-01-07 [expires: 2021-01-31] Key fingerprint = 7DAB 5259 74AE 17A2 B31B 4199 04FD 0CF9 18F8 F65A uid CNB_KEYENC_PUB_000001_20 (PROD CNB) <hub@cnb.cz> sub 2048R/481B358A 2020-01-07 [expires: 2021-01-31] $ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_20 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBF4UR5UBCAC4IqIWJAP+i0AUmOj+h1yJdfqZjdLuY1VwVDLuYpyfSXUxBJ29 dodCrZ72k/YwtMjS+MgvTAHDE6LOzvN96pPMVELOhDHnKbgYsAffiQvdwcBFmmuN u5ndPFFPj823lrWtZyA7pCl4w1t1fB4obql4qG4tEn54lyryRmOVZZOZwDLcSQ9X 3FDL3ty18XZ6ENxVUrjniAFu0/OsRmZ1kEhrom9Ie0hEsD8IreeXANIK1Sv3kfhI RsAsnlK9b0RfrU4tmMU5xVzaN0jcHS7q5N6eqwsdcILyrDtHQnZ5QFcealnHyLKl udrsMFBU/8usulJo68K3t0Wkwju6BN0WMglBABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8yMCAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXhRH lQIbAwUJAgIpAAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEAT9DPkY+PZa RT0H+wcnGLeJH7dy9CsgLypFhNiskD1cimgv3KJ2yDaEJQNsZzmtFPUzdzhQdZPb 0l1cl5WSJvL2Xhl2qhLcCTqCA4esK7DX5rLTnuZXbTiApT6UhzgbBU0dLHs4Odzc Ck6OJXyPdhb2k5ESSa6u+q3bTGb49P8LMIkIfHzZUW0XP/iEVIN/CNhH+7eamWgX cmiN6INNDUEC/b3BotZaX0TLnzubt8aO5Yma1cKoAorEEWYnW3IwpdCeGEAgUuy1 AB3ECVe/ePyHP3qcKgxj5OmVnSdoktYqftt440dqMR+9VY2xzN0vbC5WHjBDm9HG RDMZuTaDtlMUOQDGEH+pJekmGh25AQ0EXhRHlQEIANIeIQYtKso6OnlxWjMehkzj Inn0ndlTlJpxSV1+va3bJ7o/3AmjZVXZ5crTsjCy3x0AvPCaq+32UrC3QzOfzDuM HXnRYVXGuvlk+jyy/uS/MzEcYHD4qoHqEwZ5Z2BSwSy7r3G/U2VXLLndT1bTeBGw SewjV5eOTOZcljuPtLCK7kt7QAFfFSSz1PenrnfIWphG24VHqVy4VEg6zcF9grlM EWjF50/Mr42Cbf8Gq84RzdQ0i5uIKkXbvjbNAPF+Z6daM3tKePJ4EASrfRaZVpJ6 MDWHHZoLnfuCy9fAEpijE0YQocq3kXY5ESB7eOSKbjj5onzcEev58q02/E2MdVEA EQEAAYkBJQQYAQIADwUCXhRHlQIbDAUJAgIpAAAKCRAE/Qz5GPj2Wt1KCACgZtjd abm2EeUtrq/N9tBNDzux+1p9CJ0G1hqZL4xSj+2NAyVwkgDoBqYr38QmWsrkrVi8 +qmmujyXL5Nmny1/gyyyM/qk2eN964V03yoxpihLY2JUckGpZc1pznrZthB+1UDD g0bWC/4Zsew/Q17+DffG71cfJU6hmNNFxC7D1I45tNe2GHG71GNz2iDVKeEklNAl BkaWbKoE5l39YRViGw4Zy22R35gLBG6MVqYds1OkFEThvaObUKoiSDI9Z6dLETQp Fwl42Eij+SJ5tAYUYfbAM0bl9y+IwjX9cOzVkZZEwEPYQ6OP++g2H3qVE3qKmBrw hpjlu13aQtKo4+d2 =XB31 -----END PGP PUBLIC KEY BLOCK----- * 2019 $ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_19 pub 2048R/729243CD 2019-01-09 [expires: 2020-01-31] Key fingerprint = 14AD A954 0CFF 0EB1 1FB8 4C21 498C 8D8D 7292 43CD uid CNB_KEYENC_PUB_000001_19 (PROD CNB) <hub@cnb.cz> sub 2048R/1BC67BF2 2019-01-09 [expires: 2020-01-31] $ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_19 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBFw2SxsBCACdxMzydeB1n2O9BVVglQlL3TA7+9L2RIDcXrGOSHtH5PyGYZ0T /cNFWAEUBGpsMaA0BvG+Mlooi9UgagFQZ8VyoTkmD58ZzqK2FuvnXFZQr+UpuzBm GLAintPbi1WIZ5HIpzyeapoh5E5KIxL43lggfdGjrh7vbPWhishPvomRNMDDZobR dkPVT2xHEpq8UwX86TWXu9vmFeV+EdPpkaVrfTpWPEQTJJVciXQMaVuw5MxXikMm lyYpztPZeMRfNv9E6fdj4QdvdliFKw72nv62WKAPmH5M3mCFWNUuM6/dlCuKMREz Qs47xK0ZDRrggeyM8uA5msO8cUA50wFJ8lrlABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8xOSAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXDZL GwIbAwUJAf40gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEEmMjY1ykkPN d1MH/Rl40weqdcaJurDob1LyNEmBPJg1ibnek5w0OxuIAVHOaCD0k+B8uuob9Ddv +P5xazgh+l7riqvQHl/c79sphARwBJk6pSSuS3OPzdMVyl1OYkU3zn37BcecYQcE 9u0Zt/JaA8mCw8BT37Z4y3wW8fKnnRzyefcIlc0S5ztsr8xNY2jVICtI8tMm+yWE q8FCAIfmGkxVuWRdeVoLgR3tBMINPGu9KUIyTqJdDUqNdzJvn+RyTiDI7tARXKwp gO/5IzHaO9VJnN0e2JKxYUPfC7FCC5mhAmITIO2UUwrYofijeIyNBxA9HymK6ELf MGbEVuJBYAw4kA3zVDIIOkJDpcm5AQ0EXDZLGwEIALupAKbdA/R8zjtKHHtlK/oB sE867P+64FkfdtQBaNWEBW7PdzzDrKDGaRW071OJthPwAOkcnzzfW7vMGfQsYKqi I+boKBhXHJR/gGuGJWuXHXV1zwxNTtc/o9pqlVOQDHQ2P7ykO9QAtWnqXBFknO46 TxbFKKRuAkxAxpjKmt49zF3maY4Vsr7YAIeTwD0l1J/yS6/3BpgnKQgD1hRPiOnC qhzHFsi9qEF4URo/lg05Xlkbq4Kr3PitKSL5oM6QPwuWEU74v7woqDLDJyQ7q4l5 Q0JoyeT7D2sefaTsErsZ4qoZ7I76LO+bqpEVFSuo41YiaymZTsvueGJd1doY9IEA EQEAAYkBJQQYAQIADwUCXDZLGwIbDAUJAf40gAAKCRBJjI2NcpJDzdXSB/92v25D lK05JR3bhCYvaz2crAkYFnnGi7ISSv5xqH8aNSBHblHPoyCWJKHJ/CQfB2LxJKhi 9IBSY1NBZmjsWY0Bq7XVAk/CqekBhZDvUIOdmM5DcEeMt+w57KKgDuomMr33NcU3 E0wAIiySqg/v0JZoK6oaM7euwqBqpzpTy6eIMwntim41ugNUg5D12eKhkYrrXA4i bZuThUeOzEHXL0uPZKvqa7EmsNdaJqhFCqJztaBWQvGV5VeTJmdsXOW3H75ZQudN xespN2PorAhUex63Dnh+2bjp37XmqYnMelKIDMCnAuDlJzL70DyQjyj18zbU6KL4 zoGL/lUYs0Pe1YFr =Kd2V -----END PGP PUBLIC KEY BLOCK----- * 2018 $ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_18 pub 2048R/A936795A 2017-11-05 [expires: 2019-01-31] Key fingerprint = CD87 AF4F E7C2 1330 A168 6429 1265 9EA8 A936 795A uid CNB_KEYENC_PUB_000001_18 (PROD CNB) <hub@cnb.cz> sub 2048R/07E8D48D 2017-11-05 [expires: 2019-01-31] $ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_18 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.14 (GNU/Linux) mQENBFn/dCYBCADKEYO4tNtyMzTl9+j5qZmCViUDMwHemJI5gD7vc4Cy9p6XGYBz E/Cl4tCp1IHCqHBCzuJXYwGTxPWqejBtY0H+Yfmn9hq/UqC2IqCD53URfq+YTWwj u97K5CjTYJnTpNtKhwiwjnS6EmER1LCO3mcuJcQta13hONc3yO0PcQdzb+AI/UJU X48kNsb3c8IV/zXLOwJWfNocYQhTb8JMhYATIbPwPND6v3PUu+3IV4l6w0RpaiBN ssc7cT/aNsMEApnGHeuuTkk8vHORy6d/hSB8Bgwh3Y1x8pEYcfPIbnLeJ/ZzfJSB Lg241GHgcNfWPwaqeQr8gWmX6NF1ApJMjfIXABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8xOCAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPgQTAQIAKAUCWf90 JgIbAwUJAlPmAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQEmWeqKk2eVr6 dwgAisvTexaHzNTq/aRiSLNcdfflxpv9w0QwzTzaKQLGo9oqXlAWsXa7RWdInZED qcc/8zRoV/Oa7IId3Q+K5f5OngQlvtBns4GQHmFugyoja0lne78GgG8ttMp1OMPy u8I/GYwWSXUozHe3oi1OPAtovlNLH8tUOdZTHE0nkOJE1klUX/7n0CDn4EptuJh/ 8/VCX2Xp1sTsslmJd5ExmwOjr+xsdoV7YGVgwGs+Ugo8LQ7NyYEcrxXBYPv0cuoU 7lAZ+72KtW08XoOJ5NXd5v68r+mCIg8AfL+F38UgnPUxxat2VylAaSTG+yTLKGsc UX8lYr15pGDk1TfE85lnjNrKS7kBDQRZ/3QmAQgAuVIh9N0Jm0tpXmfhGMqKKICx 42Qcz8d3vwSBWSiTSlGMRlufO9cAZxpajx56Gd2RTO8Fup3FJrY6Yt9NLoDtCjg2 w2+MU/Oxw368WHHTWJFdONtsTeVVHGM1VSC6tXdU0fNwdYDdQOBJJl6f2pB1OM01 qmGlVH+PUH3F2UJmUWTO8wx/lvbkT9ZwP/a9YDPP/9qibJxFWrMjukdm2n2MVHsn wgWYlAdeh4qflSX3/8gTkd8f/csBga//2IGBAGk9XW97RHtRgk6hgIUgaeveIQlw yTh0NvX+Wd7vyZJGyd4fP/sUJKiYDhhS8XMog4SUGxYo49nUxmCFgPf1FVctmQAR AQABiQElBBgBAgAPBQJZ/3QmAhsMBQkCU+YAAAoJEBJlnqipNnlajDYIALYF+FWJ jF+BezoTK7sEATFTcCJV2T6RUweMBI+q/vc3/NgM8LOu874tYLvlSgWUNA3vEdRE 9diB1hOnMwXdXdAHmkBeCp3/m4vKAIebceEUVLFsAKjg82LlI/CjKnL+g/pLU6uM Fury4HJyUVtxBtNK9FPK399wsEYrS5I1AiNP4e7kXJ8ltud4lTbWiQNO+Nk8G9wE uhFzY4Dy89YYtTLquPNQt8jLqLoGURxYBl3ewh9evK97YJUAZ6jNpOZ1K87ubbsq 5ht9LtKpiBD2VbFjlwLrZT75Yn8EUK6gu1Qzg14/98ECcE/M9wiViN9GQUy4LKdg y5DGtkR/Fs6E4ZE= =47mr -----END PGP PUBLIC KEY BLOCK----- o testovací: * 2021/2022 $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_21 pub 2048R/5CD486FC 2021-01-11 [expires: 2023-01-31] Key fingerprint = EA95 0763 005B 53EE EB90 509A 55C6 02D9 5CD4 86FC uid CNB_KEYENC_PUB_000001_21 (TEST CNB) <hub@cnb.cz> sub 2048R/AA507CCF 2021-01-11 [expires: 2023-01-31] $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_21 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBF/8w4gBCADuQWUFrMgWolxSojY9DhONLUjLAq8o3IEjGpiC9hBEIyfnScr9 cFX7Bf1SYzRXG0btmjsOKvjFqxojX91UwyK1hmfe4JoQZP79zaq4YdW1i9huX19H VU3xRncgqZYa6kuo/yX8yKo6Zs4qN7cI/7PE1z/2L7WW4tS56YZ+hMSsyQ4rxTFf NbODLjcxtcM1/pcQGB6n94MaCPMe7uYbXWFiQKNoibsWuTUj9kurnx6EXmZXbBcY ldGlqEc5w5B4Zbpd2tgIDNIVTmFqsYwuEm3JlY3Z4Yh2Vv5Eb2tNJLuC/yghpUN/ KvF0soaNo4n+t0G2Zhh0CLFGY61RUuERN5alABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8yMSAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCX/zD iAIbAwUJA9zFAAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEFXGAtlc1Ib8 1AwIAM+34q1ESnzmddfH5y8izDlPnCV06qIJ30AlbSed1Uehbmtg8NPQagPxyD0t Hji6QsoJKmJ6w9sqrvMk0O6yUToqC0rmakCZ09XZUXZY1uB+cVknW0z23eqQDaUS GBIoN3vDaws25rhLUAkRXRClrsRmtaX2/tVUv08/CJNPx06vB8JrHIW0k3SM/ViA Vih0qaoRpyyHh15KhUk+a1HlL4M1BiXqDLrgyUltz3xIXgyPzYv7s4aau9aVnD/o Fs+9EcoNaNE211uaRZTTsDVOSWWHH9bm888f6eXVInqDO5sFcIhdVU26q5WJNJur vP7GCduDC1tQEHj9uXfwpdijFBi5AQ0EX/zDiAEIAL0Lfax2Z6hLL9u0lxDgrjDf /GfXXisvq5nVzttHSMheM2Mhg+gtKudTP0AvfC4BHBnD19dp4mgjSAs+LXpnKwbH 2p529D5ykwbTfbrdRWn5qRyZYR5Qta9cil2Bd7T0MhP7voE/IDi+9ccG24SzRZ1H m7vieRb+/AneBtf99o6sjQeMxhkVBki51B4cIJWt9o3rJl3xLu8RxQ/Xc4od9pf6 K2KHBSfOsV5lVeSLxx71iG2aZ6cy+yNyokcPZki7BAyfqPGXYRyvqKALSE5DJX/W N2iLSB/mPCbq3Qx1RD6+4xXyTq7u0XhihsnIv3JF2JKmdv4YIGhWtj5fN6pSe6EA EQEAAYkBJQQYAQIADwUCX/zDiAIbDAUJA9zFAAAKCRBVxgLZXNSG/EGBB/9GEYJC SjFJ04xLOC78a5n1uuUKBo1KsPvO1WqAOVPuX7s85kt+JotChm5KOhsXI/3osqtL txJG2+AQBMTw7ERr8JH51bdxFAa3rBXxn1YAcq42w9sOnzd159FAMlo3m9ANZ8GF vLIBSNhTeNx+0KsEQYw2O1xpJHR5GW95Y+QLudqXi+enKgEdilowKDfsOvP2tJCL bn2yla6rIoTgn6e8E1T/m2KYbMUPz3KafHlnOvOSmKTf5UY4tEcm2DWF5Iwf5/h8 1tMIi+9WGVv0mgUFDp3aCZYQUIdFsm4qShdQRlqjvoQ5kHsurNdeDIdPqPFM2oM0 JK0+Q3s3UY+5lf4M =BnPe -----END PGP PUBLIC KEY BLOCK----- * 2020 $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_20 pub 2048R/D4F8A092 2020-01-16 [expires: 2021-01-31] Key fingerprint = F7D4 81D8 E19A D546 DA79 41EC C108 E10D D4F8 A092 uid CNB_KEYENC_PUB_000001_20 (TEST CNB) <hub@cnb.cz> sub 2048R/A628FC21 2020-01-16 [expires: 2021-01-31] $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_20 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBF4gJTABCACs4+Pogcqv6Rxj9IICS6VpVwpOqLTjiYe+Y8+MbmW4wO9l8uTo OsKUFsHVJBQUcrJ6/XP4hjzlu6AwdBXLHjMvAApnm2bevEA+pzewTwSzYw58W5be M0XFuBYncY/vNlL7CXtKgWHax2f7YLljRTY56EV/Z8SM8BoCbxGA7KSylTMj9P23 OmYKLBgKMNjxB6MpTDtvrQfURqK1wP2QHoT7XYxy5eegfHjInywliVmx5PiBZrVy CHA4w8vyTtL5KYIGgGbGyEk6Mc+P1SqMD5FIT6JTMY9etRq77l2Pq6jms//gulVt CjrNC+67rgXsss6Nthe+od9kJjXEckBqVsSvABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8yMCAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXiAl MAIbAwUJAfZLgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMEI4Q3U+KCS e0YH/3cb75o3sn02Cs1glOPQxwnONDFe6FTQGn8CiOabX6KzMSe36ivE1MReJ/E4 qJtqs125JZju3Ol5SbwGMvR5+4YitCcavbPfnp3s7EuHGmYNe6tcuJPDHN/1zRpW /XykImb5NF8NGfZaFa+mswqL7UQ5+OrEGDFJgCPtMacciQSjeJ0DGNDY6g8T1WD+ mkJZYQeoA1LZZbka/3R6WjiNO7TPWVm0t+k1vTT+vASbzKRU4TYaGJ8hf+BHmQ7J o35+iLopmhYnyjxVLEn5oTp/SVVjcjuuztwQeuxRRSef9fIEikRwnDNNqkxwS28U V55wHetCUV7JKCdBPvlENSnYemi5AQ0EXiAlMAEIAM5OaDGByu8/t/6oV7R/qJ/Z FApc3n43L2jHMrC5pv9Ab4kzWpUZq32AILOZljR2tMl3hx3F7LO0UqaQ9VhMzDSn HQ4TUyod0XOXOEQK61/9P0E7J5HMAyWfSXwYztoukzA/Sc9ls1Ni8ClJiNQv/0de GSxIlYV0Slt9AOT7G1qavXa3daDeT4kWBHdQRV+9/7rzutHv/J9yXe2cYSqT3rIO MWXox4UY68V/edSn5Ew7wQNMFIRqzzNrQvLZbmH9MCsU7lfBXi5xjVJ2IT5rAdXW VBCc4FsTgZsos3F8sucDCkvWc3E/hieWL8vR6j86Kg60YLE3IxubBW58GAx6XL0A EQEAAYkBJQQYAQIADwUCXiAlMAIbDAUJAfZLgAAKCRDBCOEN1PigkmqLB/wIcvpI ZzXcKLe9UWH4Iu98mer42wQWzAbe1TExgjg+YMdWYGnTRYOxFu0/TP0ynXxmZBFs mtFObd1b56x0LaVKifNbqUIOQqTbzqx/P1M1ls/+5EqZyv5Upp3dKMnzXMGilJRJ hVC53GiDvTBFALsnRppgKzaaTHPiy8hyRbyDTRjiLxJC+qoWqHRhqYf1Rcih7HRv 1ZEJcFn9kYDL3PZnS/koI5olkp9CDq36E1z47gRH1woBXBsaCiWi6Sw62m9KHT4g WKgggGl9ALoWMc9Dcf7gMA94Su1+ia0dP02dfvRIDq97DpArtYlLm4Tb9vOFXWis eSEz/lLNRgAjYQuL =8FH7 -----END PGP PUBLIC KEY BLOCK----- * 2019 $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_19 pub 2048R/91BB95D9 2019-01-09 [expires: 2020-01-31] Key fingerprint = 80E4 D158 D249 CA95 992D D43E 9FD2 2EE3 91BB 95D9 uid CNB_KEYENC_PUB_000001_19 (TEST CNB) <hub@cnb.cz> sub 2048R/C0C2B713 2019-01-09 [expires: 2020-01-31] $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_19 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBFw1uy0BCAC4J4cHwtP0uyTqUIIZa/mKtYj6eptIBJ7eDx7NZT/F7ayzrXWK JZAuU2uBN/LGrAMq0DinUq2RM2k++unobiCAjxXgatpo3dSI8J4EZGZqXihGLs3o OiW23ZQZIdWvdyGlZvO//LiHKPdsGURJe93pCbxbuAEhn3NAJmxuPCtcCccOAJYE FtiKrKLd3vpVsnMnsToYw1orFLlH6Y7t007I82Z0KSd57nxu0o9W36ZgvbsxbOhK F5dY2sqG8SWn+OrX7NncgicT7QZI96r5I5ScRxNv2lGfHH5z8VetLGgLdJB5vM2m yF+I6A/7ZKInQfJ0RQw3a1kt6WExc+Mp2mtxABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8xOSAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXDW7 LQIbAwUJAf40gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJ/SLuORu5XZ xTYH/0UgGBLQ4ClsHO6J5jcqW4BKbbZinrJ35rlqCElil4NTFMy4RPSCKD4gP7k7 YntlQliSdWx/2qXAIymhTC1pTco6Gg5HVkJTrrT2+wLbWtcxyajHj3+fG9Rd99C1 k5ViVLkM3k4WduMRmUW0JCE3PHnGGpwN4MfNdmA18fsVvmdg3pRa7jSWcW5wZ3xL F/k2pLKUBvPiwrtzCURIgfWVgngbUkn0Ld4z82jOOrxscxB2yaeT/lpU2qeWhYIQ xuGsGQvfBLGN7LP5OsunbgN4d5pgI7eTjallUr+pwlzV2veUBFIoGmte/BVwW/9h 4TGkAPuOdGo1kBNgwac6mTZ1ejG5AQ0EXDW7LQEIAOCovSJDhi19JuquWcMkDFi6 KUyMgqsUPDheLKm0TTZ2htyTCSRx40x1lXfi4WpmXg64mgvn0Uv3wGYkPjaD4zty zlGXzreqPPItV+90EPfHAuPMMLrFteItUA8+UgJrc6HX6OHtOqupNRMdbe6ebAGI NDBcH95pygcnwyBA+atMHU7mjRUzWUouCB1wBgpLIfimPXoKjC3n/zjhG/4PTeBx 1bdEfke3zcZAdh1PdpOX9L6L95OeZEaRZ2XleWaUbVBh8beYoVE2GKURkM0AF4C1 VaO7uj/tUHJUPvMIwfhJgq/1H+jbB5TvbYCMfTMmqm1PLO2vDCUg6hoK/VttqFsA EQEAAYkBJQQYAQIADwUCXDW7LQIbDAUJAf40gAAKCRCf0i7jkbuV2bCuCACIK7eg rgdKaHIeiy77GV/dys5+dPEVc6wmx1U8g4OKJUEpq9k6fMucwGevhiyQD04Kg3DK 1ILr056/AwH1MAleV7uWbw44ACCJUTYereQ3DtSkQYq0NruQvVEomoXKCrcBtlfv 1tZxuoY4dfMofU+zdkZ76gIJMYeVPBAiy9Y6Dyi5hAGCBaynSoOWvzF6J0TeKDI+ BFfaC/SzzH1uo7kWMHle+vfNq806gGCTMO46emAgs/7faiL0gC2eU3FIopo8JlFc 4lsCagqppmTcuvjvOB3iwLibEFJq7dKUQCScrQA5LxdEvHD/kWqYHaLQ3kLEzLba VCNdvQcvwp2QvrCl =ItaM -----END PGP PUBLIC KEY BLOCK----- * 2018 $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \ > CNB_KEYENC_PUB_000001_18 pub 2048R/7BC65C25 2017-11-05 [expires: 2019-01-31] Key fingerprint = E7AB EE78 0A71 B510 9AB4 CE6D 125D DDAE 7BC6 5C25 uid CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz> sub 2048R/EC0B70CB 2017-11-05 [expires: 2019-01-31] $ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \ > --export CNB_KEYENC_PUB_000001_18 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.14 (GNU/Linux) mQENBFn/fGIBCADACyoW2/zFd97aUIzk7M41dxjbYUbehKnljRY5m6B4fRVAd+aQ OukF41ENPi33b1YxU7kxMtvZp945a6qojxVSCeFFUG/oN3Kpm1wMkJhC8D2PRTqc aZHA4lF8TBkD58Qhmp2N7+pVgVBS9f9OQZEvrN/2Pl1oy3YQtLa1V6m4ITO5ArCf EDDH5zVr1AjvKcIDNi2qzIqSF901N1s/7b8+xLT+C2bxBdFgkWcdsZEPQnapgFR1 hGBTGT+QtpLiHV/bEKS64/ytnhjMOzR3oW3KwO4f0W5f0kihA3gI1xc8O+dfn3X/ TkVMFXtpUI/xFD/wkZtKwlWOZMawPaQdfZJTABEBAAG0MENOQl9LRVlFTkNfUFVC XzAwMDAwMV8xOCAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPgQTAQIAKAUCWf98 YgIbAwUJAlPmAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQEl3drnvGXCVp Jwf8DzAb5BQ28d0pwfPdYSJTd4av9Fd+XeYd0XfSA+QTrG6xXhOC3820ophPVq5Z fBS7k0RmaYIFTiogC91N+Ymabmj6qgc/OjmTK74RYnviTiRLeE7iXlbjdZ39IonJ URWdwcR/uL9bwOTUUh3CmZYaZ+HU5VC0hbb/qq8NbbQCtk3UPCw38XyUePCDrzHY jcu7p0Qb91EjCwVBaoQjYPeJIc1lEfcsf19R6ClFsvgSQlldQLV8NeqKv/sW9fV9 TP1SojjQCHL0bFsRC36NeeRNBbPWaWL0K2dp+5sQgTryZ636kSABPV9CKlMfz+RY M4XboceE3f3Y2MsxupkBfeFDlrkBDQRZ/3xiAQgAtVptFY+ug22nBdHkNl145Yxw ktIFsUgT0ApDi7zKolJU7Ef3DcnxuPcWgiTBHT2XUiKc52UG9Dl/Ls+LNZIn7snM jhDiip7Mb7FjxbD12HZktcfJMBs732bFXwDnZ0NAD4zFUyaolFOeAPToPf/kBaN2 t0if0dMFkTX+SARoTpyWBaV36RkaZSKU2AkZPncmdGaDCxQPothxuwGsIwonMjO3 uE/dxqkjCrF4DD8CzJJjAseZo/EGGjN4QWuUAH/vTqiqR6GdZPF53BRPNppTdzkF vyU3zrKOh18sI9ISscu/GcqBfi+2NphccejdhXr0Od0dhxfLUU1UV/9ZNakN0wAR AQABiQElBBgBAgAPBQJZ/3xiAhsMBQkCU+YAAAoJEBJd3a57xlwl5bgH/1QT0YwJ sf+C5cnJBw4ROz/fbExXDYurSnWnRIMcbL6IxqePPn1yItnhKZZYDVjv+5cBW5pP bQGVRqMVw8Ikh0PUba5J39IMcQKfr9/Mowo0DyqsszQXfqYd9adW5bqEUsgCg2Lf gMRTXfpJBm+qSlGJVAWDnT3Sac8TyQIcURm/WVcRlAlpcXzP+Vl6M7flHgbrMrbO lJPsXif7N74L4kGXMlIR+35nQf56y3RVhZuVwcQU/1WvNVqAGXtAz04b5Lfu5vGw BVGacbnk2Iv3w5WxZ1ryYOd5C9YDTnBzw0SI3PuxwTOg92gJVwT1+hgqLBdw5rax iPZpNGDOH9BsfJM= =yRYI -----END PGP PUBLIC KEY BLOCK----- 3. IPv4 adresy/hostname a TCP porty podle prostředí: o produkční: hub.cnb.cz(193.84.159.117):6710 o testovací: hub-t.cnb.cz(193.84.159.118):6710 4. Signatury SSH veřejných klíčů serveru: o uzel 0: * 256 MD5:6e:07:41:73:91:b8:b9:e8:54:8a:5e:65:29:e0:33:d6 (ECDSA) * 256 MD5:15:b3:8a:4f:88:f9:cf:28:34:bc:c2:7f:35:a1:61:0c (ED25519) * 2048 MD5:60:8c:6e:2c:ae:d2:fe:ee:8e:7b:ff:5d:48:ab:09:13 (RSA) o uzel 1: * 256 MD5:3a:03:79:02:4e:72:f0:60:b5:50:46:a3:71:44:9d:1c (ECDSA) * 256 MD5:ab:a6:1a:3e:a2:9b:eb:c1:f9:da:45:b7:3a:a3:cf:ad (ED25519) * 2048 MD5:9b:fa:ae:89:f6:ac:f6:ad:75:fd:3c:18:f2:c7:ef:97 (RSA) Dodatek B. Formáty, rozsahy a limity 1. Formát časové značky (POSIX): %Y%m%d%H%M%S. Například datum a čas "5. října 2017 12:34:56" budou zapsány takto: 20171005123456. 2. URC je technicky trojmístné hexadecimální číslo. Může nabývat 4096 různých hodnot, z toho rozsahy "000" až "A00" a "FF0" až "FFF" jsou reservovány pro správu. Zbývající hodnoty v rozsahu "A01" až "FEF" jsou k dispozici pro klienty. 3. Maximální velikost souboru na SFTP serveru je stanovena na 50MB. 4. Kvóta klientského účtu je stanovena na 10GB. Dodatek C. Dodatečné ověření identity {přechodné} Tento dodatek popisuje dodatečné ověření identity klienta správou. Tento postup je předepsán pro klienty, kteří zasílají data dle kapitoly 3.1 prostřednictvím SDNS a zároveň chtějí zpětně odbírat datové soubory z těchto dat sestavené, a to ve formátu dle specifikace uvedené v kapitole 3.1. Poznámka: Požadavek na získávání dat ze serveru je zásadně odlišný od původního záměru, kdy klient zabezpečené datové soubory na svůj účet ukládal sám a měl tak nad jejich obsahem výhradní kontrolu. Nově je požadováno poskytnout klientovi datový soubor, jehož obsah nebyl pořízen klientem serveru. Proto je třeba ověřit, že klient je oprávněn k takovým datům přistupovat. Předpokladem pro zahájení dodatečného ověření identity klienta je úspěšné získání přístupu k serveru (viz kapitola 1). 1. Klient oznámí správě záměr využívat možnost zpětného odběru datových souborů. Forma oznámení není stanovena. 2. Správa předá věcně příslušnému správci sběru (dále VS) LEI zájemce. 3. VS vyzve zájemce prostřednictvím jiného kontaktu k předání signatur CPoK všech klíčů, které chce klient ověřit. Typicky jde o aktuální CPoK do testovacího a produkčního prostředí. 4. Dodané signatury předá VS správě serveru, která zajistí jejich ověření a o výsledku informuje VS. 5. Pro účty používající ověřené signatury správa nastaví automatický zpětný odběr souborů.