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=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> <ns1:getprice soapenv:encodingstyle=" 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= " </ds:transform> <ds:transform Algorithm= " </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" </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=" </ds:canonicalizationmethod> <ds:signaturemethod Algorithm=" </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=" <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(" 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( " if(nodes.getlength() == 0) { // Přidání elementu hlavičky SOAP headerelement = doc.createelementns( " nodes = doc.getelementsbytagnamens( " 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(" 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=" xmlns=...>... </EncryptedData> </A> Obrázek 1: Zašifrování elementu <A> <B> <EncryptedData Type=" 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