Česká národní banka (ČNB) Jaroslav Zatloukal
Verze: 0.9.20190109 Č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í:
* 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)
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í:
* 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)
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ů.