Avointa verkkoa kuten Internetiä hyödyntävä viestinvälitys saattaa olla riskialtista tiedon monistus- ja muuntamisriskin vuoksi.

129

Avointa verkkoa kuten Internetiä hyödyntävä viestinvälitys saattaa olla riskialtista tiedon monistus- ja muuntamisriskin vuoksi. On syytä muistaa, että 100% turvallisuutta ei voida koskaan taata. Turvallisuus voidaankin ajatella ketjuna, jonka kestävyys on sama kuin sen heikoimman lenkin kestävyys. Käytännössä kyse on siitä, että tiedonsiirto on turvallista riittävän suurella todennäköisyydellä. Niinpä yritysten tulee päättää turvallisuuspolitiikasta, jota määriteltäessä tulee huomioida (ainakin) seuraavat asiat: -arvioida/määrittää mahdolliset vahingot siinä tapauksessa, että tietoturvariski realisoituu, -arvioida/määrittää itse tietoturvateknologian aiheuttamat haitat (esim. käyttömukavuus) ja -määritellä proseduurit mahdollisia tietoturvahyökkäyksiä ja niihin reagoimista varten. 130

Confidentiality: luottamuksellisuus Integrity: koskemattomuus Authentication: autentikointi Nonrepudiation: kiistämättömyys Luottamuksellisuudella tässä yhteydessä tarkoitetaan sitä, että mikään ulkopuolinen osapuoli ei pysty lukemaan tai kopioimaan viestin sisältöä. Luottamuksellisuus voidaan toteuttaa esimerkiksi käyttämällä kryptausmenetelmiä. Koskemattomuus puolestaan tarkoittaa sitä, että mikään ulkopuolinen osapuoli ei pysty muuttamaan tai manipuloimaan viestin sisältöä. Autentikointi takaa sen, että mikään ulkopuolinen osapuoli ei pysty näyttäytymään virallisena osapuolena. Ja lopuksi kiistämättömyys takaa sen, että viestin lähettäjä ei pysty kieltämään lähettäneensä viestiä. Seuraavaksi tarkastelemme näitä viestinvälityksen turvallisuusvaatimuksia hieman tarkemmin, erityisesti Web-palveluiden näkökulmasta. 131

Käyttöoikeus (access control) sekoitetaan silloin tällöin autentikointiin (authentication). Tämä on toisaalta ymmärrettävää, sillä näitä kahta tukevat mekanismit on usein integroitu yhdeksi mekanismiksi. Esimerkiksi joissain tilanteissa palvelimen salasanasuojattuja Web-sivuja pääsevät käyttämään/selaamaan vain asianmukaisilla oikeuksilla autentikoidut asiakkaat. Kyseessä eivät kuitenkaan ole synonyymit: autentikointia käytetään todistamaan kommunikointikumppanin identiteetti, kun taas käyttöoikeudet määräävät tietoturvapolitiikan (ts. asiakkaalle sallittavat operaatiot määräytyvät asiakkaan identiteetin perusteella). Web-palveluiden tapauksessa eri käyttäjille eri käyttöoikeuksin voi näkyä erilaiset rajapinnat palveluun. 132

Kryptosysteemit voivat olla symmetrisiä tai ei-symmetrisiä. Mikäli kryptausavaimen K perusteella voidaan helposti määrittää sen käänteisoperaatio D, on kyseessä symmetrinen kryptosysteemi. Käänteisoperaatiolla tarkoitetaan tässä sellaista operaatiota, jonka avulla kryptatun tiedon T (ts. K(T)) kryptaus voidaan purkaa ja näin ollen saada selville alkuperäinen tieto T. Ts., D(K(T)) = T. Mikäli taas käänteisoperaatiota ei voida helposti selvittää kryptausavaimen perusteella, on kyseessä eisymmetrinen kryptosysteemi. Ei-symmetrisen kryptosysteemin etuna on se, että kryptausavain voidaan huoletta julkaista. Needham-Schroeder Public Key Protocol määrittelee ei-symmetrisen kryptosysteemin käyttöön perustuvan kommunikaation A:nja B:n välillä seuraavasti: 1. A ->B: {NA, A} KB 2. B ->A: {NA, NB} KA 3. A->B: {NB}KB missä NA on A:n salainen sanoma, NB on B:n salainen sanoma, KA on A:n julkinen avain ja KB on B:n julkinen avain 133

Onko edellä oleva julkisiin avaimiin perustuvat identiteetin varmistus aukoton? Ts., voivatko A ja B olla varmoja toistensa henkilöllisyydestä ja voivatko he välittää turvallisesti viestejä toisilleen? 133

Kalvolla on esitetty kaksi esimerkkiä ei-symmetrisen kryptosysteemin käytöstä. Ensimmäisessä esimerkissä A:n tarkoitus on välittää informaatiota B:lle tallentaen sen julkiseen paikkaan B:n haettavaksi. Tällöin A kryptaa ko. informaation T käyttäen B:n julkista avainta. Koska vain B tietää miten kryptattu tieto puretaan, on kryptatun tiedon K B (T) tallettaminen julkiseen paikkaan mahdollista. Jälkimmäinen esimerkki koskee digitaalista allekirjoittamista. Digitaalisissa allekirjoituksissa käytetään vain allekirjoittajan tiedossa olevaa avainta (private key) allekirjoittamiseen. Sen lisäksi on olemassa joko vain tietyn luotettavan osapuolen (tai mahdollisesti useampien) tiedossa oleva avain (public key), jota käytetään digitaalisen allekirjoituksen varmistamiseen. Tässäkin tapauksessa on kyseessä ei-symmetrinen kryptosysteemi. Esimerkissä A haluaa tallettaa B:lle tarkoitetun digitaalisesti allekirjoittamansa tiedon T julkiseen paikkaan. Tällöin A kryptaa B:n julkista avainta käyttäen allekirjoittamansa tiedon ja tallettaa lopputuloksen julkiseen paikkaan. B pystyy tällöin käyttämään digitaalisen allekirjoituksen varmistamiseen käytettävää avainta käyttämällä ensin omaa avaintaan kryptauksen purkamiseen. Edellä esitetty Needham-Schroeder Public Key Protocol kommunikaatio ei ole turvallinen, sillä se ei toteuta autentikointivaatimusta. Esimerkki tästä on ns. Lowen hyökkäys (Lowe s attack), jossa oletetaan A:ksi naamioitu tunkeilija Z. Lowe osoitti, että B ei voi olla varma siitä, että viesti tulee A:lta. Huomaa myös, että protokollassa A ei eksplisiittisesti julista haluavansa kommunikoida nimenomaan B:n kanssa. Hyökkäyksessä ilkeä agentti Z huijaa rehellistä A:ta antamaan B:n salaisen sanoman NB. Tämän jälkeen ilkeä Z voikin huijata B:tä. Lowen hyökkäyksessä käytetään kaksi samanaikaista protokollaa, toinen A:n ja Z:n välillä (1) ja toinen Z:n ja B:n välillä (2). 1.1 A ->Z: {NA, A} KZ 134

2.1 Z(A) ->B: {NA, A} KB 2.2 B ->Z(A): {NA, NB} KA 1.2 Z ->A: {NA, NB} KA 1.3 A->Z: {NB}KZ 2.3 Z(A)->B: {NB}KB 134

135

Web-palveluissa turvallisuusnäkökulmat voidaan huomioida eri tasoilla (kts. kalvo 111, Layers of Web Services ). Kuljetusprotokollatasolla voidaan käyttää esimerkiksi Netscapen määrittelemää SSL:ää HTTP-yhteyden turvaamiseksi. Toisaalta SOAP-viestien turvallisuus voidaan varmentaa käyttämällä kryptausmenetelmiä ja digitaalisia allekirjoituksia. Käytännössä kaikki selaimet ja HTTP-palvelimet tukevat nykyisin SSL:ää. Transport Layer Security 1.0 (TLS), joka on IETF:n (Internet Engineering Task Force) määrittelemä, on lähes identtinen SSL versio 3 :lle. SSL:ssä luottamuksellisuus toteutetaan käyttämällä symmetristä kryptausta (esim. Data Encryption Standard (DES)). Koskemattomuus varmistetaan puolestaan käyttämällä turvallisiin hash-funktioihin perustuvaa viestin autentikointia (esim. Message Digest 5 (MD5) ja Secure Hash Algorithm 1 (SHA-1)). SSL-yhteydessä asiakaspään autentikointi on optionaalista, kun taas palvelimen autentikointi on pakollista. Tämä perustuu siihen, että asiakas tietää aina palvelimen identiteetin, mutta päinvastainen ei välttämättä päde. 136

SSL:ssä palvelimen autentikointi koostuu seuraavista askeleista: 1) Ennen kommunikoinnin aloittamista Web-palvelin hankkii kolmannelta osapuolelta (ns. certification authority) ns. digitaalisen sertifikaatin, joka sisältää mm. julkisen salausavaimen, tiedon palvelimesta jolle sertifikaatti on myönnetty sekä allekirjoituksen, joka varmistaa palvelimen pitäjän olevan se mikä se väittää olevansa. Sertifikaatti voidaan tallettaa julkiseen paikkaan. 2) Asiakassovellus ja Web-palvelin sopivat salausmenetelmän sekä SSL-version käytöstä, palvelin lähettää asiakkaalle istunnon tunnuksen (id). 3) Palvelin lähettää sertifikaatin asiakkaalle. 4) Asiakas generoi ns. premaster-avaimen (satunnaisluku), kryptaa sen käyttämällä julkista avainta K S ja lähettää sen palvelimelle. 5) Palvelin purkaa kryptauksen (yksityisellä) avaimella D S (jolloin D S (K S (premaster))=premaster). 6) Tässä vaiheessa palvelimella ja asiakkaalla on tieto yhteisestä premasterluvusta, josta muodostetaan symmetriset kryptausavaimet ko. istuntoa varten. Tämän jälkeen molemmat (asiakas ja palvelin) lähettävät vielä viestin vahvistaakseen, että ovat valmiita suojatun liikenteen aloittamiseen käyttäen sovittua symmetristä salausmenetelmää ja istuntoavainta. 137

SSL:ää käytettäessä asiakaspään autentikointi toisin kuin palvelimen autentikointi - ei siis ole pakollista. Esimerkiksi selaimen anonyymisyys tyypillisesti sallitaan. Toisaalta liiketoiminnan kannalta tärkeässä kommunikoinnissa sitä usein edellytetään. Asiakaspään autentikointi on yleisesti käytössä kaksi tapaa: (1) HTTP perusautentikointi yhdistettynä palvelimen SSL-autentikointiin ja (2) SSL:n sertifikaatti-perustainen autentikointi (samaan tapaan kuin edellä esitettiin palvelimelle). HTTP perusautentikointi (HTTP basic authentication, RFC 2617) on osa HTTP protokollan spesifikaatioita ja se perustuu käyttäjätunnuksen ja salasanan käyttöön. Huomaa, että ne molemmat lähetetään kryptaamattomana. Tässä vaihtoehdossa SSL tarjoaa luottamuksellisuuden. Jälkimmäinen tapa on puolestaan vastaava kuin edellä esitettiin palvelimen tapauksessa. Tässäkin tapauksessa asiakkaan tulee siis ensin pyytää digitaalinen sertifikaatti kolmannelta osapuolelta. 138

Web-palveluteknologioiden kehittäjinä Microsoft ja IBM ovat olleet tärkeissä rooleissa. Turvallinen viestinvälitys on myös viime aikoina ollut näiden sekä monien muiden osapuolien tärkeänä kehityskohteena. Microsoft, IBM ja Verisign tekivätkin ehdotuksen, jonka nimeksi tuli WS-Security, SOAP-pohjaisen viestinvälityksen turvallisuuteen liittyvien ongelmien ratkaisemiseksi. WS- Security pyrkii erityisesti turvaamaan luottamuksellisuuden ja koskemattomuuden viestinvälityksessä. Vuonna 2004 OASIS teki WS-Security ehdotuksesta version 1.0 ja samalla siitä tuli OASIS-organisaation ylläpitämä standardi. Helmikuussa 2006 OASIS julkaisi siitä version 1.1. WS-Security on laajennettava standardi. Se tarjoaa mekanismit turvallisuusprotokollien määrittämiseksi sen sijaan että se tarjoaisi tietyt eksplisiittiset turvallisuusprotokollat. Tämä tarkoittaa sitä, että on käyttäjien vastuulla suunnitella omat haavoittumattomat protokollat. 139

WS-Security käyttää hyväkseen W3C:n XML Encryption ja XML Signature spesifikaatioita, joihin tutustutaan seuraavaksi. Koska voisi ehkä sanoa, että SW-Securityspesifikaation takana on Web-palvelutekniikoiden pääkehittäjät, voi sen käyttöönoton olettaa lisääntyvän yleisemminkin. Työkalutukea SW-Security-spesifikaatioille on jo nyt olemassa. WS-Security käyttää XML Signature -spesifikaatioita sekä ns. turvallisuusavaimia (security tokens) viestin koskemattomuuden varmistamiseksi. Nämä turvallisuusavaimet ovat viestin lähettäjän määräämiä väitteitä, joita käytetään varmistamaan viestin koskemattomuus. Tällainen väite voi sisältää esimerkiksi nimen, salasanan, avaimen, sertifikaatin jne. Viestin luotettavuuden varmistamiseen puolestaan käytetään XML Encryption kieltä yhdessä turvallisuusavaimien kanssa. 140

SW-Security merkkaus laajentaa SOAP-viestiä lisäämällä sopivia elementtejä SOAPviestin header-osaan. Tämä merkkaus sijoitetaan elementtiin <Security>. SW-Securityspesifikaatio määrittelee joukon eri elementtejä erityyppisten turvallisuusavaimien merkkaamiselle. Esimerkiksi elementtiä <UsernameToken> voidaan käyttää käyttäjänimen antamiseen ja elementtiä <BinarySecurityToken> binääri-formaatissa olevan turvallisuusavaimen antamiseen. Alla on SW-Security spesifikaatiossa esitetty esimerkki elementin <UsernameToken> käytöstä: <S11:Envelope xmlns:s11="..." xmlns:wsse="..."> <S11:Header>... <wsse:security> <wsse:usernametoken> <wsse:username>zoe</wsse:username> </wsse:usernametoken> </wsse:security>... </S11:Header>... </S11:Envelope> 141

Ns. hash-funktioita käytetään esimerkiksi digitaalisissa allekirjoituksissa helpottamaan ja tehostamaan digitaalisten allekirjoitusten tekemistä sekä niiden verifiointia. hash-funktio on algoritmi, joka muodostaa alkuperäisestä tiedosta yksikäsitteisen esityksen, ns., sormenjäljen, joka on huomattavasti lyhyempi kuin alkuperäinen data. Tässä yksikäsitteisyys on oleellista sormenjäljen aitouden varmentamiseksi ja mahdollisten muutosten havaitsemiseksi: mikäli alkuperäistä tietoa on muutettu, samaa hash-funktioita sovellettaessa saadaan erilainen sormenjälki. Puhuttaessa turvallisista hash-funktioista, tarkoitetaan tilannetta, jossa hashfunktion käänteisfunktio on mahdotonta tai hyvin vaikea muodostaa alkuperäisen datan muodostamiseksi sormenjäljestä. Tilanne on siis vastaava kuin eisymmetrisissä kryptosysteemeissä. 142

hash-funktioita käytetään esimerkiksi digitaalisissa allekirjoituksissa, erityisesti tapauksissa, joissa sähköisessä muodossa olevaa asiakirjaa ei haluta kryptata vaan ainoastaan allekirjoittaa se. Ts., tarkoitus ei ole välttämättä salata tietoa vaan ainoastaan todistaa, että lähettäjä on oikea tai tarkemmin sanottuna että lähettäjä ja viesti liittyvät yhteen. Tällöin hash-funktiolla muodostetaan ensin lyhyt sormenjälki alkuperäisestä asiakirjasta. Sen jälkeen tämä sormenjälki kryptataan (alkuperäisen asiakirjan sijaan). Vastaanottajalle lähetetään asiakirja alkuperäisessä muodossaan sekä kryptattu sormenjälki. Allekirjoituksen varmentamiseksi vastaanottaja purkaa ensin kryptauksen käyttäen lähettäjän julkista avainta. Tässä julkisuus voi myös rajoittua rajoitettuun joukkoon vastaanottajia. Sen jälkeen vastaanottaja generoi samalla hash-funktiolla alkuperäisestä dokumentista toisen sormenjäljen. Mikäli uusi sormenjälki ja viestin mukana lähetetty sormenjälki ovat identtiset, on allekirjoitus validi. Tällöin siis vastaanottaja tietää, että kryptaus on suoritettu avaimella, jota ko. julkinen avain vastaa. 143

144

145

146

147

148

149

XML Encryption on W3C suositus tiedon kryptaamiseksi ja kryptatun tiedon esittämiseksi XML-muodossa. Kryptattava tieto voi olla mitä vain, esimerkiksi XML-dokumentti, yksi tai useampi XML-dokumentin elementeistä tai vaikkapa XML-elementin sisältö (merkkijono). Kryptattava tieto voi olla myös binääridataa, esimerkiksi png-formaatissa oleva kuva. XML Encryption kieli on periaatteessa melko yksinkertainen. Kryptauksen tulos esitetään elementin EncryptedData sisältönä. Ko. elementti korvaa alkuperäisen kryptattavan tiedon ja sisältää alielementeissään tai viittaa kryptattuun tietoon. Lisäksi EncryptedData-elementti voi sisältää tietoa kryptauksessa käytetyistä avaimista. Sovelluksien tulee käyttää URIa xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' identifioimaan, että ne toteuttavat voimassa olevan XML Encryption suosituksen (joulukuulta 2002). XML-dokumenttien kryptaus saattaa aiheuttaa myös ongelmia. Esimerkiksi eri tyyppiset haut kryptatusta XML-dokumentista saattavat olla vähintäänkin ongelmallisia. Lisäksi saattaa olla vaikea valita mitkä osat XML-dokumentista on tarkoituksenmukaista kryptata ja mitkä ei. Myös XML Scheman/DTD määrittelyjen käyttö saattaa aiheuttaa ongelmia. Kryptatun lohkon sisältämät elementit voidaan kuitenkin päätellä kielioppimäärityksestä (mikäli sellainen on käytettävissä). 150

EncryptedData-elementillä on neljä attribuuttia, joista kaikki ovat optionaalisia. Id-attribuuttia voidaan käyttää identifioimaan EncryptedData-elementti string-tyyppisellä arvolla. Type-attribuutti määrittelee kryptatun tiedon tyypin. Se voi olla Element (elementti) tai Content (elementin sisältö): 1. Tyyppi Element a) kryptataan tietty elementti b) super-encryption : kryptattu tieto (elementti) sisältää EncryptedData tai EncryptedKey elementtejä. Huom! Elementti EncryptedData ei kuitenkaan voi olla isä- tai lapsielementti toiselle EncryptedDataelementille. Itse kryptattu tieto sen sijaan voi olla mitä vain...ja siis sisältää esim. EncryptedData tai EncryptedElement elementtejä. Esim.: <EncryptedData Id='ED1' xmlns='http://www.w3.org/2001/04/xmlenc#' Type= http://www.w3.org/2001/04/xmlenc#element > 2. Tyyppi Content a) kryptataan joukko elementtejä (elements) b) kryptataan elementin sisältö (character data) Esim. <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> Vaikka Type-attribuutin käyttö onkin optionaalista, sen käyttöä suositellaan vahvasti tapauksessa, jossa kryptattu data (EncryptedData-elementin sisältö) korvaa osan alkuperäisen XML-dokumentin sisällöstä ja on tyypiltään element (eli korvaa tietyn elementin) tai content (korvaa tietyn elementin sisällön, esim. luottokortin numero: <creditcardnumber>123 </creditcardnumber>). Jos tällöin Type- 151

attribuutille ei anneta arvoa, saattaa dekryptauksessa tulla ongelmia, ts. dekryptaaaja ei pysty automaattisesti purkamaan kryptausta alkuperäiseen XML-dokumentin muotoon. Tämä johtuu dekryptaukselle määritellyistä vaatimuksista XML Encryption spesifikaatioissa ja siitä, että tyyppi-informaatio saattaa muussa tapauksessa sisältää tulkinnan tai prosessoinnin kannalta oleellista tietoa. 151

MimeType-attribuutti määrittelee kryptatun datan mediatyypin string-muodossa ja Encoding-attribuutti määrittelee käytetyn koodaustavan URI-arvon avulla. Jos esimerkiksi kryptattu data on base64-koodattua PNG-muotoa, voidaan koodaus määritellä ja mediatyyppi Encoding= http://www.w3.org/2000/09/xmldsig#base64 MimeType= image/png. Attribuuttien lisäksi EncryptedData-elementillä on joukko alielementtejä, joista osa on optionaalisia. Sen ensimmäinen optionaalinen alielementti on EncryptionMethod. Se kuvaa käytetyn kryptausalgoritmin. Mikäli tämä alielementti puuttuu, täytyy vastaanottajan (dekryptaajan) tietää entuudestaan käytetty kryptausalgoritmi. Muuten dekryptaus ei luonnollisestikaan onnistu. 152

Optionaalinen alielementti KeyInfo sisältää informaatiota kryptaukseen käytetyistä julkisista avaimista. Sillä on muutamia alielementtejä, joita käytetään tämän informaation merkkaamiseen. Koko KeyInfo-elementin rakenne on määritelty XML Signature spesifikaatiossa, johon tutustumme seuraavaksi. EncryptedData-elementin CipherData-alielementti on pakollinen. Se joko sisältää kryptatun tiedon CipherValue-alielementissään tai viittaaa siihen CipherReference-alielementissä URI-arvon avulla. EncryptionProperties on myös optionaalinen alielementti. Siinä voidaan antaa lisäinformaatiota EncryptedData tai EncryptedKey elementtien generoinnista prosessointia varten (esim. aika tai päivämäärä). Tarkkaan ottaen EncryptionProperties antaa lisäinformaatiota EncryptedType-elementtien generointiin liittyen, joka puolestaan on abstrakti tyyppi, josta EncryptedData ja EncryptedKey on johdettu. 153

Esimerkki (XML Encryption spesifikaatio): 1. Alkuperäinen XML-dokumentti: <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> 2. Versio, jossa luottokortti-informaatio (CreditCard elementti) on kryptattu <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> 154

<CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo> 154

155

156

XML Signature suositus on IEFT:n ja W3C:n yhdessä kehittämä. Se määrittelee XML-pohjaisen syntaksin digitaalisten allekirjoitusten merkkaamiseen sekä prosessointiohjeet niiden käsittelemiseksi. XML Signature kieltä voidaan käyttää monentyyppisen digitaalisen sisällön allekirjoittamiseen. Se tarjoaa periaatteessa tavan liittää avaintietoa sisältöön. XML Signature kielen sisältöön tutustuimme osin jo edellä: XML Encryption kielen KeyInfo-määritykset on määritelty XML Signature spesifikaatiossa. XML Signature tarjoaa tuen koskemattomuudelle sekä viestin ja/tai allekirjoittajan autentikoinnille.. 157

Digitaalinen allekirjoitus voi sisältää tietoa käytetyistä kryptografisista funktioista, joita käytetään allekirjoituksissa. Näitä voivat olla esimerkiksi sormenjäljen muodostamiseen käytetyt hash-funktiot ja julkisiin avaimiin perustuvat algoritmit. Lisäksi viestin vastaanottajalle voidaan välittää tietoa (julkisesta) avaimesta, jota se voi käyttää allekirjoituksen varmentamiseen. Digitaalinen allekirjoitus voi koskea paikallisesti jotain tiettyä osaa XMLdokumentista (envoloped), se voi koskea koko XML-dokumenttia (enveloping) tai se voi olla ulkoinen (external), jolloin erillisenä annettuun allekirjoitukseen ainoastaan viitataan itse dokumentista. XML Signature spesifikaation mukainen allekirjoitus annetaan Signatureelementin avulla. Sen sisäiseen rakenteeseen perehdymme myöhemmin. 158

Kaksi XML dokumenttia saattavat erota toisistaan puhtaan tekstuaalisen vertailun perusteella, vaikkakin ne voivat olla loogisesti ekvivalentit. Tällaisissa tapauksissa kryptografiset hash-algoritmit, joita käytetään digitaalisissa allekirjoituksissa, antavat eri arvot. Niin sanottu kanoninen XML spesifikaatio kuvaa menetelmän, jolla voidaan generoida sellainen fyysinen esitys XML-dokumentista (ns. kanoninen muoto), joka ottaa huomioon sallittavat variaatiot (eivät vaikuta loogiseen sisältöön) annetussa sovelluskontekstissa. Tämä luonnollisestikin auttaa edellä mainittuun ongelmaan, koska tällöin esimerkiksi epäilyjä autentikoinnin tai luottamuksellisuuden suhteen ei nouse esille loogisesti samanlaisten XML-varianttien esiintyessä. Kanoninen muoto tarkoittaa siis sellaista XML-dokumentin fyysistä esitystä, joka on tuotettu jollain kanonisointimenetelmällä. Kahden fyysisesti hieman erilaisen mutta sisällöltään ja rakenteeltaan samanlaisesta dokumentista kanonisointi tuottaa identtiset dokumentit. Digitaalisissa allekirjoituksissa käytetään tyypillisesti XML-dokumentin kanonista muotoa. Digitaalisten allekirjoitusten lisäksi sitä käytetään tapauksissa, jolloin dokumentin tarkalla fyysisellä rakenteella on vaikutusta sen käyttöön. Tällaisissa tapauksissa esimerkiksi välilyöntien tai tabulointien käyttö vaikuttaa siihen miten dokumenttia tulkitaan tai käytetään. Esimerkki (W3C: Canonical XML Recommendation): a) Alkuperäinen XML dokumentti: <?xml version="1.0"?> <?xml-stylesheet href="doc.xsl" type="text/xsl"?> <!DOCTYPE doc SYSTEM "doc.dtd"> <doc>hello, world!<!-- Comment 1 --></doc> <?pi-without-data?> <!-- Comment 2 --> <!-- Comment 3 --> b) Kanoninen muoto (ilman kommentteja): <?xml-stylesheet href="doc.xsl" type="text/xsl"?> <doc>hello, world!</doc> <?pi-without-data?> 159

c) Kanoninen muoto (kommentteineen): <?xml-stylesheet href="doc.xsl" type="text/xsl"?> <doc>hello, world!<!-- Comment 1 --></doc> <?pi-without-data?> <!-- Comment 2 --> <!-- Comment 3 --> 159

Digitaaliset allekirjoitukset merkataan XML Signature kieltä käytettäessä elementin Signature avulla. Sillä on neljä alielementtiä, joista kaksi on pakollista ja kaksi optionaalista. Elementti SignedInfo sisältää sen informaation, joka allekirjoitetaan. SignedInfo-elementillä on kolme alielementtiä. Alielementti CanonicalizationMethod on pakollinen ja se määrittelee käytetyn kanonisointialgoritmin, jonka avulla tieto muutetaan kanoniseen XML-muotoon. Itse allekirjoitus tehdään kanonisoidulle muodolle. Seuraava pakollinen alielementti on SignatureMethod. Se puolestaan määrittelee algoritmin, jolla kanonisoidusta muodosta muodostetaan itse allekirjoitus. SignatureMethod identifioi kaikki kryptografiset funktiot, joita allekirjoitusoperaatiossa tarvitaan. Allekirjoituken tekeminen voi olla monimutkainenkin kombinaatio erilaisia funktioita, kuten ensin käytetty kanonisointialgoritmi, padding (ja mahdollisesti muita käytettyjä transformaatioalgoritmeja) sekä hash-funktiota käyttävä sormenjäljen muodostava pakkausalgoritmi (digest-funktio). Jotkut kryptauksessa käytetyt algoritmit edellyttävät tietynmittaisia syötteitä, padding tarkoittaa (yksikertaistetusti) merkkijononlisäystä, jonka avulla syöte saadaan määrämittaiseksi (tai sen monikerraksi). Kryptausta avattaessa tulee luonnollisesti tietää miten ko. lisätty merkkijono tulee poistaa. Yksinkertaisessa allekirjoitusprosessissa siis ensin tulee kanonisoida allekirjoitettava tieto. Sitten siitä muodostetaan lyhyt sormenjälki, joka sen jälkeen allekirjoitetaan käyttäen salaista omaa avainta (julkisiin avaimiin perustuva kryptosysteemi). Allekirjoitus sijoitetaan Signature-elementin SignatureValue-alielementin sisällöksi. Viestin vastaanottaja voi myöhemmin käyttää julkista avainta varmistaakseen allekirjoituksen. XML Signature spesifikaatio sallii siis sen, että usealla osapuolella voi olla julkinen avain hallussaan allekirjoituksen verifiointia varten. Tämä julkinen avain voidaan välittää viestin mukana tai se voi olla muutoin tietyn vastaanottajajoukon hallussa. Spesifikaatio painottaa, että yksityinen avain tulee olla vain pienen joukon 160

ja mieluiten vain yhden osapuolen hallussa. Julkinen avain voi olla suuremman joukon (osapuolet, jotka voivat tai joiden odotetaan varmentavan allekirjoitus) tiedossa, mutta se ei kaikissa tapauksissa ole täysin julkinen. Yksi tärkeä esille nouseva kysymys on vastaanottajaosapuolten luottamus julkiseen avaimeen. Tätä on pyritty varmentamaan käyttämällä sertifikaatteja. 160

SignedInfo-elementin kolmas alielementti Reference on pakollinen. Sillä on kolme optionaalista attribuuttia. ID-attribuutti ja Transforms-alielementti (josta lisää seuraavaksi) kuvaavat miten syöte sormenjäljen ottamiselle on muodostettu. Type-attribuutti puolestaan kuvaa tämän syötteen tyypin ja auttaa siten ko. tiedon prosessoinnissa. URI-attribuuttia käytetään allekirjoituksen validoinnissa (josta lisää myöhemmin). Sen vuoksi se tulisi yleensä antaa. Sen pois jättäminen on perusteltua vain silloin, kun voidaan olettaa, että viestin vastaanottaja pystyy selvittämään allekirjoitettavan tiedon jollain muulla tavoin. ID-attribuutti puolestaan identifioi Reference-elementin (normaaliin ID-attribuutin käytön tapaan). Tämä puolestaan mahdollistaa turvallisen viittauksen Referenceelementtiin ulkopuolelta. Type-attribuutti kertoo minkä tyyppistä allekirjoitettava data on. Esim.: Type= http://www.w3.org/2000/09/xmldsig#object 161

Reference sisältää kolme alielementtiä. Pakollinen DigestMethod-alielementti määrittelee allekirjoitusalgoritmin, jota käytetään allekirjoitettavalle tiedolle sen jälkeen, kun se on ensin käsitelty Transforms-algoritmeilla. DigestMethodalielementin määrittelemä algoritmi muodostaa allekirjoitettavasta (ja kanonisoidusta) tiedosta hash-funktion avulla muodostetun sormenjäljen. Pakollinen DigestValue-alielementti sisältää itse sormenjäljen. Optionaalinen Transforms-alielementti sisältää listan esiprosessointiaskeleista, joita sovelletaan allekirjoitettavalle tiedolle ennen kuin se allekirjoitetaan. Tällaisia esiprosessointiaskeleita voivat olla esimerkiksi kanonisointi, koodaustavan soveltaminen, XSLT-transformaatio, XPath-määritys, XML Schema validointi tai XInclude-määritys. 162

Signature-elementin SignatureValue-alielementti on pakollinen ja sisältää lopullisen allekirjoituksen. Se käyttää aina base64-koodaustapaa. Signatureelementin kaksi jäljellä olevaa alielementtiä Object ja KeyInfo ovat molemmat optionaalisia. KeyInfo-alielementin avulla viestin vastaanottajalle välitetään tietoa avaimesta, joita se voi käyttää allekirjoituksen verifiointiin. Object-alielementtejä voi puolestaan esiintyä useampia ja ne voivat periaatteessa sisältää millaista dataa hyvänsä. Object-elementtiä käytetään kirjekuorena toimivaa allekirjoitusta (enveloping signature) käytettäessä kuljettamaan allekirjoitettava tieto. Tällöin sormenjälki (digest) lasketaan koko Objectelementistä, mukaanlukien alku- ja lopputagit. Object-elementillä on kolme optionaalista attribuuttia: MimeType, ID, ja Encoding. Jos esimerkiksi Object sisältää base64-koodattua PNG-mutoista tietoa, voisi attribuutin MimeType arvo olla image/png ja attribuutin Encoding arvo base64. Object-elementin IDattribuuttiin viitataan usein esimerkiksi SignedInfo-elementistä. 163

Esimerkki (XML Signature specification): <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n- 20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> 164

<P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature> 164

Kuten jo aiemmin on mainittu, digitaalista allekirjoitusta tehtäessä kanonisoinnin ja mahdollisten muiden transformaatio operaatioiden jälkeen lasketaan allekirjoitettavasta datasta lyhyt sormenjälki (digest) käyttäen hash-algoritmeja. Tämän jälkeen saatu sormenjälki allekirjoitetaan käyttäen allekirjoittajan yksityistä avainta. Vastaava julkinen avain voidaan välittää viestin vastaanottajalle sanomassa (KeyInfo-elementissä) tai vastaanottaja voi saada sen muuten tietoonsa. Allekirjoituksen tarkistamiseen (perusvarmistus) liittyy kaksi pakollista vaihetta, jotka liittyvät em. allekirjoitusprosessiin: sormenjäljen varmistus (digest verification) ja allekirjoituksen varmistus (signature validation). Allekirjoituksen varmistus tehdään, jos sormenjäljen varmistus on onnistunut. 165

Varmistettaessa XML Signature kielellä tehtyä digitaalista allekirjoita tehdään ensin sormenjäljen varmistus. Aluksi kanonisoidaan SignedInfo-elementin arvo käyttäen annettua kanonisointimenetelmää (CanonicalizationMethod ). Sen jälkeen jokaiselle SignedInfo-elementin Reference-alielementille tehdään sormenjäljen varmistus käyttäen sen alielementtejä DigestMethod, DigestValue ja Transforms. Tämä tehdään puolestaan kolmessa vaiheessa. Aluksi tulee selvittää tieto, jolle allekirjoitus on tehty. Kuten aiemmin Signature-elementin alielementtejä läpi käydessä selvitettiin, SignedInfo-alielementin Referencealielementin URI-attribuutti identifioi tiedon, jolle sormenjälki muodostetaan. Tässä vaiheessa voidaan siis käyttää apuna sitä tietoa sekä Transformsalielementin määrittelemiä transformointifunktioita. Seuraavassa vaiheessa saadusta tiedosta muodostetaan sormenjälki käyttäen DigestMethod-elementissä annettua menetelmää. Lopuksi verrataan laskettua arvoa DigestValuealielementin arvoon. Mikäli ne ovat täsmälleen samat, on sormenjälki todettu oikeaksi (koskemattomuus). 166

Allekirjoituksen tarkistaminen tapahtuu luonnollisesti allekirjoittajan julkista avainta käyttäen. Tarkoituksena on tarkistaa vastaako SignatureValue-elementin arvo sitä arvoa, joka saadaan kun käytetään kanonisointimenetelmää (CanocicalizationMethod ) ja allekirjoitusmenetelmää (SignatureMethod ). Tässä tulee siis tarkistettua, että SignedInfo-elementin arvoa ei ole muutettu ja että käytetyt avaimet ja menetelmät/muunnokset ovat oikeita. Allekirjoituksen validoinnissa toimitaan kuten allekirjoitettaessakin. Ensin siis tehdään kanonisointi allekirjoitettavalle tiedolle ja sen jälkeen käytetään kuvattua allekirjoitusmenetelmää. Laskettua allekirjoitusta verrataan sitten SignatureValue-elementin sisältämään allekirjoitukseen. Tässä tulee muistaa, että SignatureMethod kuvaa mahdollisesti useita kryptografisia funktiota, joita allekirjoitusalgoritmi käyttää. 167

SOAP ei itsessään ota kantaa tai sisällä mekanismeja viestin turvallisuuden takaamiseksi, mutta se sallii niiden toteuttamisen laajennosmekanisminsa kautta (header-osa). Turvallinen viestinvälitys voidaan Web-palvelukonseptissa taata usealla eri tavalla ja usealla eri tasolla. Digitaalisia allekirjoituksia ja kryptausta voidaan käyttää laajentaen SOAP-viestejä sopivasti. Toisaalta kuljetusprotokollatasolla voidaan käyttää vaikkapa SSL:ää tai TLS:ää. Mikäli näin saatu lisäturvallisuus on riittävää, on se monissa tapauksissa parempi vaihtoehto kuin käyttää digitaalisia allekirjoituksia ja kryptausta XML-tasolla. On arvioitu, että SSL:n käyttö on n. 10 kertaa tehokkaampaa kuin XML-tasolla tehty kryptaus ja allekirjoitus. Kuten edellä esitetystä voi päätellä, on esimerkiksi digitaalisen allekirjoituksen tekeminen että sen verifiointi monivaiheinen aikaa vievä prosessi. Itse allekirjoitukseen ja kryptaukseen liittyvä merkkaus voi jopa moninkertaistaa viestin koon. Tällöin jo pelkkä jäsentäminenkin vie enemmän aikaa. Mielenkiintoinen vaihtoehto on myös toteuttaa tietyt turvallisuusominaisuudet, kuten avainten hallinta, sertifikaattien hallinta, jne., erillisenä palveluna, joita (tietyt?) Web-palvelut voisivat käyttää. Tämä toisaalta vapauttaisi Webpalveluiden toteuttajan näiden melko monimutkaistenkin asioiden hallinnalta, mutta sisältää myös omat hankaluutensa. Mitkä? 168

Yksi ehkä tällä vilkkaimmin tutkituista palvelujen käyttöön liittyvistä ongelma-alueista on palveluiden yhdistämisen ja workflow-kuvausten mallintaminen. Vaikka BPEL-kieli onkin saavuttanut tietyssä mielessä käytännön standardin aseman palveluperustaisten järjestelmien liiketoimintaprosessien kuvauskielenä, muitakin kieliä on toki ehdotettu ja niitä käytetään. Eri kielet on kehitetty hieman eri tarkoituksiin ja hieman erilaisia vaatimuksia silmällä pitäen. Tämän vuoksi tällä hetkellä kehitetään runsaasti sekä työkaluja ja menetelmiä varsinaisten palveluiden koordinointikuvausten tuottamiseksi korkean tason workflow-malleista. Myös muuntimia eri workflow-kielten välille on kehitetty. Tällä kurssilla ei käsitellä tarkemmin Semanttista Webiä. Siihen voi kuitenkin tutustua esimerkiksi W3C:n Suomen toimiston sivuilla, jonka esitelmäarkistosta löytyy useita esityksiä aiheesta. Perusideana Semanttisessa Webissä on kuvata (Webissä esitettävälle) tiedolle annettava metatieto tavalla, joka on ohjelmallisesti käsiteltävissä ja hyödynnettävissä esimerkiksi tiedon hakua varten. Koska tiedonsiirto erityisesti Internetissä on aina hidasta, on tarkoituksen mukaista siirtää vain oleellinen tieto. Tämä puolestaan edellyttää sen, että tämä oleellinen tieto voidaan helposti löytää. Tiedon tehokasta löytämistä taas tukee metatiedon mahdollisimman hyvä ja kattava esittäminen, jota erilaiset hakukriteerit voivat hyödyntää. Semanttisen Webin tekniikoiden hyödyntäminen Web-palvelujärjestelmissä tarjoaakin näin ollen mahdollisuuden ko. järjestelmien tehostamiseksi. Rekisterit (kuten UDDI) tavallaan hyödyntävätkin metatiedon käyttöä eri kategorisointimekanismeillaan. Käytännössä ei vieläkään ole useita Web-palveluiden ja Semanttisen Webin yhdistämistä tukevia sovelluksia olemassa. 169

Yksi tärkeä tutkimus- ja sovelluskohde on vanhojen legacy-järjestelmien toiminnallisuuden tarjoaminen Web-palveluina. Käytännön tarve sille on tällä hetkellä suuri. Tämä edellyttää ensinnäkin sen, että päätetään mikä toiminnallisuus tarjotaan palveluna. Se puolestaan edellyttää palveluiden identifioinnin. Tämän jälkeen tulee päättää kommunikointitavasta ja kommunikoinnin abstraktiotasosta sekä valita sopiva käärimistapa. Yksi ohjelmistotuotannon näkökulmasta kiinnostava ja oleellinen haaste on myös ohjelmistosuunnitteluprosessin eri vaiheiden huomion ottaminen Web-palveluja toteutettaessa. Tämä edellyttää myös mm. tukea palveluiden ja palveluiden koordinoinnin mallintamiselle. SOA-pohjaisten järjestelmien hallinta kaiken kaikkiaan on myös laaja kysymys. Myös palveluiden tarjoaminen mobiililaitteissa on kiinnostava ja tällä hetkellä akuutti tutkimus- ja kehityskohde. Mobiililaitteita käytetään tällä hetkellä pääasiassa asiakassovellusten ajamiseen. Mobiilius tuo mukanaan myös muita kiinnostavia ja Web-palvelukonseptissa hyödynnettäviä näkökulmia, kuten kontekstisensitiivisyyden. 170

Web-palvelukonseptin käyttöön ottoon liittyy vielä paljon ongelmia. Yksi niistä on standardien jatkuva kehitys ja toisaalta myös työkalutuen kehittyminen ja sen monimuotoisuus. Tällä hetkellä saatava Web-palveluiden toteuttamiseksi tarjolla oleva työkalutuki keskittyy pääasiassa RPCtyyppiseen kommunikointiin, kun taas tuki dokumenttipohjaiselle kommunikoinnille on puutteellisempaa. Se on luonnollisesti myös haasteellisempaa ja vaatii enemmän käsityötä erityisesti palvelua toteutettaessa. Myös prosessinmallinnustyökalut eroavat huomattavasti esimerkiksi käytettyjen mallinnusmenetelmien suhteen. Lisäksi niiden tarjoama tukin ajettavien BPEL-orkestraatioiden generoimiseksi vaihtelee. Turvallisuus on Internet-pohjaisen Web-palveluiden käytön kannalta ehkä suurin haaste. Vaikkakin menetelmiä tietoturvan lisäämiseksi on kehitetty (digitaaliset allekirjoitukset ja kryptausmenetelmät), niin yleistä käytäntöä näiden menetelmien käytöstä Webpalveluinteraktioissa standardista puhumattakaan ei vielä ole. Yksi käytännön kannalta ongelmallinen asia on myös transaktioiden ja palveluiden koordinoinnin tuen vajavaisuus, tosin W3C:n Web Service Choreography -työryhmän ja OASIS-konsortion kehittämät menetelmät ja standardit tähtäävät näiden ongelmien ratkaisemiseen. Liiketoimintatransaktioita tuetaan kuitenkin paremmin esimerkiksi ebxml-konseptissa, jossa on lisäksi tuki sopimuspohjaisuudelle. Koska liiketoimintatransaktioita on vaikea koostaa yksittäisistä viesteistä, aiheuttaa se mahdollisesti enemmän liikennettä asiakassovelluksen ja palvelun välillä. Lisäksi se joissain tapauksissa edellyttää joko asiakaspäähän tai palvelupäähän lisää tarvetta prosessoida viestejä ja yhdistellä tietoja. Sillä on myös vaikutus tehokkuuteen. Tehokkuusongelmat toki koostuvat monista asioista: XML-pohjaisen tiedon prosessointi on tyypillisesti hidasta, asiakassovelluksen mahdollisesti käyttämä dynaaminen proxy tai dynaaminen kutsurajapinta saattavat aiheuttaa hitautta jne. 171

Tehokkuus on usein ongelma XML-pohjaista tietoa käsiteltäessä. Lisäksi Webpalvelujärjestelmissä saatetaan käyttää kryptausmenetelmiä ja digitaalisia allekirjoituksia, joita koskevaa tietoa kuljetetaan SOAP-viestissä. Tämä hidastaa huomattavasti viestien käsittelyä: prosessoitavaa XML-pohjaista tietoa on usein huomattavastikin enemmän ja ennen kaikkea allekirjoitusten validointi, kryptauksten purkaminen jne. vaatii huomattavasti prosessointia. Turvallisuus Web-palvelujärjestelmissä ei rajoitus turvalliseen viestinvälitykseen, vaan sen lisäksi tulisi huolehtia siitä. että palvelut ovat saatavilla, ne toimivat luotettavasti ja ongelmatilanteissa voidaan virhetilanteista toipua dynaamisesti. Virheestä toipuminen voi tarkoittaa esimerkiksi sitä, että ei saatavilla oleva palvelu voidaan tarvittaessa korvata toisella saman toiminnallisuuden tarjoavalla palvelulla. Palvelujärjestelmien ylläpidettävyys onkin mielenkiintoinen ja haasteellinen kysymys, koska palvelujärjestelmillä ei ehkä ole yhtä instanssia, jolla olisi jonkinlainen keskitetty vastuu kaikista käytetyistä palveluista. Edellä mainittujen lisäksi myös laatuattribuuttien (Quality of Service, QoS) käyttö ja hallinta (esimerkiksi koskien vasteaikoja tms.) saattaa vaatia järjestelyitä, joihin ei ole olemassa mitään standardiratkaisuja. Edellä on lueteltu vain muutama Web-palveluiden tämän hetken haasteista. Tuleeko mieleesi muita haasteita? 172