Zabezpečení webových služeb

Rozměr: px
Začít zobrazení ze stránky:

Download "Zabezpečení webových služeb"

Transkript

1 Zabezpečení webových služeb Martin Lasoň Abstrakt Webové služby jsou v současné době rychle se rozvíjející technologií. Existuje několik standardů jejichž implementace bude důležitá pro rozšíření webových služeb v komerční oblasti. V tomto článku jsou popsány specifikace, které mají umožnit zabezpečení webových služeb. Součástí textu jsou také ukázky implementace v jazyce Java. Klíčová slova: Webové služby, bezpečnost, XML Signature, XML Encryption, WS- Security, SAML, XKMS, XACML, ebxml, XML. Obsah 1 Webové služby Důvody zabezpečení Omezení SSL Řešení založená na XML XML digitální podpis Hlavní cíle Výhody Nevýhody Syntaxe Typ podepisovaných dat Algoritmy Ukázka vytvoření XML podpisu Ukázka ověření XML podpisu XML Encryption Hlavní cíle Výhody Nevýhody Syntaxe Ukázka zašifrování XML dokumentu Ukázka dešifrování XML dokumentu

2 4 WS-Security Elementy WS-Security Specifikace navazující na WS-Security Ukázka bezpečného přenosu SAML Možnosti využití SAML tvrzení Ukázka žádosti a odpovědi XKMS XML Key Information Service Specification XML Key Registration Service Specification XACML Příklad politiky kontroly přístupu ebxml Message Service 28 9 Spolupráce těchto iniciativ 28 2

3 1 Webové služby Webové služby (anglicky Web Services) jsou novou technologií vzdáleného volání funkcí v distribuovaných systémech, jako jsou RPC, CORBA nebo RMI [7]. Tato technologie je jednoduchá, nezávislá na platformě a založená na standardech W3C. Neřeší však autentizaci a bezpečnost. Technologii webových služeb tvoří tři části: protokol pro vzdálené volání procedur, zvaný SOAP, přenášející data ve formátu XML jazyk pro popis poskytovaných služeb, zvaný WSDL mechanismus pro nalezení služeb, zastoupený standardy UDDI a WSIL 1.1 Důvody zabezpečení Protokol SOAP (Simple Object Access Protocol česky jednoduchý protokol pro přístup k objektům) má formát XML dokumentu, který je přenášen protokolem HTTP. Mohou jej ale přenášet i jiné protokoly jako FTP nebo SMTP. Problémem je otevřený text protokolu SOAP. Tato vlastnost je nepřijatelná pro komerční aplikace, které přenášejí čísla kreditních karet, rodná čísla nebo čísla účtů. 1.2 Omezení SSL K zabezpečení webových služeb se nabízí použití šifrovaného protokolu SSL (Secure Socket Layer). Pro použití ve webových službách je však z následujících důvodů nevhodný: 1. SSL je navržen, aby zabezpečoval spojení typu bod bod. To nestačí pro webové služby, neboť u nich je potřeba zabezpečit komunikaci mezi koncovými účastníky mezi kterými může existovat několik uzlů. 2. SSL pracuje na transportní vrstvě a ne na úrovni zprávy. Data jsou tedy chráněna, když putují po drátě ale ne na pevném disku. 3. HTTPS v současné podobě nepodporuje nepopiratelnost. Ta je důležitá zvláště u komerčních webových služeb. 4. SSL neumožňuje podepisování a šifrování elementů v XML dokumentu. 1.3 Řešení založená na XML Bezpečnost při výměně zpráv typicky představuje autenticitu, integritu dat, nepopiratelnost a utajení. Digitální podpis zajišťuje první tři požadavky. Čtvrtý zajišťuje šifrování dat. 3

4 World Wide Web Consortium (W3C) definovalo specifikace XML Signature a XML Encryption pro zabezpečení komunikace založené na XML. Kromě toho společnosti IBM, Microsoft a VeriSign společně vytvořili doplňující specifikace jako WS-Security (Web Services Security), které jsou postaveny na těchto specifikacích W3C. Celkem bylo v průběhu posledních let vytvořeno několik bezpečnostních schémat založených na XML, aby poskytly úplné a jednotné bezpečnostní schémata pro Webové služby [15]. Tyto schémata zahrnují: XML digital signature 1 XML Encryption 2 WS-Security (Web Services Security) 3 SAML (Secure Assertion Markup Language) 4 XKMS (XML Key Management Specification) 5 XACML (Extensible Access Control Markup Language) 6 ebxml Message Service 7 V následujícím textu, budou tato schémata popsány podrobněji. 2 XML digitální podpis Stejně jako jiné technologie digitálního podpisu, také XML digitální podpis zaručuje autenticitu (kdo je autorem), integritu dat (ochranu proti falšování) a nepopiratelnost (nemožnost popřít odeslání). Ze všech bezpečnostních iniciativ pro XML je tato nejdále. Jeho využití je důležité zvláště pro komerční aplikace, kde najde uplatnění při zabezpečení ceníků, smluv a podobně. 2.1 Hlavní cíle XML podpis (anglicky XML Signature) je navržen pro případy, kdy dokument vytváří několik účastníků a každý chce podepsat jen tu část, za kterou je zodpovědný. XML podpis je vyvíjen společným úsilím World Wide Web Consortium (W3C) a Internet Engineering Task Force (IETF). Cílem této pracovní skupiny je vyvinout syntaxi jazyka XML, umožňující reprezentaci podpisů Webových zdrojů a části protokolových zpráv 1 W3C Recommendation 2 W3C Recommendation 3 OASIS Committee Draft 4 OASIS Standard 5 W3C Working Draft 6 OASIS Standard 7 OASIS Standard 4

5 (cokoli co lze adresovat pomocí URI). Dále definuje procedury pro počítání a ověřování takovýchto podpisů [19]. Zabývá se také tak zvanou kanonizací dokumentů, tj. převedením do syntakticky ekvivalentní formy (například vypouštění počátečních mezer). XML podpisy jsou digitální podpisy navržené pro použití v XML transakcích. Standard definuje schéma pro popsání výsledku operace digitálního podpisu provedené na libovolných (často XML) datech. Stejně jako digitální podpisy, které nejsou ve formátu XML (např. PKCS), obohacují XML podpisy podepisovaná data o autenticitu, integritu dat a nepopiratelnost. Na rozdíl od jiných standardů digitálního podpisu byl XML podpis navržen tak, aby mohl být využit v Internetu a v XML. Výsledný podpis může být zakotven v dokumentu nebo přiložen zvlášť. 2.2 Výhody Hlavní výhodou XML podpisů je schopnost podepsat jen určitou část XML stromu místo celého dokumentu. To může být důležité v případě, kdy jeden XML dokument má dlouhou historii a různé části vytvářely různé strany a každá podepisuje jen ty elementy, za které je zodpovědná. Tato flexibilita je zvláště výhodná v případě, kdy je důležité zajistit integritu jisté části dokumentu, který je ponechán otevřený pro případné změny. Příkladem může být XML formulář, kde by podpis přes celý formulář neumožňoval změnit položky aniž by došlo k zneplatnění podpisu. 2.3 Nevýhody XML podpis (podle RFC 3075) zaručuje integritu, autenticitu zprávy a/nebo služby autentizující podepsaného pro jakýkoli datový typ umístěný v podepsaném XML nebo kdekoli jinde. Hlavním cílem těchto podpisů je poskytovat základní serverové bezpečnostní služby pro Web pomocí XML. Jeho autoři však varují, aby tato práce nebyla považována za technický všelék. XML podpisy předpokládají použití Webu (pomocí URI v XML) k nalezení metod pro zakódování a dekódování. Jestliže ale podpis potřebuje zdroje ze sítě, aby mohl provést akci, kdo bude dodávat tyto zdroje? Proces XML podpisu je navržen co nejobecněji, ale právě tato obecnost je problém. Představme si například komerční softwarovou společnost, která se rozhodne, že chce poskytovat tyto autentizační služby. Dále předpokládejme, že operační systém této společnosti je široce rozšířen. Společnost přijde s novou verzí operačního systému, který obsahuje klienta využívajícího jen XML podpisy k zajištění bezpečnosti. Všechny XML kódy ukazují na servery tohoto výrobce. Autentizace pomocí tohoto klienta se stane široce používaná, protože je snadné jej nastavit jako výchozí v rozšířeném operačním systému. A tak jej výrobce zakotví do jeho oblíbeného zdarma dodávaného prohlížeče jako výchozí bezpečnostní mechanismus. A jako třešničku na dortu začne tento výrobce požadovat poplatky za každé využití jeho serverů k autentizaci tímto klientem. A najednou jsou příjmy a monopol na světě! [8] 5

6 2.4 Syntaxe XML digitální podpisy jsou reprezentovány elementem <Signature>, který má následující strukturu 8 [20]: <Signature> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference (URI=)? > (<Transforms/>)? <DigestMethod/> <DigestValue/> </Reference>)+ </SignedInfo> <SignatureValue/> (<KeyInfo/>)? (<Object ID?/>)* </Signature> Povinný element <SignedInfo> je informace, která je opravdu podepisována. Ověření podpisu (anglicky validation) se skládá ze dvou povinných částí ověření podpisu a ověření každého zdroje popsaných podrobněji v části 2.8. Algoritmus uvedený v <CanonicalizationMethod> je použit pro standardizaci elementu <SignedInfo> před tím, než je vytvořen otisk (anglicky digest). Různé datové proudy se stejnými XML informacemi, které se liší například jen mezerami, je totiž potřeba převést do jednotného tvaru, aby se předešlo problémům při ověřování. Proces vytváření podpisu je podrobněji vysvětlen na příkladě v části 2.7. <SignatureMethod> označuje algoritmus použitý pro převedení kanonizovaného elementu <SignedInfo> na hodnotu <SignatureValue>. Jedná se o kombinaci algoritmu otisku, algoritmu závislého na klíči a případně jiných algoritmech, jako je doplňování (anglicky padding). Každý element <Reference> obsahuje typ otisku a jeho výslednou vypočtenou hodnotu. Volitelné URI identifikuje podepisovaný datový objekt. Element <Transforms> pak obsahuje volitelný seznam kroků, které byly provedeny se zdrojem než byl podepsán. Může se jednat o operace jako XSLT, XPath, komprese atd. <KeyInfo> označuje klíč určený k ověření podpisu. Tento element je volitelný jednak z důvodu, že podepsaný si nemusí přát prozradit svůj klíč všem stranám, které s dokumentem pracují a nebo je tato informace aplikaci již známa a není potřeba ji proto všude uvádět. (Tento element se využívá také v XML Encryption.) Volitelný element <Object> slouží ke vkládání datových objektů v rámci elementu podpisu nebo jinam. 8 znak? znamená žádný nebo jeden výskyt, + znamená jeden nebo více výskytů a * znamená nula nebo více výskytů 6

7 Typ Algoritmus Požadavky Otisk (Digest) SHA1 Vyžadováno Kódování base64 Vyžadováno MAC HMAC-SHA1 Vyžadováno Podpis DSAwithSHA1 (DSS) Vyžadováno Podpis RSAwithSHA1 Doporučeno Standardizace Canonical XML Vyžadováno Standardizace Canonical XML with Comments Doporučeno Transformace XSLT Dobrovolné Transformace XPath Doporučeno Transformace Enveloped Signature Vyžadováno Tabulka 1: Algoritmy využívané v XML podpisu. 2.5 Typ podepisovaných dat XML podpis může podepsat jeden nebo více zdrojů různého typu. Například jeden XML podpis může zahrnovat textová data (HTML), binární data (JPG), XML data a stanovenou část XML souboru. Ověření vyžaduje, aby byl podepsaný objekt dostupný. XML podpis obvykle označuje místo podepsaného objektu. Odkaz na takovýto objekt může být adresován pomocí URI v XML podpisu být umístěn ve stejném zdroji jako XML podpis podpis je sourozenec být zakotvený v XML podpisu podpis je rodič mít svůj XML podpis zakotven v sobě podpis je syn 2.6 Algoritmy Tabulka 1 uvádí algoritmy využívané v XML digitálním podpisu. Jednotlivé algoritmy jsou identifikovány pomocí URI, které je uvedeno jako atribut elementu označujícího způsob jeho použití. Tato URI jsou uvedena v tabulce Ukázka vytvoření XML podpisu Následující příklad ukazuje postup vytvoření XML podpisu XML dokumentu vytvořený programem napsaným v jazyce Java. Tento příklad byl inspirován článkem [10]. Pro generování podpisu byly použity třídy projektu Apache XML Security [1] 9 Projekt Apache 9 Aby bylo možné s uvedenou knihovnou pracovat, je potřeba nainstalovat knihovnu Xalan (2.2.0 nebo vyšší). 7

8 Algoritmus SHA1 Base64 HMAC-SHA1 DSAwithSHA1 (DSS) RSAwithSHA1 Canonical XML XSLT XPath URI algoritmu Tabulka 2: URI algoritmů používaných v XML podpisu. XML Security je open source projekt, který implementuje specifikaci W3C XML Signature a brzy by měl podporovat také XML Encryption. Následující kroky vysvětlují postup vytvoření XML podpisu SOAP zprávy. Předpokládejme jednoduchou webovou službu zjišťující cenu akcií. Klient, který chce poslat službě dotaz na cenu akcií firmy IBM, pošle například zprávu SOAP: <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <soapenv:body> <ns1:getprice soapenv:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="urn:quote"> <symbol xsi:type="xsd:string">ibm</symbol> </ns1:getprice> </soapenv:body> </soapenv:envelope> Následující kroky se provedou, při podepisování XML dokumentu: 1. Určení zdrojů, které budou podepsány. V prvním kroku se vytvoří identifikace zdrojů pomocí URI. 2. Vypočtení otisku každého zdroje. V XML podpisu je každý adresovatelný zdroj popsán elementem <Reference> a jeho otisk je umístěn v synovském elementu <DigestValue>, jak je uvedeno na příkladě: <ds:reference URI=""> <ds:transforms> 8

9 <ds:transform Algorithm= "http://www.w3.org/2000/09/xmldsig#enveloped-signature"> </ds:transform> <ds:transform Algorithm= "http://www.w3.org/tr/2001/rec-xml-c14n #withcomments"> </ds:transform> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </ds:digestmethod> <ds:digestvalue>w1cjdtvtonxk2ntwv+uwu34ahx8=</ds:digestvalue> </ds:reference> Element <DigestMethod> určuje algoritmus, který byl použit pro výpočet otisku. 3. Shromáždění elementů Reference Elementy <Reference> jsou se svými otisky shromážděny do elementu <Signed- Info>. <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n "> </ds:canonicalizationmethod> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"> </ds:signaturemethod> <ds:reference URI="">... </ds:reference> </ds:signedinfo> Element <CanonicalizationMethod> označuje algoritmus, který byl použit ke kanonizaci elementu <SignedInfo>. Element <SignatureMethod> označuje algoritmus použitý k vytvoření hodnoty podpisu. 4. Podepsání Je vypočten otisk elementu <SignedInfo>, provedeno podepsání tohoto otisku a umístění hodnoty podpisu do elementu <SignatureValue>. <ds:signaturevalue>lew5r5vjdwydy62atx+lrkdthrtid dqklsxmftlb8tl8aebuovf3rq==</ds:signaturevalue> 9

10 5. Přidání informace o klíči Jestliže je vkládána informace o klíči, pak je to do elementu <KeyInfo>. Tyto informace pak obsahují X.509 certifikát odesilatele, který může obsahovat veřejný klíč potřebný k ověření podpisu. <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidtjccawo...oj9qwa==</ds:x509certificate> </ds:x509data> <ds:keyvalue> <ds:dsakeyvalue> <ds:p>/x9tgr11eils30qcluzk...iacc=</ds:p> <ds:q>l2bqjxujc8yykrmcouuec/byhpu=</ds:q> <ds:g>9+gghdabpd7lvktcnrhx...psso=</ds:g> <ds:y>avwau514aa1ig0qp3iin...kll4=</ds:y> </ds:dsakeyvalue> </ds:keyvalue> </ds:keyinfo> 6. Zapouzdření do elementu Signature Umístění elementů <SignedInfo>, <SignatureValue> a <KeyInfo> do elementu <Signature>. Element <Signature> pak obsahuje XML podpis. <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:signedinfo>... </ds:signedinfo> <ds:signaturevalue>lew5r5vjdwydy...uovf3rq==</ds:signaturevalue> <ds:keyinfo>... </ds:keyinfo> </ds:signature> Ukázka zdrojového kódu Nyní uvedu ukázku kódu, která pomocí Apache XML Security podepíše SOAP zprávu a vloží podpis do hlavičky zprávy, podobně jako je to definováno ve WS-Security. Dodejme, že odpověď ze serveru bude podobná zprávě s požadavkem, tj. tělo SOAP bude v kanonizovaném tvaru a digitální podpis bude v hlavičce. Vytvoření podpisu vypadá takto: // Inicializace knihovny org.apache.xml.security.init.init(); 10

11 // Nahrání zprávy SOAP s požadavkem javax.xml.parsers.documentbuilderfactory dbf = javax.xml.parsers.documentbuilderfactory.newinstance(); dbf.setnamespaceaware(true); dbf.setattribute("http://xml.org/sax/features/namespaces", Boolean.TRUE); javax.xml.parsers.documentbuilder db = dbf.newdocumentbuilder(); db.seterrorhandler(new org.apache.xml.security.utils.ignoreallerrorhandler()); org.w3c.dom.document doc = db.parse(new java.io.fileinputstream(new File("Request.xml"))); // Vyhledání hlavičky SOAP Element headerelement = null; NodeList nodes = doc.getelementsbytagnamens( "http://schemas.xmlsoap.org/soap/envelope/","header"); if(nodes.getlength() == 0) { // Přidání elementu hlavičky SOAP headerelement = doc.createelementns( "http://schemas.xmlsoap.org/soap/envelope/","header"); nodes = doc.getelementsbytagnamens( "http://schemas.xmlsoap.org/soap/envelope/","envelope"); if (nodes!= null) { Element envelopeelement = (Element)nodes.item(0); headerelement.setprefix(envelopeelement.getprefix()); envelopeelement.appendchild(headerelement); } } else { // Nalezeny elementy hlaviček SOAP headerelement = (Element)nodes.item(0); } // Vytvoření instance třídy XMLSignature XMLSignature sig = new XMLSignature(doc, "", XMLSignature.ALGO_ID_SIGNATURE_DSA); headerelement.appendchild(sig.getelement()); // Specifikace transformace Transforms transforms = new Transforms(doc); transforms.addtransform(transforms.transform_enveloped_signature); transforms.addtransform(transforms.transform_c14n_with_comments); sig.adddocument("", transforms, org.apache.xml.security.utils.constants.algo_id_digest_sha1); 11

12 // Přidání certifikátu a informací o veřejném klíči pro verifikátor X509Certificate cert = (X509Certificate) ks.getcertificate("martin"); sig.addkeyinfo(cert); sig.addkeyinfo(cert.getpublickey()); // Podepsání sig.sign(privatekey); // Uložení podepsané zprávy do souboru FileOutputStream f = new FileOutputStream(new File("SignedRequest.xml")); XMLUtils.outputDOMc14nWithComments(doc, f); f.close(); 2.8 Ukázka ověření XML podpisu K ověření XML podpisu je potřeba provést následující dva kroky: 1. Provede se ověření podpisu elementu <SignedInfo>. K tomu je potřeba přepočítat otisk elementu <SignedInfo> (algoritmem uvedeným v elementu <Signature- Method> a pomocí veřejného klíče ověřit, že hodnota elementu <SignatureValue> souhlasí s otiskem v elementu <SignedInfo>. 2. Pokud je předchozí krok úspěšný, jsou přepočítány otisky odkazů uvedených v elementu <SignedInfo> a porovnány s hodnotami otisků uvedenými v elementech <DigestValue> odpovídajícího elementu <Reference>. Ukázka zdrojového kódu Následující ukázka kódu, provede pomocí Apache XML Security ověření podpisu SOAP zprávy: org.apache.xml.security.init.init(); javax.xml.parsers.documentbuilderfactory dbf = javax.xml.parsers.documentbuilderfactory.newinstance(); dbf.setnamespaceaware(true); dbf.setattribute("http://xml.org/sax/features/namespaces", Boolean.TRUE); File f = new File("SignedRequest.xml"); javax.xml.parsers.documentbuilder db = dbf.newdocumentbuilder(); db.seterrorhandler(new org.apache.xml.security.utils.ignoreallerrorhandler()); 12

13 org.w3c.dom.document doc = db.parse(new java.io.fileinputstream(f)); Element sigelement = null; NodeList nodes = doc.getelementsbytagnamens( org.apache.xml.security.utils.constants.signaturespecns, "Signature"); if (nodes.getlength()!= 0) { // Byly nalezeny elementy Signature sigelement = (Element)nodes.item(0); XMLSignature signature = new XMLSignature(sigElement,""); KeyInfo ki = signature.getkeyinfo(); if (ki!= null) { if (ki.containsx509data()) { System.out.println("Could find a X509Data in the KeyInfo"); } X509Certificate cert = signature.getkeyinfo().getx509certificate(); } if (cert!= null) { System.out.println("The XML signature is " + (signature.checksignaturevalue(cert)? "valid (good)" : "invalid!!!!! (bad)")); } else { System.out.println("Did not find a Certificate"); PublicKey pk = signature.getkeyinfo().getpublickey(); if (pk!= null) { System.out.println("The XML signatur is " + (signature.checksignaturevalue(pk)? "valid (good)" : "invalid!!!!! (bad)")); } else { System.out.println("Did not find a public key"); } } } else { System.out.println("Did not find a KeyInfo"); } 13

14 3 XML Encryption XML dokument lze, stejně jako jakýkoli jiný dokument, celý zašifrovat například pomocí SSL nebo TSL. Jak ale vyřešit situace, kdy různé části jednoho dokumentu vyžadují odlišné zpracování? Jak kontrolovat autorizovaný přístup k různým skupinám elementů? Obchodník chce znát vaše jméno a adresu, ale nepotřebuje vědět detaily o vašem účtu o nic víc než banka o nakupovaném zboží. To vše řeší XML Encryption. 3.1 Hlavní cíle Cílem XML šifrování (anglicky XML Encryption je vyvinout proces šifrování/dešifrování digitálního obsahu (včetně XML dokumentů a jejich částí), syntaxi pro reprezentaci zašifrovaného obsahu a informaci, která umožní zamýšlenému adresátovi zprávu dešifrovat [17]. Standart také specifikuje transformaci dešifrování XML podpisu tak, aby aplikace ověřující XML podpis mohly rozličit struktury, které byly zašifrovány před podepsáním (tedy nesmí být dešifrovány) a ty, které byly zašifrovány po podepsání (a musí být dešifrovány). Stejně jako XML podpis je také šifrování koordinováno konsorciem W3C. 3.2 Výhody Standardy jako S/MIME (Secure/Multipurpose Internet Mail Extensions) a PGP (Pretty Good Privacy) zajišťují, že zprávu může přečíst jen zamýšlený adresát. Tyto standardy bohužel (stejně jako SSL/TLS) zachází s každou zprávou jako s celkem a nelze s nimi zašifrovat jen část XML dokumentu. Schopnost selektivně šifrovat je důležitá zvláště v případech, kdy dokument je vytvářen více aplikacemi nebo je prohlížen, podepisován nebo schvalován více lidmi [3]. XML Encryption může, na rozdíl od SSL, zašifrovat jen ta data, která musí být zašifrována. 3.3 Nevýhody Jednou z výhod XML dokumentu je, že hledání v něm je jasné a jednoznačné. DTD nebo schéma poskytují informace týkající se odpovídající syntaxe. Pokud je část dokumentu včetně tagů zašifrována jako celek, pak je možnost vyhledávat data odpovídající těmto tagům ztracena. Pokud jsou tagy zašifrovány samy, pak mohou být vhodným materiálem k zahájení útoku na kryptografickou metodu pomocí známého otevřeného textu [9]. 3.4 Syntaxe Při XML šifrování je šifrován buď element (obr. 1) nebo obsah elementu (obr. 2). Nelze však zašifrovat půl obsahu elementu. Po zašifrování získáme XML element nazvaný Encrypted- Data obsahující zašifrovaný text zakódovaný ve formátu Base64. To znamená, že EncryptedData nahrazuje čistý text. 14

15 <A> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns=...>... </EncryptedData> </A> Obrázek 1: Zašifrování elementu <A> <B> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns=...>... <EncryptedData> </B> </A> Obrázek 2: Zašifrování obsahu elementu Elementy XML šifrování EncryptedData a EncryptedKey jsou odvozeny z abstraktního typu EncryptedType. První je určen pro zašifrovaná data a druhý pro zašifrované klíče. Pokud dokument obsahuje element EncryptedKey, může v něm být šifrovaný dočasný klíč (anglicky session key) zašifrovaný veřejným klíčem. Element EncryptedData má následující strukturu 10 [18]: <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:keyinfo> <EncryptedKey>? <AgreementMethod>? <ds:keyname>? <ds:retrievalmethod>? <ds:*>? </ds:keyinfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData> Nejdůležitějsím elementem je CipherData, který obsahuje zašifrovaná data buď v ele- 10 znak? znamená žádný nebo jeden výskyt, + znamená jeden nebo více výskytů a * znamená nula nebo více výskytů 15

16 mentu CipherValue nebo na ně ukazuje v případě CipherReference. Ostatní elementy jsou volitelné, protože sdělují informace, které druhá strana již může znát (např. algoritmus použitý k šifrování nebo použitý šifrovací klíč). 3.5 Ukázka zašifrování XML dokumentu Následující příklad byl vytvořen na základě článku [3]. K jeho vyzkoušení je potřeba mít nainstalovánu knihovnu XML Security Suite od IBM 11. Pro samotné šifrování je potřeba: 1. element, který bude zašifrován; 2. rozhodnout, zda se bude šifrovat celý nebo jen jeho obsah; 3. šifrovací metoda (tj. jméno algoritmu a délku klíče); 4. šifrovací klíč; 5. možnost získání klíče. Zdrojový kód v jazyce Java vypadá nějak takto: //Nastavení zdroje klíčů KeyStoreKeyInfoResolver kskiresolver = new KeyStoreKeyInfoResolver(ks); kskiresolver.putaliasandpassword("merchant", "merchantpw".tochararray()); kskiresolver.putaliasandpassword("bank", "bankpw".tochararray()); // Připravení EncryptedData a vložení CipherValue CipherValue cv = new CipherValue(); CipherData cd = new CipherData(); cd.setciphervalue(cv); EncryptedData ed = new EncryptedData(); ed.setcipherdata(cd); // Zvolení algoritmu RSA v1.5 k šifrování EncryptionMethod rsa_1_5 = new EncryptionMethod(); em.setalgorithm(encryptionmethod.rsa_1_5); // Připrava KeyInfo pro obchodníka KeyInfo merchant = new KeyInfo(); KeyName kn = new KeyName(); kn.setname("merchant"); merchant.addkeyname(kn); 11 Tato knihovna nejlépe s poskykovatelem bezpečnosti (anglicky Security Provider) IBMJCE. 16

17 // Připrava KeyInfo pro banku... // Zašifrování xmlplaintext.encrypt("//item", kskiresolver, ed, EncryptedData.CONTENT, rsa_1_5, merchant); xmlplaintext.encrypt("//creditcard", kskiresolver, ed, EncryptedData.ELEMENT, rsa_1_5, bank); 3.6 Ukázka dešifrování XML dokumentu Při dešifrování je potřeba říci knihovně, který element se má dešifrovat a kde najít šifrovací klíč. V předcházejícím případě nebyly ukládány žádné inforamce o algoritmu a klíči. Zdrojový kód dešifrující minulý příklad může vypadat nějak takto: EncryptionMethod em = new EncryptionMethod(); em.setalgorithm(encryptionmethod.rsa_1_5); KeyInfo ki = new KeyInfo(); KeyName kn = new KeyName(); kn.setname("merchant"); ki.addkeyname(kn); // Dešifrování klíčem obchodníka xmlciphertext.decrypt("//item/child::*", kskiresolver, null, null, em.createelement(xmlutil.createnewdocument(), true), ki.createelement(xmlutil.createnewdocument(), true)); 4 WS-Security Bezpečnost webových služeb (anglicky Web Sevice Security) rozšiřuje zprávu SOAP tak, aby poskytovala kvalitní ochranu zajištěním integrity, utajení a autentizaci jedné zprávy [5]. WS-Security také poskytuje obecný mechanizmus umožňující spojení zpráv s bezpečnostními informacemi (anglicky security token) 12, přičemž není vyžadován žádný konkrétní typ. Navíc popisuje, jak tyto tokeny zakódovat. WS-Security sama o sobě nezajišťuje ani neposkytuje bezpečnostní řešení, ale je stavebním kamenem, který se používá s jinými protokoly a technologiemi. Využívá například specifikací XML podpisu a XML šifrování a definuje, jak vložit digitální podpis, otisk zprávy nebo zašifrovaná data do zprávy SOAP. Návrh WS-Security vznikl ve spolupráci společností IBM, Microsoft a Verisn a její spe- 12 Může se jednat například o uživatelské jméno, certifikát X.509 nebo lístek Kerbera 17

18 Prefix ds S11 S12 wsse wsu xenc Jmenný prostor wss-wssecurity-secext-1.0.xsd wss-wssecurity-utility-1.0.xsd Tabulka 3: Tabulka jmenných prostorů cifikaci definuje Organization for the Advancement of Structured Information Standards (OASIS). Následující text používá jmenné prostory uvedené v tabulce Elementy WS-Security Hlavičkový blok <wsse:security> poskytuje mechanismus pro připojení bezpečnostních informací určených zamýšlenému příjemci. Tím může být konečný adresát nebo prostředník. Proto elementy tohoto typu mohou být ve zprávě SOAP obsaženy vícekrát. Prostředník, kterým zpráva prochází, může do existujícího hlavičkového bloku <wssw:security> přidat jeden nebo více podelementů pokud jsou určeny pro jeho uzel SOAP nebo může přidat jeden nebo více hlaviček pro další cíle. Zpráva tedy může mít v hlavičce více bloků <wsse:security>, ale jen jeden z nich může vypustit atributy S11:actor nebo S12:role. Žádné dva bloky přitom nesmí mít stejnou hodnotu těchto atributů. Zpráva určená více príjemcům musí mít různé bloky <wsse:security>. Blok bez atributů S11:actor nebo S12:role může být zpracován kýmkoli, ale nesmí být odstraněn před svým konečným cílem. <S11:Envelope> <S11:Header>... <wsse:security S11:actor="..." S11:mustUnderstand="...">... </wsse:security>... </S11:Header>... </S11:Envelope> Pokud hlavička <wsse:security> obsahuje atribut mustunderstand="true", musí příjemce vygenerovat chybu SOAP, pokud neimplementuje specifikaci uvedenou ve jmenném 18

19 prostoru nebo pokud neumí interpertovat nebo zpracovat bezpečností informace (security token). Příjemce však smí ignorovat elementy nebo rozšíření v elementu <wsse:security> založené na lokální bezpečností politice. V rámci elementu <wsse:security> jsou definovány následující prvky [14]: Autentizační element <wsse:usernametoken> nese infor- Element UsernameToken. maci o přihlašovacím jméně 13. <wsse:usernametoken wsu:id="..."> <wsse:username>...</wsse:username> </wsse:usernametoken> Element BinarySecurityToken. K ukládání autentizačních informací, které jsou v jiném formátu než XML (například certifikát X.509 nebo lístek systému Kerberos) slouží element <wsse:binarysecuritytoken>. Atribut EncodingType specifikuje použité kódování (například Base64Binary). <wsse:binarysecuritytoken wsu:id=... EncodingType=... ValueType=.../> Element SecurityTokenReference. Security token obsahuje množinu údajů. Někdy se tyto autentizační data se mohou nacházet někde jinde a nemusí tak být obsažena v každé zprávě. Element <wsse:securitytokenreference> poskytuje rozšiřitelný mechanismus k získání těchto identifikačních dat. Zejména při použití XML Signature a XML Encryption se doporučuje umístit tento element do elementu <ds:keyinfo>. <wsse:securitytokenreference wsu:id="...">... </wsse:securitytokenreference> Následující výčet poskytuje seznam konkrétních odkazů seřazený podle důležitosti: Přímé odkazy odkaz na vložené tokeny pomocí URI (elementem <wsse:reference>); Identifikátory klíčů odkaz pomocí nejasné hodnoty reprezentující token (elementem <wsse:keyidentifier>); Jména klíčů odkaz na token pomocí identifikačního řetězce, což může vést k více výsledkům (nedoporučovaný element <ds:keyname>.); Vnořené odkazy vnořený token, což odporuje smyslu elementu odkazovat se jinam (element <wsse:securitytokenreference>). 13 Specifikace IBM připouští také připojení volitelného elementu Password, které se doporučuje používat jen při bezpečném přenosu. Standard OASIS však tuto volbu neobsahuje. 19

XML Signatures. Autor

XML Signatures. Autor XML Signatures Autor Martin Lasoň Abstrakt Digitální podpisy zajišťují integritu, autenticitu a nepopiratelnost dat na Webu. Takové rysy jsou zvlášť důležité pro dokumenty, které reprezentují závazky jako

Více

XML a bezpečnost. Dagmar BRECHLEROVÁ. KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz

XML a bezpečnost. Dagmar BRECHLEROVÁ. KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz XML a bezpečnost Dagmar BRECHLEROVÁ KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz INFORUM 2006: 12. konference o profesionálních informačních zdrojích Praha, 23. - 25.5. 2006 Abstrakt. Webové

Více

Zabezpečená middleware komunikace

Zabezpečená middleware komunikace České vysoké učení technické v Praze F a k u l t a e l e k t r o t e c h n i c k á Zabezpečená middleware komunikace autor: František Hlavan vedoucí práce: Ing. Jan Kubr Katedra počítačů leden 211 Cíle

Více

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

Integrovaný informační systém Státní pokladny (IISSP) Dokumentace API - integrační dokumentace Č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

Více

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

ECR brána - rozhraní ECR obálka 2.0 Zhotovil: Radek Častorál Datum vzniku: 24.11.2014 Jméno souboru: ECR brána - rozhraní ECR obálka 2.0 Počet stran: 19 Verze dokumentu Změny 1.0 Úvodní verze určená pro implementátory. 1.1 Popis ECR obálky

Více

Pokročilé Webové služby a Caché security. Š. Havlíček

Pokročilé Webové služby a Caché security. Š. Havlíček Pokročilé Webové služby a Caché security Š. Havlíček Webové služby co se tím míní? Webová služba metoda komunikace mezi dvěma elektronickými zařízeními přes internet Typicky jsou pomocí rozhraní přístupné

Více

Michaela Sluková, Lenka Ščepánková 15.5.2014

Michaela Sluková, Lenka Ščepánková 15.5.2014 ČVUT FJFI 15.5.2014 1 Úvod 2 3 4 OpenPGP Úvod Jak? Zašifrovat email lze pomocí šifrování zprávy samotné či elektronickým podpisem emailových zpráv. Proč? Zprávu nepřečte někdo jiný a nemůže být změněna,

Více

SSL Secure Sockets Layer

SSL Secure Sockets Layer SSL Secure Sockets Layer internetové aplikační protokoly jsou nezabezpečené SSL vkládá do architektury šifrující vrstvu aplikační (HTTP, IMAP,...) SSL transportní (TCP, UDP) síťová (IP) SSL poskytuje zabezpečenou

Více

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

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Asymetrická kryptografie a elektronický podpis Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Obsah cvičení Asymetrická, symetrická a hybridní kryptografie Matematické problémy, na kterých

Více

SAML a XACML jako nová cesta pro Identity management. SAML and XACML as a New Way of Identity Management

SAML a XACML jako nová cesta pro Identity management. SAML and XACML as a New Way of Identity Management SAML a XACML jako nová cesta pro Identity management SAML and XACML as a New Way of Identity Management Dagmar BRECHLEROVÁ Oddělení medicínské informatiky, Ústav informatiky AVČR, v.v.i. brechlerova@euromise.cz

Více

Další XML technologie

Další XML technologie XML teorie a praxe značkovacích jazyků (4IZ238) Jirka Kosek Poslední modifikace: $Date: 2012/05/17 18:58:55 $ Obsah Odkazy... 3 Odkazy v rámci jednoho dokumentu... 4 XLink (XML Linking Language)... 5 XLink

Více

Úvod do Web Services

Úvod do Web Services Úvod do Web Services Základy webových služeb a jejich implementace na platformě OS/2 Jarda Kačer jarda@kacer.biz Český Warpstock 2008 Brno, 20.-21.9.2008 Co je to webová služba? Část business logiky přístupná

Více

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt. C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

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

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5 Funkční specifikace ABOKWS Aplikační rozhraní elektronického bankovnictví ABO-K Verze 0.5 Přehled změn Verze Datum Změnil Popis 0.1 26.2.2013 MB Úvod, Osnova dokumentu, funkce ABOKWS 0.2 18.4.2014 MB Tabulky

Více

Webové služby a XML. Obsah přednášky. Co jsou to webové služby. Co jsou to webové služby. Webové služby a XML

Webové služby a XML. Obsah přednášky. Co jsou to webové služby. Co jsou to webové služby. Webové služby a XML Obsah přednášky Webové služby a XML Miroslav Beneš Co jsou to webové služby Architektura webových služeb SOAP SOAP a Java SOAP a PHP SOAP a C# Webové služby a XML 2 Co jsou to webové služby rozhraní k

Více

Obsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2

Obsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2 Úroveň I - Přehled Úroveň II - Principy Kapitola 1 Kapitola 2 1. Základní pojmy a souvislosti 27 1.1 Zpráva vs. dokument 27 1.2 Písemná, listinná a elektronická podoba dokumentu 27 1.3 Podpis, elektronický

Více

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

Lesk a bída elektronické fakturace Pavel Vondruška Lesk a bída elektronické fakturace Pavel Vondruška BIST GigaCon 2006 Datum: 23-24 Říjen 2006, Místo: Praha, Hotel Pyramida http://gigacon.org/cz/conferences/gigacon/bin.html Slide2 Obsah Lesk Elektronická

Více

Internet Information Services (IIS) 6.0

Internet Information Services (IIS) 6.0 Internet Information Services (IIS) 6.0 V operačním systému Windows Server 2003 je obsažena i služba IIS v 6.0. Služba IIS poskytuje jak www server tak i některé další služby (FTP, NNTP,...). Jedná se

Více

pomocí S/MIME ezprava.net s.r.o. 21. ledna 2015

pomocí S/MIME ezprava.net s.r.o. 21. ledna 2015 Lékařský email elektronická výměna dat ve zdravotnictví pomocí S/MIME ezprava.net s.r.o. 21. ledna 2015 Abstrakt Tento dokument popisuje technické požadavky nutné pro zabezpečenou výměnu dat ve zdravotnictví

Více

Zabezpečení platformy SOA. Michal Opatřil Corinex Group

Zabezpečení platformy SOA. Michal Opatřil Corinex Group Zabezpečení platformy Michal Opatřil Corinex Group Agenda Současný přístup k bezpečnosti Požadavky zákazníků CA Security Manager Architektura Klíčové vlastnosti Proč CA Security Manager CA 2 Security Manager

Více

GP webpay: Správa objednávek, Web Services

GP webpay: Správa objednávek, Web Services GP webpay: Správa objednávek, Web Services červenec 2013 OBSAH: ÚVOD... 3 ON-LINE ADMINISTRACE PROSTŘEDNICTVÍM WEB SERVICES... 3 DRUHY PODPOROVANÝCH POŽADAVKŮ... 4 Approve Reversal... 6 Deposit... 9 Deposit

Více

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

Co je Czech Point? Podací Ověřovací Informační Národní Terminál, zredukovat přílišnou byrokracii ve vztahu Czech Point Co je Czech Point? Podací Ověřovací Informační Národní Terminál, tedy Czech POINT je projektem, který by měl zredukovat přílišnou byrokracii ve vztahu občan veřejná správa. Czech POINT bude

Více

ŠIFROVÁNÍ, EL. PODPIS. Kryptografie Elektronický podpis Datové schránky

ŠIFROVÁNÍ, EL. PODPIS. Kryptografie Elektronický podpis Datové schránky ŠIFROVÁNÍ, EL. PODPIS Kryptografie Elektronický podpis Datové schránky Kryptografie Kryptografie neboli šifrování je nauka o metodách utajování smyslu zpráv převodem do podoby, která je čitelná jen se

Více

Šifrování Autentizace Bezpečnostní slabiny. Bezpečnost. Lenka Kosková Třísková, NTI TUL. 22. března 2013

Šifrování Autentizace Bezpečnostní slabiny. Bezpečnost. Lenka Kosková Třísková, NTI TUL. 22. března 2013 Šifrování Autentizace ní slabiny 22. března 2013 Šifrování Autentizace ní slabiny Technologie Symetrické vs. asymetrické šifry (dnes kombinace) HTTPS Funguje nad HTTP Šifrování s pomocí SSL nebo TLS Šifrování

Více

SPRÁVA ZÁKLADNÍCH REGISTRŮ PODMÍNKY PRO PŘIPOJENÍ AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO ISZR. verze 2.00

SPRÁVA ZÁKLADNÍCH REGISTRŮ PODMÍNKY PRO PŘIPOJENÍ AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO ISZR. verze 2.00 SPRÁVA ZÁKLADNÍCH REGISTRŮ PODMÍNKY PRO PŘIPOJENÍ ORGANIZAČNÍ SLOŽKA STÁTU AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO ISZR VÝROČNÍ ZPRÁVA verze 2.00 ZA ROK 2010 Na Vápence 14 1 www.szrcr.cz OBSAH 1. Úvod... 8

Více

7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly.

7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly. 7. Aplikační vrstva Studijní cíl Představíme si funkci aplikační vrstvy a jednotlivé protokoly. Doba nutná k nastudování 2 hodiny Aplikační vrstva Účelem aplikační vrstvy je poskytnout aplikačním procesům

Více

Programové vybavení OKsmart pro využití čipových karet

Programové vybavení OKsmart pro využití čipových karet Spojujeme software, technologie a služby Programové vybavení OKsmart pro využití čipových karet Ukázky biometrické autentizace Ing. Vítězslav Vacek vedoucí oddělení bezpečnosti a čipových karet SmartCard

Více

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce Základní princip Elektronický podpis Odesílatel podepíše otevřený text vznikne digitálně podepsaný text Příjemce ověří zda podpis patří odesílateli uvěří v pravost podpisu ověří zda podpis a text k sobě

Více

Bezpečnost v Gridech. Daniel Kouřil EGEE kurz 12. prosince 2006. Enabling Grids for E-sciencE. www.eu-egee.org

Bezpečnost v Gridech. Daniel Kouřil EGEE kurz 12. prosince 2006. Enabling Grids for E-sciencE. www.eu-egee.org Bezpečnost v Gridech Daniel Kouřil EGEE kurz 12. prosince 2006 www.eu-egee.org EGEE and glite are registered trademarks Proč bezpečnost Ochrana uživatele citlivá data ochrana výzkumu Ochrana majitele prostředků

Více

Elektronický podpis. Marek Kumpošt Kamil Malinka

Elektronický podpis. Marek Kumpošt Kamil Malinka Elektronický podpis Marek Kumpošt Kamil Malinka Související technologie kryptografie algoritmy pro podepisování dokumentů management klíčů generování klíčů, distribuce, revokace, verifikace implementace

Více

Certifikáty a jejich použití

Certifikáty a jejich použití Certifikáty a jejich použití Verze 1.0 Vydání certifikátu pro AIS Aby mohl AIS volat egon služby ISZR, musí mít povolen přístup k vnějšímu rozhraní ISZR. Přístup povoluje SZR na žádost OVM, který je správcem

Více

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

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptografie, elektronický podpis Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptologie Kryptologie věda o šifrování, dělí se: Kryptografie nauka o metodách utajování smyslu zpráv převodem do podoby,

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence

Více

Systémy jednotného přihlášení Single Sign On (SSO)

Systémy jednotného přihlášení Single Sign On (SSO) Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Systémy jednotného přihlášení Single Sign On (SSO) Bakalářská práce Autor: Pavel Novotný Informační technologie

Více

[1] ICAReNewZEP v1.2 Uživatelská příručka

[1] ICAReNewZEP v1.2 Uživatelská příručka [1] ICAReNewZEP v1.2 Uživatelská příručka 06.10.2011 [2] Obsah 1 - ÚVOD... 3 2 - POUŽITÉ ZKRATKY... 3 3 POŽADAVKY... 4 3.1 POŽADAVKY PRO SPRÁVNÝ CHOD APLIKACE... 4 3.2 POŽADAVKY NA OBNOVOVANÝ CERTIFIKÁT...

Více

dokumentaci Miloslav Špunda

dokumentaci Miloslav Špunda Možnosti elektronického podpisu ve zdravotnické dokumentaci Možnosti elektronického podpisu ve zdravotnické dokumentaci Miloslav Špunda Anotace Příspěvek se zabývá problematikou užití elektronického podpisu

Více

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace k projektu CZECH POINT Popis použití komerčního a kvalifikovaného certifikátu Vytvořeno dne: 20.5.2008 Aktualizováno: 23.5.2008 Verze: 1.3 Obsah Uživatelská dokumentace...1 Obsah...2

Více

Certifikační prováděcí směrnice

Certifikační prováděcí směrnice První certifikační autorita, a.s. Certifikační prováděcí směrnice (algoritmus RSA) Certifikační prováděcí směrnice (algoritmus RSA) je veřejným dokumentem, který je vlastnictvím společnosti První certifikační

Více

OpenSSL a certifikáty

OpenSSL a certifikáty OpenSSL a certifikáty Petr Krčmář 1. června 2013 Uvedené dílo podléhá licenci Creative Commons Uved te autora 3.0 Česko. Petr Krčmář (Root.cz) OpenSSL a certifikáty 1. června 2013 1 / 20 OpenSSL: o čem

Více

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

Elektronická komunikace s CSÚIS. Jak to řeší Fenix Elektronická komunikace s CSÚIS Jak to řeší Fenix Asseco Solutions a veřejná správa Informační systém Fenix Balík aplikací pro státní správu a samosprávu Více než 15 let zkušeností Více než 2000 instalací

Více

Model ISO - OSI. 5 až 7 - uživatelská část, 1 až 3 - síťová část

Model ISO - OSI. 5 až 7 - uživatelská část, 1 až 3 - síťová část Zatímco první čtyři vrstvy jsou poměrně exaktně definovány, zbylé tři vrstvy nemusí být striktně použity tak, jak jsou definovány podle tohoto modelu. (Příkladem, kdy nejsou v modelu použity všechny vrstvy,

Více

KVALIFIKOVANÉ CERTIFIKÁTY

KVALIFIKOVANÉ CERTIFIKÁTY Ondřej Ševeček PM Windows Server GOPAS a.s. MCM: Directory Services MVP: Enterprise Security ondrej@sevecek.com www.sevecek.com KVALIFIKOVANÉ CERTIFIKÁTY Slovníček Česky veřejný / soukromý klíč otisk podepsat

Více

Použití čipových karet v IT úřadu

Použití čipových karet v IT úřadu Použití čipových karet v IT úřadu Software pro personalizaci, správu a použití čipových karet Ing. Ivo Rosol, CSc. Ing. Pavel Rous 9. 10. 6. 2011 1 Použití bezkontaktních čipových karet Přístupové systémy

Více

Ing. Jitka Dařbujanová. E-mail, SSL, News, elektronické konference

Ing. Jitka Dařbujanová. E-mail, SSL, News, elektronické konference Ing. Jitka Dařbujanová E-mail, SSL, News, elektronické konference Elementární služba s dlouhou historií Původně určena pro přenášení pouze textových ASCII zpráv poté rozšíření MIME Pro příjem pošty potřebujete

Více

POLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE

POLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE POLOPROVOZ ZNALOSTNÍ DATABÁZE INTERPI DOKUMENTACE INTERPI Interoperabilita v paměťových institucích Program aplikovaného výzkumu a vývoje národní kulturní identity (NAKI) (DF11P01OVV023) Zpracovali: Marie

Více

CZ.1.07/1.5.00/34.0527

CZ.1.07/1.5.00/34.0527 Projekt: Příjemce: Digitální učební materiály ve škole, registrační číslo projektu CZ.1.07/1.5.00/34.0527 Střední zdravotnická škola a Vyšší odborná škola zdravotnická, Husova 3, 371 60 České Budějovice

Více

Bezpečnost dat. Možnosti ochrany - realizována na několika úrovních

Bezpečnost dat. Možnosti ochrany - realizována na několika úrovních Bezpečnost dat Možnosti ochrany - realizována na několika úrovních 1. ochrana přístupu k počítači 2. ochrana přístupu k datům 3. ochrana počítačové sítě 4. ochrana pravosti a celistvosti dat (tzv. autenticity

Více

Federativní přístup k autentizaci

Federativní přístup k autentizaci Federativní přístup k autentizaci Milan Sova * sova@cesnet.cz 1 Úvod Abstrakt: Příspěvek předkládá stručný úvod do problematiky autentizace a autorizace a seznamuje s koncepcí autentizačních federací.

Více

Dokumentace. k projektu Czech POINT. Popis použití komerčního a kvalifikovaného certifikátu

Dokumentace. k projektu Czech POINT. Popis použití komerčního a kvalifikovaného certifikátu Dokumentace k projektu Czech POINT Popis použití komerčního a kvalifikovaného certifikátu Vytvořeno dne: 11.4.2007 Aktualizováno: 19.2.2009 Verze: 3.3 2009 MVČR Obsah 1. Vysvětleme si pár pojmů...3 1.1.

Více

IDENTITY MANAGEMENT Bc. Tomáš PRŮCHA

IDENTITY MANAGEMENT Bc. Tomáš PRŮCHA IDENTITY MANAGEMENT Bc. Tomáš PRŮCHA 20. 12. 2013 ÚVOD S penetrací IT do fungování společnosti roste důraz na zabezpečení důvěrnosti a opravdovosti (autenticity) informací a potvrzení (autorizaci) přístupu

Více

Inovace bakalářského studijního oboru Aplikovaná chemie http://aplchem.upol.cz

Inovace bakalářského studijního oboru Aplikovaná chemie http://aplchem.upol.cz http://aplchem.upol.cz CZ.1.07/2.2.00/15.0247 Tento projekt je spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky. Internet a zdroje Elektronická pošta a její správa, bezpečnost

Více

Správa přístupu PS3-2

Správa přístupu PS3-2 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Správa přístupu PS3-2 1 Osnova II základní metody pro zajištění oprávněného přístupu; autentizace; autorizace; správa uživatelských účtů; srovnání současných

Více

Česká pošta, s.p. Certifikační autorita PostSignum

Česká pošta, s.p. Certifikační autorita PostSignum Česká pošta, s.p. Certifikační autorita PostSignum 6. 12. 2012 Ing. Miroslav Trávníček Služby certifikační autority Kvalifikované certifikáty komunikace s úřady státní správy Komerční certifikáty bezpečný

Více

Publikování map na webu - WMS

Publikování map na webu - WMS Semestrální práce z předmětu Kartografická polygrafie a reprografie Publikování map na webu - WMS Autor: Ondřej Dohnal, Martina Černohorská Editor: Filip Dvořáček Praha, duben 2010 Katedra mapování a kartografie

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 03.220.01, 35.240.60 materiálem o normě. Dopravní a cestovní informace (TTI) TTI ČSN P CEN předávané

Více

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

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 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 Ministerstvo vnitra stanoví podle 9 odst. 3 a 4, 20 odst. 3 a 21 zákona č. 300/2008

Více

Extrémně silné zabezpečení mobilního přístupu do sítě.

Extrémně silné zabezpečení mobilního přístupu do sítě. Extrémně silné zabezpečení mobilního přístupu do sítě. ESET Secure Authentication (ESA) poskytuje silné ověření oprávnění přístupu do firemní sítě a k jejímu obsahu. Jedná se o mobilní řešení, které používá

Více

Středoškolská technika 2015. Encryption Protection System

Středoškolská technika 2015. Encryption Protection System Středoškolská technika 2015 Setkání a prezentace prací středoškolských studentů na ČVUT Encryption Protection System Jaroslav Vondrák Vyšší odborná a Střední škola Varnsdorf Mariánská 1100, Varnsdorf 1

Více

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka Metody tvorby ontologií a sémantický web Martin Malčík, Rostislav Miarka Obsah Reprezentace znalostí Ontologie a sémantický web Tvorba ontologií Hierarchie znalostí (D.R.Tobin) Data jakékoliv znakové řetězce

Více

[ 1 ] Ing. Tomáš Melen náměstek pro informatiku a ekonomiku 2009 Státní ústav pro kontrolu léčiv

[ 1 ] Ing. Tomáš Melen náměstek pro informatiku a ekonomiku 2009 Státní ústav pro kontrolu léčiv [ 1 ] [ 2 ] Přístup pro účastníky správních řízení Přístup pro farmaceutické firmy [ 3 ] Program prezentace Cíle prezentovaného řešení Představení prezentovaného řešení Diskuse a dotazy [ 4 ] Cíle prezentovaného

Více

Uživatelská příručka

Uživatelská příručka Uživatelská příručka Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace Outlook Express. Verze: C 23.10.2007 CDS D4_Instalace_OutlookExpressSettings.doc Strana 1 z 10 OBSAH 1 Úvod a shrnutí...4

Více

POKYNY K REGISTRACI PROFILU ZADAVATELE

POKYNY K REGISTRACI PROFILU ZADAVATELE POKYNY K REGISTRACI PROFILU ZADAVATELE Stav ke dni 4. 12. 2012 Obsah: 1 Úvod... 3 1.1 Podmínky provozu... 3 1.2 Pokyny k užívání dokumentu... 3 2 Registrace profilu zadavatele... 4 2.1 Přihlášení uživatele...

Více

Bezpečnost elektronických platebních systémů

Bezpečnost elektronických platebních systémů Katedra matematiky, Fakulta jaderná a fyzikálně inženýrská, České vysoké učení technické v Praze Plán Platby kartou na terminálech/bankomaty Platby kartou na webu Internetové bankovnictví Platby kartou

Více

Alena Malovaná, MAL305

Alena Malovaná, MAL305 Alena Malovaná, MAL305 GML WFS WMF Geografický značkovací jazyk (Geographic Markup Language - GML) Jedná se o velmi rozšířený standard pro popis geodat umožňující sdílení i integraci dat. Jeho základem

Více

Práce s e-mailovými schránkami v síti Selfnet

Práce s e-mailovými schránkami v síti Selfnet Práce s e-mailovými schránkami v síti Selfnet Obsah návodu Základní informace k nastavení schránky selfnet.cz...2 Doporučené parametry nastavení e-mailového klienta...2 Základní informace k nastavení e-mailové

Více

schopni vysvětlit, co znamená protokol NFS a k čemu se používá; umět rozpoznat autorské dílo a znát autorská práva;

schopni vysvětlit, co znamená protokol NFS a k čemu se používá; umět rozpoznat autorské dílo a znát autorská práva; POKYNY KE STUDIU 1 Rozšiřující data na Internetu Pracovní materiály Doprovodné obrázky a videa na Internetu Rejstřík pojmů 7 SDÍLENÍ DAT Čas ke studiu: 1,5 hodiny Cíl: Po prostudování této kapitoly budete:

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

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

Adobe Inteligentní elektronické dokumenty a jejich uplatnění v práci úřadu Adobe Inteligentní elektronické dokumenty a jejich uplatnění v práci úřadu Vladimír Střálka Territory Account Manager 18.9.2006 1 Problém elektronického dokumentu Co je dokument? Soubor, jaký formát, co

Více

Nastavení tabletu Apple ipad

Nastavení tabletu Apple ipad Nastavení tabletu Apple ipad Tablet Apple ipad, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny. Pokud je potřeba

Více

Jazyk XSL XPath XPath XML. Jazyk XSL - rychlá transformace dokumentů. PhDr. Milan Novák, Ph.D. KIN PF JU České Budějovice. 9.

Jazyk XSL XPath XPath XML. Jazyk XSL - rychlá transformace dokumentů. PhDr. Milan Novák, Ph.D. KIN PF JU České Budějovice. 9. Jazyk XSL - rychlá transformace dokumentů 9. prosince 2010 Osnova 1 Jazyk XSL Úvod Princip zpracování pomocí stylů Formátování dokumentu pomocí XSL FO Osnova 1 Jazyk XSL Úvod Princip zpracování pomocí

Více

InternetovéTechnologie

InternetovéTechnologie 9 InternetovéTechnologie webové služby, SOA, služby, atd. Ing. Michal Radecký, Ph.D. www.cs.vsb.cz/radecky Co je to webová služba - Webová služba je softwarový systém zkonstruovaný k podpoře interakce

Více

Robert Hernady, Regional Solution Architect, Microsoft

Robert Hernady, Regional Solution Architect, Microsoft Robert Hernady, Regional Solution Architect, Microsoft Agenda prezentace Seznámení s problematikou Principy elektronického podpisu Certifikáty Co je třeba změnit pro využití algoritmů SHA-2 Shrnutí nutných

Více

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci l Kontakt s klientem SSP automatizované komunikace s ÚP ČR v součinnosti a exekuci Obsah: 1. SEZNAM POUŽITÝCH ZKRATEK... 3 2. POPIS SLUŽBY... 4 2.1 Forma a struktura rozhraní... 4 2.2 Dostupnost služby...

Více

Národní elektronický nástroj. Import profilu zadavatele do NEN

Národní elektronický nástroj. Import profilu zadavatele do NEN Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce

Více

Artlingua Translation API

Artlingua Translation API Artlingua Translation API Dokumentace Jan Šváb, Artlingua, a.s. 2015 Revize: 2015-09-22 - verze API : v1 Obsah Obsah... 2 Předávání dokumentů k překladu... 3 Implementace klientské aplikace pro Translation

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě ICS: 03.220.01; 35.240.60 CALM Základní přístupy k ochraně osobních dat z informačních

Více

Autorizovaná konverze dokumentů

Autorizovaná konverze dokumentů Autorizovaná konverze dokumentů Autorizovaná konverze Konverze z pohledu občana a úředníka CzechPOINT@office Principy konverze, centrální evidence doložek Poplatky za konverzi, digitální podpis Zkoušky

Více

Rozdělení šifer Certifikáty a jejich použití Podání žádosti o certifikát. Martin Fiala digri@dik.cvut.cz

Rozdělení šifer Certifikáty a jejich použití Podání žádosti o certifikát. Martin Fiala digri@dik.cvut.cz Certifikační autorita Rozdělení šifer Certifikáty a jejich použití Podání žádosti o certifikát Certifikační autority u nás Martin Fiala digri@dik.cvut.cz Význam šifer umožnit zakódování a pozdější dekódování

Více

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví Koordinační středisko pro resortní zdravotnické informační systémy Budějovická 15/743 140 00 Praha 4 Počet stran: 10 KSRZIS Postup kroků nutných pro napojení nemocničního informačního systému s registrem

Více

Dokumentace k nevizuálnímu rozhraní aplikace DopisOnline

Dokumentace k nevizuálnímu rozhraní aplikace DopisOnline Dokumentace k nevizuálnímu rozhraní aplikace DopisOnline Rozhraní slouží k automatizovanému podání listovních zásilek elektronickou cestou z aplikací třetích stran. Veškerá komunikace s naším serverem

Více

Technologie sémantického webu (4.11.2010) Roman Špánek

Technologie sémantického webu (4.11.2010) Roman Špánek DŮVĚRAŮ Ě A SÉMANTICKÝ WEB Technologie sémantického webu (4.11.2010) Roman Špánek Obsah 2 Úvod Sémantický web, bezpečnost a důvěra Možné přístupy Reputační č systémy Závěr Bezpečnost a budoucnost 3 Slibná

Více

Bezpečnostní aspekty informačních a komunikačních systémů KS2

Bezpečnostní aspekty informačních a komunikačních systémů KS2 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Bezpečnostní aspekty informačních a komunikačních systémů KS2 VŠFS; Aplikovaná informatika; SW systémy

Více

Směry rozvoje v oblasti ochrany informací KS - 7

Směry rozvoje v oblasti ochrany informací KS - 7 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Směry rozvoje v oblasti ochrany informací KS - 7 VŠFS; Aplikovaná informatika; SW systémy 2005/2006

Více

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

A. Datové prvky a jejich struktura... 5. Identifikátory... 6. Identifikace ÚJ... 6. Identifikace ZO... 6. Identifikace CSÚIS... 6. Záhlaví... Technický manuál (Pracovní verze k 10.12.2009) Slovník pojmů... 5 A. Datové prvky a jejich struktura... 5 Struktura komunikační obálky... 6 Identifikátory... 6 Identifikátor přenosu... 6 Identifikace ÚJ...

Více

Schéma e-pošty. UA (User Agent) rozhraní pro uživatele MTA (Message Transfer Agent) zajišťuje dopravu dopisů. disk. odesilatel. fronta dopisů SMTP

Schéma e-pošty. UA (User Agent) rozhraní pro uživatele MTA (Message Transfer Agent) zajišťuje dopravu dopisů. disk. odesilatel. fronta dopisů SMTP Elektronická pošta Schéma e-pošty odesilatel UA disk SMTP fronta dopisů disk MTA SMTP MTA adresát UA disk POP IMAP poštovní schránka disk MTA SMTP UA (User Agent) rozhraní pro uživatele MTA (Message Transfer

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

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

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP. Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Jádro TCP/IP TCP/IP Jádro Pseudo terminal driver Uživatel u terminálu TCP spojení

Více

ČESKÁ TECHNICKÁ NORMA

ČESKÁ TECHNICKÁ NORMA ČESKÁ TECHNICKÁ NORMA ICS 35.240.15 2003 Bankovnictví - Bezpečný přenos souborů (drobné obchody) ČSN ISO 15668 97 9120 Listopad Banking - Secure file transfer (retail) Banque - Transfert de fichier de

Více

Internet Banka v mobilu

Internet Banka v mobilu Internet Banka v mobilu Obsah Co je Internet Banka v mobilu?... 3 Co umí Internet Banka v mobilu?... 3 Kdo může používat Internet Banku v mobilu?... 3 Na jakých telefonech Internet Banka v mobilu funguje?...

Více

Internet, www, el. pošta, prohlížeče, služby, bezpečnost

Internet, www, el. pošta, prohlížeče, služby, bezpečnost Internet, www, el. pošta, prohlížeče, služby, bezpečnost Internet jedná se o fyzické propojení komponent nacházejících se v počítačových sítí všech rozsahů LAN, MAN, WAN. Patří sem koncové uživatelské

Více

ADIS Opt-Out rozhraní na okolní systémy. Technický popis rozhraní s pojišťovnami

ADIS Opt-Out rozhraní na okolní systémy. Technický popis rozhraní s pojišťovnami ADIS Opt-Out rozhraní na okolní systémy Technický popis rozhraní s pojišťovnami Verze: 1.4h Datum verze: 18.1.2013 Účel dokumentu: Dokument je návrhem rozhraní systému ADIS na systémy: - pojišťoven, v

Více

Elektronická pošta... 3 Historie... 3 Technické principy... 3 Komunikační protokoly... 3 MBOX... 4 Maildir... 4 Jak funguje e-mail... 5 POP3...

Elektronická pošta... 3 Historie... 3 Technické principy... 3 Komunikační protokoly... 3 MBOX... 4 Maildir... 4 Jak funguje e-mail... 5 POP3... Elektronická pošta Elektronická pošta... 3 Historie... 3 Technické principy... 3 Komunikační protokoly... 3 MBOX... 4 Maildir... 4 Jak funguje e-mail... 5 POP3... 5 IMAP... 6 Výhody a nevýhody IMAP...

Více

Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME

Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME Je dostupnou možností, jak lze zaslat lékařskou dokumentaci elektronicky. Co je třeba k odeslání šifrovaného

Více