Integrovaný informační systém Státní pokladny (IISSP) Dokumentace API - integrační dokumentace

Podobné dokumenty
Integrovaný informační systém Státní pokladny (IISSP)

A. Datové prvky a jejich struktura Identifikátory Identifikace ÚJ Identifikace ZO Identifikace CSÚIS Záhlaví...

Elektronická komunikace s CSÚIS. Jak to řeší Fenix

Integrovaný informační systém Státní pokladny (IISSP) Dokumentace koncového uživatele (uživatelská dokumentace) Šifrovací utilita pro účetní jednotky

Integrovaný informační systém státní pokladny. Ministerstvo financí. Integrovaný informační systém Státní pokladny

Integrovaný informační systém Státní pokladny (IISSP)

Vybrané technické informace pro předávání účetních záznamů do centrálního systému účetních informací státu

Integrovaný informační systém Státní pokladny (IISSP) Dokumentace koncového uživatele (uživatelská dokumentace) Šifrovací utilita pro účetní jednotky

Lesk a bída elektronické fakturace Pavel Vondruška

Integrovaný informační systém Státní pokladny (IISSP)

Technický manuál Centrálního systému účetních informací státu

Zabezpečená middleware komunikace

Integrovaný informační systém Státní pokladny (IISSP)

Matematické základy šifrování a kódování

Java a XML. 10/26/09 1/7 Java a XML

Integrovaný informační systém Státní pokladny (IISSP)

Integrovaný informační systém Státní pokladny (IISSP)

Data v počítači. Informační data. Logické hodnoty. Znakové hodnoty

INFORMACE pro zabezpečení zpracování dat a sumarizací dat a výkazů v roce

Kódy a kódování dat. Binární (dvojkové) kódy. Kód Aikenův

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007

OpenSSL a certifikáty

Seminář Účetní konsolidace státu Pomocný konsolidační přehled. Ministerstvo financí

Postup ukládání výkazů do CSÚIS

Od Enigmy k PKI. principy moderní kryptografie T-SEC4 / L3. Tomáš Herout Cisco. Praha, hotel Clarion dubna 2013.

KRY. Projekt č. 2. Kamil Dudka xdudka00

Co je Czech Point? Podací Ověřovací Informační Národní Terminál, zredukovat přílišnou byrokracii ve vztahu

Hammingovy kódy. dekódování H.kódů. konstrukce. šifrování. Fanova rovina charakteristický vektor. princip generující a prověrková matice

Návrh technických pravidel pro tvorbu SIP

ECR brána - rozhraní ECR obálka 2.0

Digitální podepisování pomocí asymetrické kryptografie

Návrh funkcí webových služeb (WS) pro komunikaci mezi Informačním systémem datových schránek (ISDS) a spisovými službami (SS)

EXTRAKT z mezinárodní normy

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz

ALIS-ÚIS Program pro komfortní komunikaci s CSÚIS

Integrovaný informační systém Státní pokladny (IISSP)

PA159 - Bezpečnostní aspekty

Profilová část maturitní zkoušky 2013/2014

Šifrová ochrana informací věk počítačů PS5-2

Teorie informace a kódování (KMI/TIK) Reed-Mullerovy kódy

SSL Secure Sockets Layer

Kódování signálu. Problémy při návrhu linkové úrovně. Úvod do počítačových sítí. Linková úroveň


12. Bezpečnost počítačových sítí

Verze dokumentu 0.1 duben 2016

Informatika / bezpečnost

Sada 1 - Základy programování

Požadavky pro výběrová řízení TerraBus ESB/G2x

Profilová část maturitní zkoušky 2017/2018

Andrew Kozlík KA MFF UK

I.CA RemoteSeal. Ing. Filip Michl První certifikační autorita, a.s

Fenix. Účetnictví státu - Přenosy. Asseco Solutions, a.s. Uživatelská příručka. verze 6.81

Informatika Ochrana dat

Ministerstvo financí ČR, Krajský úřad Olomouckého kraje

Kryptoanalýza. Kamil Malinka Fakulta informačních technologií. Kryptografie a informační bezpečnost, Kamil Malinka 2008

Analýza síťového provozu. Ing. Dominik Breitenbacher Mgr. Radim Janča

Popis egon služby. E165 - robvydejdat. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

MINIMÁLNÍ POŽADAVKY NA KRYPTOGRAFICKÉ ALGORITMY. doporučení v oblasti kryptografických prostředků

CO JE KRYPTOGRAFIE Šifrovací algoritmy Kódovací algoritmus Prolomení algoritmu

Integrovaný informační systém Státní pokladny (IISSP)

Šifrová ochrana informací věk počítačů PS5-1

kryptosystémy obecně další zajímavé substituční šifry klíčové hospodářství kryptografická pravidla Hillova šifra Vernamova šifra Knižní šifra

Šifrová ochrana informací věk počítačů PS5-2

Náhled testu. Přijímací zkouška magisterského studia. konečný automat bez zbytečných stavů, který přijímá jazyk popsaný tímto výrazem, má:

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services

ECR BRÁNA - ROZHRANÍ ECR OBÁLKA 2.0. Verze dokumentu: 1.1 Datum vzniku: Počet stran: 16

Asymetrické šifry. Pavla Henzlová FJFI ČVUT v Praze. Pavla Henzlová (FJFI ČVUT v Praze) Asymetrické šifry 28.3.

VYHLÁŠKA. 3 Účinnost. Tato vyhláška nabývá účinnosti dnem 1. prosince 2016.

ERP-001, verze 2_10, platnost od

Náhled testu. Přijímací zkouška magisterského studia. konečný automat bez zbytečných stavů, který přijímá jazyk popsaný tímto výrazem, má:

Centrum pošty informace pro integrované aplikace

Projekt 2 - Nejčastější chyby. Ing. Dominik Breitenbacher

POPIS STANDARDU CEN TC278/WG4. 1 z 5. Oblast: TTI. Zkrácený název: Zprávy přes CN 4. Norma číslo:

Vysoké učení technické v Brně Fakulta informačních technologií ITP Technika personálních počítačů Služby ROM BIOS a BootROM

8. RSA, kryptografie s veřejným klíčem. doc. Ing. Róbert Lórencz, CSc.

Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/ Digitální podpisy

Bezpečnostní rozhraní UN/EDIFACT

1 Webový server, instalace PHP a MySQL 13

Hardwarové bezpečnostní moduly API a útoky

Dokumentace k nevizuálnímu rozhraní aplikace DopisOnline

MANUÁL Šifrovaná komunikace PGP MS Outlook

DSY-6. Přenosový kanál kódy pro zabezpečení dat Základy šifrování, autentizace Digitální podpis Základy měření kvality přenosu signálu

Identifikátor materiálu: ICT-2-04

[1] samoopravné kódy: terminologie, princip

KRYPTOGRAFIE VER EJNE HO KLI Č E

VYHLÁŠKA ze dne 23. června 2009 o stanovení podrobností užívání a provozování informačního systému datových schránek

Popis egon služby. E04 - robautentizace. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

PV157 Autentizace a řízení přístupu

Proudové šifry a posuvné registry s lineární zpětnou vazbou

Složitost a moderní kryptografie

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP TCP/IP.

Operační mody blokových šifer a hašovací algoritmy. šifer. Bloková šifra. šifer. Útoky na operační modus ECB

Kódování a Šifrování. Iveta Nastoupilová

Podpora XML v.net. Podpora XML v.net. nezávislý publicista. Jirka Kosek.

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

Požadavky kladené na ekonomické informační systémy související se sběrem údajů dle zákona č. 25/2017 Sb.

Kryptografie a počítačová bezpečnost

Adobe Inteligentní elektronické dokumenty a jejich uplatnění v práci úřadu

xrays optimalizační nástroj

Transkript:

Česká republika Vlastník: Logica Czech Republic s.r.o. Page 1 of 10

Česká republika Obsah 1. Úvod...3 2. Východiska a postupy...4 2.1 Způsob dešifrování a ověření sady přístupových údajů...4 2.2 Způsob přípravy zprávy k odeslání...4 2.2.1 Tvorba identifikátoru celistvosti...4 2.2.2 Šifrování dat pro přenos...5 2.3 Způsob zpracování přijaté zprávy...6 2.3.1 Dešifrování zprávy...6 2.3.2 Ověření identifikátoru celistvosti...7 3. Technický popis funkčních procesů...8 3.1 Dekódování osobních přístupových údajů...8 3.2 Příprava dat v XML formátu před odesláním do CSÚIS...9 3.3 Dešifrování dat přijatých z CSÚIS...9 Vlastník: Logica Czech Republic s.r.o. Page 2 of 10

Česká republika 1. Úvod Následující dokument prezentuje popis API šifrovací utility, která umožňuje realizaci procesů: dekódování osobních přístupových kódů, přípravu dat k odeslání zpracování přijatých dat. V dokumentu je popsán technický popis funkčních procesů v jazyce Java. Pro generování a verifikaci XML elektronického podpisu je využito knihovny Apache XML Security ve verzi 1.4.3. Pro transformaci XML zpráv a jako SAX Parser je využito Apache Xalan (ve verzi 2.7.1) a Apache Xerces-J (ve verzi 2.9.0). Vzhledem k tomu, že je použito silné kryptografie (AES s klíčem délky 256 bitů), je nutné použít Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files (ke stažení na stránkách výrobce JRE). Šifrovací utilita je distribuována formou Java Webstart aplikace, pro tvorbu grafického rozhraní bylo použito frameworku JGoodies (forms a looks). Součástí dokumentu je také popis východisek pro tvorbu osobních přístupových kódů, přípravu a zpracování dat (dle vyhlášky č. 383/2009 Sb.), který je součástí kapitoly 2. Vlastník: Logica Czech Republic s.r.o. Page 3 of 10

Česká republika 2. Východiska a postupy 2.1 Způsob dešifrování a ověření sady přístupových údajů V následujícím popisu jsou používány tyto operace: - zřetězení dvou polí znaků C_DecryptECB provedení dešifrování algoritmem AES v ECB módu Base64 kódování binárních dat v textové formě HexString hexadecimální řetězec Decode_Base64 převede data z kódování Base64 do binárního tvaru StrBytes textový řetězec v kódování ASCII převede do binárního tvaru DigestSHA256 kontrolní součet vytvořený pomocí algoritmu SHA-256 padding doplněk zprávy, tak aby délka zprávy byla celistvým násobkem 512 bitů removepadding odstraní zarovnání na šířku šifrovacího bloku decode osobní dekódovací kód v binárním tvaru Algoritmy a výstupy (všechny výstupy mají formu ASCII řetězce): 1. Dešifrování přístupových údajů [out] passcomm = removepadding(c_decryptecb(decode_base64(pacccommenc), decode)) [out] aeskey = C_DecryptECB(Decode_Base64(aesKeyEnc), decode) [out] logincomm = removepadding(c_decryptecb(decode_base64(logincommenc), decode)) 2. Ověření integrity sady přístupových údajů [out] confirmhash = HexString(DigestSHA256(StrBytes (ujeid) StrBytes(datnar) StrBytes(jmezo) StrBytes(prizo) Base64(aesKey) StrBytes (logincommopen) StrBytes (passcommopen) padding())) 2.2 Způsob přípravy zprávy k odeslání Postup přípravy zprávy je následující: 1. ÚJ nebo CSUIS připraví datový obsah zprávy ve formě XML dat. Tato data obsahují logické části: hlavička, tělo, patička realizované konkrétními elementy (viz XSD schéma pro přenos dat). V takto připravených datech nejsou vloženy žádné bezpečnostní atributy související s přenosem dat. 2. ÚJ nebo CSUIS vytvoří identifikátor celistvosti, který bude vložen do patičky XML dokumentu vytvořeného v bodě 1. Tvorba identifikátoru celistvosti je popsána v kapitole 2.2.1 3. ÚJ nebo CSUIS provedou zašifrování dat pro přenos postupem uvedeným v kapitole 2.2.2 2.2.1 Tvorba identifikátoru celistvosti Vzhledem k tomu, že identifikátor celistvosti má prokazovat, že data nebyla přenosem změněna či poškozena, je potřeba přesně definovat, z jakých dat a jakým způsobem se identifikátor vypočte. Vzhledem k povaze dat (XML) bude identifikátor celistvosti vytvořen pomocí postupů definovaných ve standardu [XMLSig11]. Identifikátor celistvosti bude vytvořen ve formě elementu Signature s využitím Vlastník: Logica Czech Republic s.r.o. Page 4 of 10

Česká republika mechanizmu HMAC-SHA256. Pro výpočet HMAC nebude použit utajený klíč a identifikátor celistvosti tak nebude sloužit k autentizaci. Jako hodnota klíče pro HMAC bude použito 32 nulových bajtů. Vložená XML signatura může vypadat například takto (použité transformace a algoritmy jsou závazné): <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="identifikator-celistvosti"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" /> <ds:signaturemethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"> <ds:hmacoutputlength>256</ds:hmacoutputlength> </ds:signaturemethod> <ds:reference URI=""> <ds:transforms> <ds:transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" /> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <ds:digestvalue>iq9zxo+eitxm5myhici3mclwpbtl6svd+3zvakh3fam=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>st8d0mddnwvlgt7jbg0xdm4gp2rr0tai5tnh/dj0gho=</ds:signaturevalue> <ds:keyinfo> <ds:keyname>kvs HMAC</ds:KeyName> </ds:keyinfo> </ds:signature> Pro tvorbu XML podpisu jsou závazné následující požadavky: Element signatury je identifikován pomoci atributu Id="identifikator-celistvosti" Element signatury je vložen jako poslední element do elementu <msg:envelopefooter> Pro zpracování se uvažuje s postupem, kdy je kořenovým elementem <msg:envelope> a signatura je vypočtena před jakýmkoli zanořením elementu <msg:envelope> do dalších XML struktur (např. SOAP) Metoda kanonikalizace v rámci signatury: http://www.w3.org/2001/10/xml-exc-c14n#withcomments Algoritmus podpisu: http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 Reference URI= celý aktuální XML dokument Transformace 1 - http://www.w3.org/2000/09/xmldsig#enveloped-signature Transformace 2 - http://www.w3.org/2001/10/xml-exc-c14n#withcomments DigestMethod http://www.w3.org/2001/04/xmlenc#sha256 2.2.2 Šifrování dat pro přenos Pro šifrování se XML dokument serializuje a vytvoří se jeho binární reprezentace. Tato binární reprezentace se šifruje dle postupu popsaného v příloze č. 6 vyhlášky. Vlastník: Logica Czech Republic s.r.o. Page 5 of 10

Česká republika Operace použité v popisu postupu: serializexml operace, která z abstraktních XML dat produkuje reálná binární data (nutno volit kódování, typ oddělení řádků, pořadí atributů apod.) {} konstantní data vyjádřená po bajtech hexadecimální hodnotou length() operace, jejímž výsledkem je délka binárních dat, která jsou parametrem % - zbytek po dělení (mod) AES_CBC(iv) mechanizmus šifrování AES v modu CBC s definovanou hodnotou iniciálního vektoru IV Encode_Base64() převede binární data do kódování Base64 C_Encrypt (mechanismus, klíč, data) provede zašifrování definovaným mechanismem a využití daného klíče Postup je následující: 1. xmldata=serializexml() 2. toencryptnnopad = RND(16) xmldata {0x0D,0x0A} 3. toencrypt = toencryptnopad RND( 16 - lenght(toencryptnopad)%16} 4. aesiv={0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00} 5. encrypted = encode_base64 (C_Encrypt(AES_CBC(aesIV), aeskey, toencrypt)) Výsledkem procesu šifrování jsou binární data zakódovaná v base64. 2.3 Způsob zpracování přijaté zprávy 2.3.1 Dešifrování zprávy Zpráva je přijata ve formě Base64 kódovaných binárních dat. Data reprezentují zašifrovanou XML zprávu. Dešifrování probíhá podle následujícího postupu, kde jsou využity následující funkce: Decode_Base64() převede data z kódování Base64 do binárního tvaru AES_CBC(iv) mechanizmus šifrování AES v modu CBC s definovanou hodnotou iniciálního vektoru IV C_Dencrypt (mechanismus, klíč, data) provede dešifrování definovaným mechanismem a využití daného klíče {} konstantní data vyjádřená po bajtech hexadecimální hodnotou stripiv() provede odříznutí prvních 16 bajtů dat strippadding() provede odříznutí bajtů doplněných na konec XML za poslední odřádkování (0x0D,0x0A) Postup je následující 1. encrypteddata=decode_base(encrypted_encoded) 2. aesiv={0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00} 3. plainwithpaddingandiv=c_decrypt(aes_cbc(aesiv), aeskey, encrypteddata) 4. plainwithpadding= stripiv(plainwithpaddingandiv) 5. plain=strippadding(plainwithpadding) Vlastník: Logica Czech Republic s.r.o. Page 6 of 10

Česká republika 2.3.2 Ověření identifikátoru celistvosti Data získaná dešifrováním jsou parsována jako stream obsahující XML. Na získaných XML datech je provedeno ověření XML-Dsig podpisu ve formě HMAC. Ověření probíhá takto: binární dešifrovaná data jsou parsována jako XML je vyhledán element <ds:signature> s Id="identifikator-celistvosti" je proveden výpočet ověření HMAC podpisu nad obsahem vybraného elementu <ds:signature> Vlastník: Logica Czech Republic s.r.o. Page 7 of 10

Česká republika 3. Technický popis funkčních procesů 3.1 Dekódování osobních přístupových údajů Vstup: Adresář s rozbalenými daty o AESKEY_C.TXT o LOGIN_C.TXT o PASSWD_C.TXT o DTRANS_PWD.TXT o PAC_PWD.TXT o UJEID.TXT o DATNAR.TXT o JMEZO.TXT o PRIZO.TXT Osobní dekódovací kód o 64-místní číslo Heslo k novému ZIP archivu (bude obsahovat dešifrované data) o Řetězec splňující podmínky pro heslo Postup (viz zdrojový kód třída com.logica.statetreasury.kvs.clienttool.util.cryptoutils metoda decodeiddata()): Validace vstupních dat - zkontrolujeme existenci potřebních souborů - zvalidujeme nově zadané heslo k ZIP archivu (viz třída com.logica.statetreasury.kvs.clienttool.util.cryptoutils metoda validatepasswords()) Dešifrování zašifrovaných souborů - načteme soubory AESKEY_C.TXT, LOGIN_C.TXT a PASSWD_C.TXT - pro dešifrování použijeme AES algoritmus (jako dešifrovací klíč použijeme osobní dekódovací kód, který ale musí být převeden do hexadecimálního tvaru třída com.logica.statetreasury.kvs.common.crypto.lutils metoda parsehex) viz zdrojový kód com.logica.statetreasury.kvs.client.crypto.kvsproviderclientsw metoda decryptidentificationdata (parametr textmode určuje, zda se jedná o textové nebo binární data v našem případě jsou LOGIN_C.TXT a PASSWD_C.TXT textové zatím co data v AESKEY_C.TXT jsou binární) Zabalení rozšifrovaných dat do ZIP archivu Vlastník: Logica Czech Republic s.r.o. Page 8 of 10

Česká republika - do zipu přibalíme k rozšifrovaným souborům (teď už s názvy AESKEY_C.DEC, LOGIN_C.DEC a PASSWD_C.DEC) i soubory DTRANS_PWD.TXT a PAC_PWD.TXT (jsou v otevřené podobě a teda není potřeba měnit jejich formát) - nastavíme k ZIP archivu heslo zadané uživatelem Vygenerování kontrolního součtu - načteme soubory UJEID.TXT,DATNAR.TXT, JMEZO.TXT a PRIZO.TXT - kontrolní součet vznikne výpočtem hash kódu zřetězených už dešifrovaných dat (AESKEY_C.DEC, LOGIN_C.DEC a PASSWD_C.DEC) a souborů načtených v předcházejícím kroku (viz třída com.logica.statetreasury.kvs.common.crypto.kvscryptoutils metoda computeconfirmationhash) Výstup: - zobrazení dešifrovaného loginu a hesla spolu s vypočteným kontrolním součtem uživateli - ZIP archiv 3.2 Příprava dat v XML formátu před odesláním do CSÚIS Vstup: XML soubor ZIP archiv obsahující AES klíč Heslo k ZIP archivu Postup (viz zdrojový kód třída com.logica.statetreasury.kvs.clienttool.util.cryptoutils metoda encodexmlfile()): Validace vstupních dat - zkontrolujeme existenci obou zadaných souborů Zašifrování XML souboru - načteme XML soubor - načteme AES klíč ze ZIP archivu (viz zdrojový kód třída com.logica.statetreasury.kvs.common.crypto.lutils metoda loadfromzip) - podepíšeme (použítý typ podpisu je HMAC signatura) a zašifrujeme XML soubor (viz zdrojový kód třída com.logica.statetreasury.kvs.common.kvsserviceshared metoda signandencrypt()) Výstup: - zašifrovaný XML soubor 3.3 Dešifrování dat přijatých z CSÚIS Vstup: Vlastník: Logica Czech Republic s.r.o. Page 9 of 10

Česká republika Zašifrovaný soubor, který uživatel obdržel z CSÚIS ZIP archiv obsahující AES klíč Heslo k ZIP archivu Postup (viz zdrojový kód třída com.logica.statetreasury.kvs.clienttool.util.cryptoutils metoda decodefile()): Validace vstupních dat - zkontrolujeme existenci obou zadaných souborů Dešifrování souboru - načteme zašifrovaný soubor - načteme AES klíč ze ZIP archivu (viz zdrojový kód třída com.logica.statetreasury.kvs.common.crypto.lutils metoda loadfromzip) - dešifrujeme soubor a ověříme HMAC signaturu zajišťující integritu šifrovaného souboru (viz zdrojový kód třída com.logica.statetreasury.kvs.common.kvsserviceshared metoda decryptandverify ()) Výstup: - zobrazení informace o průběhu dešifrování a výsledek ověření integrity uživateli - dešifrovaný soubor Vlastník: Logica Czech Republic s.r.o. Page 10 of 10