Utveckling av Web Service f¨
or hantering av ¨
oppna
autentiseringsnycklar.
Examensarbete utf¨ort i informationsteori av
Andreas Johansson
LiTH - ISY - EX - - 05 / 3747 - - SE Link¨oping, 2005
Utveckling av Web Service f¨
or hantering av ¨
oppna
autentiseringsnycklar.
Institutionen f¨or systemteknik, Link¨opings Universitet Andreas Johansson
LiTH - ISY - EX - - 05 / 3747 - - SE
Examensarbete: 20 p
F¨ordjupningsniv˚a: D
Handledare: Alf Bengtsson,
Totalf¨orsvarets forskningsinstitut, FOI
Examinator: Viiveke F˚ak,
Institutionen f¨or systemteknik, Link¨opings Universitet Link¨oping September 2005
Institutionen f¨or Systemteknik 581 83 LINK ¨OPING SWEDEN September 2005 x x http://www.ep.liu.se/exjobb/isy/2005/3747/ LiTH - ISY - EX - - 05 / 3747 - - SE
Utveckling av Web Service f¨or hantering av ¨oppna autentiseringsnycklar.
Andreas Johansson
Utvecklingen g˚ar mot alltmer distribuerade IT-system, d¨ar ett flertal da-torer kommunicerar med varandra. Detta g¨aller ¨aven f¨orsvarsmaktens ledningssystem. I dessa ¨oppna och distribuerade system ¨ar olika s¨akerhetsfunktioner kritiska. En av dessa ¨ar att kunna verifiera iden-titeten hos den part som kommunikationen sker med. Detta g¨ors oftast med hj¨alp av asymmetriska kryptooperationer, d¨ar identiteter kan veri-fieras med hj¨alp av ¨oppet publicerade autentiseringsnycklar. Hanteringen
av s˚adana nycklar kan centraliseras med hj¨alp av XML Key Management
Specification. XKMS ¨ar en standard utvecklad av W3C som specificerar en Web Service f¨or hantering av distribution, verifiering och registrering
av ¨oppna nycklar. I detta examensarbete har en del av en s˚adan service
implementerats. Fokus har legat p˚a distribution och verifikation av X.509-certifikat som ¨ar en ledande standard f¨or att knyta ihop identiteter med nycklar. Slutligen har ett API till Java utvecklats f¨or att p˚a klientsidan underl¨atta nyttjandet av en XKMS-service.
XKMS, PKI, Web Services, Datas¨akerhet, Informationss¨akerhet, XML.
Nyckelord Keyword Sammanfattning Abstract F¨orfattare Author Titel Title
URL f¨or elektronisk version
Serietitel och serienummer Title of series, numbering
ISSN ISRN ISBN Spr˚ak Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats ¨ Ovrig rapport Avdelning, Institution Division, Department Datum Date
Sammanfattning
Utvecklingen g˚ar mot alltmer distribuerade IT-system, d¨ar ett flertal datorer kommunicerar med varandra. Detta g¨aller ¨aven f¨orsvarsmaktens ledningssys-tem. I dessa ¨oppna och distribuerade system ¨ar olika s¨akerhetsfunktioner kritiska. En av dessa ¨ar att kunna verifiera identiteten hos den part som kommunikationen sker med. Detta g¨ors oftast med hj¨alp av asymmetriska kryptooperationer, d¨ar identiteter kan verifieras med hj¨alp av ¨oppet
publicer-ade autentiseringsnycklar. Hanteringen av s˚adana nycklar kan centraliseras
med hj¨alp av XML Key Management Specification. XKMS ¨ar en standard utvecklad av W3C som specificerar en Web Service f¨or hantering av distribu-tion, verifiering och registrering av ¨oppna nycklar. I detta examensarbete har en del av en s˚adan service implementerats. Fokus har legat p˚a distribution och verifikation av X.509-certifikat som ¨ar en ledande standard f¨or att knyta ihop identiteter med nycklar. Slutligen har ett API till Java utvecklats f¨or
att p˚a klientsidan underl¨atta nyttjandet av en XKMS-service.
Nyckelord: XKMS, PKI, Web Services, Datas¨akerhet, Informationss¨akerhet, XML.
Ordf¨
orklaringar
De frekvent anv¨anda termerna och f¨orkortningarna f¨orklaras och samman-fattas h¨ar.
API Application Programming Interface
CA Certificate Authority
HTTP Hypertext Transfer Protocol
PKI Public Key Infrastructure
SOAP Simple Object Access Protocol
W3C World Wide Web Consortium
WSDL Web Services Description Language
XML Extensible Markup Language
Inneh˚
all
1 Inledning 1 1.1 Bakgrund . . . 1 1.2 Syfte . . . 1 1.3 Metod . . . 2 1.4 Avgr¨ansningar . . . 2 1.5 L¨asanvisningar . . . 2 2 Teknisk bakgrund 3 2.1 Web Services . . . 32.1.1 Exempel p˚a en Web Service . . . 4
2.1.2 Web Service tekniker . . . 4
2.2 Grunder i datas¨akerhet . . . 7
2.2.1 Datas¨akerhetens tre principer . . . 8
2.3 Kryptering . . . 8 2.3.1 Terminologi . . . 9 2.3.2 Symmetrisk kryptering . . . 9 2.3.3 Asymmetrisk kryptering . . . 10 2.4 Digitala signaturer . . . 11 2.4.1 Hashalgoritmer . . . 11
2.4.2 Implementation av digitala signaturer . . . 12
2.5 Digitala certifikat . . . 12
2.5.1 X.509 . . . 13
2.6 Public Key Infrastructure . . . 14
2.6.1 Rotcertifikat . . . 14
2.7 S¨akra Web Services . . . 15
2.7.1 WS-Security . . . 15 3 XKMS - specifikation 19 3.1 Introduktion . . . 19 3.2 Uppbyggnad . . . 20 3.2.1 Protokoll . . . 22 Johansson, 2005. xi
3.3 Specifikation av X-KISS . . . 22 3.3.1 Locate . . . 22 3.3.2 Validate . . . 24 3.4 Specifikation av X-KRSS . . . 27 3.4.1 Register . . . 28 3.4.2 Revoke . . . 29 3.4.3 Key Recovery . . . 29 4 XKMS - implementation 31 4.1 Uppgiftsbeskrivning . . . 31 4.1.1 Avgr¨ansningar . . . 31 4.2 Designbeslut . . . 32 4.2.1 Val av XKMS-version . . . 32 4.2.2 Designfilosofi . . . 33 4.2.3 Java . . . 33 4.2.4 Utvecklingsmilj¨o . . . 33 4.3 Server . . . 34 4.3.1 Arkitektur . . . 34 4.3.2 Locate . . . 35 4.3.3 Validate . . . 35 4.4 Klient . . . 36 4.4.1 API . . . 37 4.4.2 XKMSClientTester . . . 38 4.5 Simulering av CA . . . 38 4.5.1 Paketet PKIInteraction . . . 39
5 Diskussion och slutsatser 43 5.1 XKMS . . . 43 5.1.1 Interoperabilitet . . . 43 5.1.2 Aktivitet . . . 44 5.2 S¨akerhet . . . 45 5.2.1 S¨akerhetsh˚al . . . 45 5.2.2 Kryptering av protokoll . . . 45 A Detaljerad design 49 A.1 Paket¨oversikt . . . 49 A.2 Klasser . . . 50 A.2.1 se.foi.andjo.xkms.client . . . 50 A.2.2 se.foi.andjo.xkms.server . . . 51 A.2.3 se.foi.andjo.xkms.server.pkiinteraction . . . 51 A.2.4 se.foi.andjo.xkms.client.iface.structs.xkms . . . 52
Inneh˚all xiii
A.2.5 se.foi.andjo.xkms.client.iface.structs.xmldsig . . . 53
A.2.6 se.foi.andjo.xkms.server.iface.struct . . . 54
B Installation 57 B.1 Inneh˚all i paketet . . . 57
B.2 Systemkrav . . . 57
B.3 Anvisningar f¨or installation och uppstart . . . 57
B.3.1 Server . . . 58 B.3.2 Klient API . . . 58 B.4 Certifikathantering . . . 58 B.5 Fels¨okning . . . 58 C XML-meddelanden 61 C.1 SOAP - XKMSLocateRequest . . . 61 C.2 SOAP - XKMSLocateResult . . . 62 C.3 SOAP - XKMSValidateRequest . . . 63 C.4 SOAP - XKMSValidateResult . . . 64
Kapitel 1
Inledning
1.1
Bakgrund
Utvecklingen g˚ar mot alltmer distribuerade IT-system, d¨ar ett flertal datorer kommunicerar med varandra. Detta g¨aller ¨aven f¨orsvarsmaktens ledningssys-tem. F¨or att f˚a ett system som ¨ar s˚a flexibelt och billigt som m¨ojligt vill man att kommunikationen skall ske enligt ¨oppna standarder som ¨ar oberoende av
vilken plattform som anv¨ands. Ett s˚adant koncept ¨ar en tj¨ansteorienterad
arkitektur realiserad via Web Services.
Ju ¨oppnare och mer distribuerat ett system ¨ar, desto mer kritiska blir s¨akerhetsfunktionerna. Viktigt ¨ar d˚a att s¨akert kunna verifiera identiteten hos den part som kommunikationen sker med. Ett av de s¨akrare s¨atten ¨ar att g¨ora detta med hj¨alp av asymmetriska kryptooperationer, d¨ar identiteter kan verifieras med hj¨alp av ¨oppet publicerade autentiseringsnycklar. Hanteringen av s˚adana nycklar ¨ar naturlig att centraliera med hj¨alp av en Web Service. World Wide Web Consortium (W3C) har utvecklat en specifikation f¨or detta
¨andam˚al - XML Key Management Specification (XKMS).
1.2
Syfte
Syftet med detta examensarbete ¨ar att implementera delar av XKMS-specifika-tionen. Detta innefattar en server som klarar av lokalisering och validering av certifikat. P˚a klientsidan g˚ar uppgiften ut p˚a att skapa ett API som ska underl¨atta anv¨andandet av den implementerade servern. API:t ska imple-menteras i Java och ¨onskem˚alet ¨ar att servern likas˚a skrivs i detta program-meringsspr˚ak.
1.3
Metod
F¨or att samla information om XKMS har en litteraturstudie anv¨ants. F¨or att utf¨ora sj¨alva implementationen av specifikationen har ett vanligt tillv¨agag˚ angs-s¨att inom mjukvaruutveckling anv¨ants. Tre faser har varit centrala under utvecklingsprocessen:
• Designfas - Arkitektur och datatyper har fastst¨allts utefter specifika-tionens krav.
• Implementationsfas - Under denna fas har den fastst¨allda designen implementerats.
• Testfas - Systemets uppf¨orande har j¨amf¨orts med de krav som st¨allts
i specifikationen vad g¨aller struktur p˚a meddelanden och f¨orv¨antade
svarskoder.
1.4
Avgr¨
ansningar
XKMS-specifikationen st¨odjer flera olika arkitekturer f¨or kryptering och cer-tifiering av identiteter. I detta examensarbete kr¨avs endast st¨od f¨or den van-ligaste standarden f¨or certifiering av nycklar, X.509.
XKMS ¨ar uppdelat i tv˚a delar, X-KISS f¨or lokalisering och verifiering av nycklar samt X-KRSS f¨or registrering. Endast X-KISS ¨ar n¨odv¨andig f¨or att realisera den del av XKMS som ¨ar aktuell i detta projekt.
1.5
L¨
asanvisningar
Kapitel 4 ger en snabb ¨overblick ¨over den implementation som gjorts. F¨or att f¨orst˚a terminologin rekommenderas att kapitel 2 l¨ases. Kapitel 3 ger en ¨oversikt ¨over specifikation och framf¨orallt den f¨orsta delen av detta kapitel ger en grundl¨aggande f¨orst˚aelse om vad XKMS-specifikationen g˚ar ut p˚a. F¨or den som vill f¨ordjupa sig mer i sj¨alva implementationen rekommenderas
Kapitel 2
Teknisk bakgrund
2.1
Web Services
Den f¨orsta f¨allan f¨or nyb¨orjare inom omr˚adet ¨ar att utifr˚an fenomenets namn f¨ors¨oka gissa sig till vad det ¨ar och vad som gjort att det f˚att dess namn. Den vanliga gissningen ¨ar att en Web Service ¨ar en tj¨anst som presenteras p˚a
webben och vars ˚atkomst sker med hj¨alp av en webbl¨asare, s˚asom en
shop-pingsajt eller ett webbaserat diskussionsforum. Detta ¨ar dock inte en Web Service utan snarare det som brukar refereras till som en webbapplikation. Framf¨orallt ¨ar det ordet web i sammanghanget som ¨ar missledande och i detta avsnitt ska jag f¨ors¨oka klarg¨ora vad en Web Service verkligen ¨ar och vad som kr¨avs f¨or att en applikation ska kunna klassas som en Web Service. IBM:s definition av en Web Service ¨ar fritt ¨oversatt att ”Web Services ¨ar modul¨ara applikationer som kan beskrivas, publiceras, lokaliseras och in-vokeras ¨over n¨atverk i allm¨anhet och, i synnerhet, ¨over Internet”. Med In-ternet menas h¨ar WWW och generellt anv¨ands protokollet HTTP f¨or att transportera information mellan en Web Service och en presumtiv klient. Kommunikation mellan en Web Service och en klient ¨ar XML-baserad f¨or
att uppn˚a plattformsoberoende. Den viktigaste skillnaden mellan en Web
Service och en webbapplikation ¨ar att klienten till en webbapplikation alltid ¨ar en webbl¨asare, men klienten till en Web Service kan vara en webbl¨asare,
det kan ocks˚a vara en helt ordin¨ar applikation som kan l¨asa XML. Sist men
inte minst kan ¨aven klienten vara en annan Web Service. En Web Service kan anv¨andas n¨ar data ska f¨orflyttas ¨over ett n¨atverk mellan tv˚a program imple-menterade i olika programmeringsspr˚ak och d¨ar det ¨ar inneh˚allet i datan och inte hur datan presenteras som ¨ar det viktiga. [1]
2.1.1
Exempel p˚
a en Web Service
Ett bra exempel p˚a ett scenario d¨ar en Web Service kan anv¨andas ¨ar i f¨or-h˚allandet mellan en leverant¨or och en ˚aterf¨ors¨aljare. F¨or att presentera ko-rrekt information om sina produkter p˚a sin hemsida m˚aste ˚aterf¨ors¨aljaren
vara i kontakt med leverant¨orens databas som antagligen befinner sig p˚a en
annan plats ¨an ˚aterf¨ors¨aljarens webbserver. Datan kan i detta fall med f¨ordel skickas med hj¨alp av en Web Service. En schematisk bild ¨over denna Web Service ges i figur 2.1.
XML
Återförsäljare Leverantör
Figur 2.1: Exempel p˚a en Web Service.
2.1.2
Web Service tekniker
Ett antal tekniker har tagits fram f¨or att publicera en Web Service ¨over In-ternet. Det ¨ar framf¨orallt tekniker f¨or beskrivning, transport och lokalisering som ¨ar intressanta att titta n¨armre p˚a.
Beskrivning - WSDL
F¨or att en klient skall kunna anv¨anda en Web Service m˚aste klienten
ve-ta vilka metoder den st¨odjer och vilka argument som kr¨avs f¨or att invok-era en metod. En Web Service har inte som en webbapplikation ett grafiskt gr¨anssnitt mot klienten. Ist¨allet anv¨ands en Web Service genom metoder som anropas direkt i programkoden f¨or klienten. F¨or att beskriva vilka metoder en Web Service st¨odjer anv¨ands ett s¨arskilt utvecklat spr˚ak - Web Services
De-scription Language (WSDL). Detta p˚aminner i anv¨andningsomr˚adet om
Cor-bas Interface Description Language (IDL) f¨or den som ¨ar bekant med detta.
F¨or att uppr¨atth˚alla plattformsoberoendet ¨ar ¨aven WSDL ett XML-baserat
spr˚ak. Den viktigaste informationen i en WSDL-fil ¨ar den som beskriver vilka metoder som finns och vilka dess argument ¨ar. En viktig egenskap hos
WS-DL ¨ar att det, precis som med Corbas IWS-DL, g˚ar att generera ett kodskelett
2.1. Web Services 5
l¨ampligt att b¨orja med att skriva en WSDL-fil f¨or sin Web Service f¨or att noga specificera vilka metoder som ska st¨odjas och hur de ska invokeras. Det g˚ar ocks˚a att utifr˚an WSDL-filen generera klientkod f¨or att underl¨atta
in-vokerandet av Web Servicens metoder. Ett exempel p˚a hur en WSDL-fil f¨or
v˚ar ovan n¨amnda Web Service ser ut ges i figur 2.2. De viktigaste delarna i filen ¨ar de under XML-elementet ”portType” som listar vilka metoder som finns att tillg˚a. I detta fall finns tv˚a metoder; getInfo och getStock. WSDL-filen
inneh˚aller ¨aven ytterligare information, s˚asom argument till operationerna, men kodexemplet ¨ar fr¨amst till f¨or att ge en bild av hur WSDL ser ut. [1,4]
<?xml version=’1.0’ encoding=’utf-8’ ?>
<definitions name=’DealerService’ targetNamespace=’..’> <types>
... </types>
<message name=’Dealer_getInfo_Request_Soap’> <part name=’name’ element=’ns0:name’/> </message>
<message name=’Dealer_getInfo_Response_Soap’>
<part name=’response’ element=’ns0:string_Response’/> </message>
<message name=’Dealer_getStock_Request_Soap’> <part name=’name’ element=’ns0:name’/> </message>
<message name=’Dealer_getStock_Response_Soap’>
<part name=’response’ element=’ns0:int_Response’/> </message>
<portType name=’DealerService’>
<operation name=’getInfo’ parameterOrder=’name’> <input message=’tns:Dealer_getInfo_Request_Soap’/> <output message=’tns:Dealer_getInfo_Response_Soap’/> </operation>
<operation name=’getStock’ parameterOrder=’name’> <input message=’tns:Dealer_getStock_Request_Soap’/> <output message=’tns:Dealer_getStock_Response_Soap’/> </operation>
</portType>
<binding name=’DealerService’ type=’tns:Dealer’> ...
</binding>
<service name=’DealerService’>
<port name=’DealerService’ binding=’tns:DealerService’> <soap:address location=’..’/>
</port> </service> </definitions>
Transport - SOAP
SOAP - eller Simple Object Access Protocol - ¨ar en specifikation fr˚an W3C
som specificerar det protokoll som anv¨ands av Web Services. SOAP ¨ar en-ligt W3C ett protokoll skapat f¨or att p˚a ”ett enkelt s¨att och med hj¨alp av XML utbyta typad och strukturerad information i en decentraliserad och distribuerad datormilj¨o”. SOAP-specifikationen kom i april 2000 och har sen dess varit synonym med Web Services. SOAP ¨ar egentligen ingen ny teknik
i sig utan tillhandah˚aller snarare en standard f¨or hur XML-meddelanden
mellan Web Services ska struktureras. Att XML ¨ar den teknik som valts f¨or strukturering ¨ar som tidigare n¨amnt fr¨amst tack vare dess oberoende av
plat-tform och programmeringsspr˚ak. XML ¨ar ¨aven en teknik som ¨ar stark och
som har en gedigen support i s˚av¨al Windows- som UNIX-v¨arlden. [1]
SOAP ¨ar i sig inget transportprotokoll utan det vilar i sin tur p˚a andra protokoll f¨or att sk¨ota denna del. HTTP (HyperText Transport Protocol), SMTP (Simple Mail Transport Protocol) och BEEP (Blocks Extensible Ex-change Protocol) ¨ar alla protokoll som kan anv¨andas f¨or att transportera SOAP-meddelanden. Dock g¨aller allm¨ant att HTTP ¨ar det protokollet som anv¨ands. Valet ¨ar naturligt d˚a HTTP, precis som SOAP, ¨ar ett request-reply-protokoll och att implementera SOAP-request-reply-protokollet kan g¨oras som en modul till en befintlig applikationsserver. En HTTP-header f¨or ett SOAP-meddelande relaterad till ovan n¨amnda DealerService kan ses i figur 2.3.
POST /DealerService HTTP/1.1 Host: 10.0.0.1
Content-Type: text/xml Content-length: 100
Figur 2.3: HTTP-header f¨or SOAP-meddelande till/fr˚an DealerService.
Meddelandesyntax
Ett SOAP-meddelandes struktur specificeras med hj¨alp av XML-scheman. De viktigaste delarna i ett meddelande ¨ar taggarna Envelope, Header och Body. Envelope ¨ar sj¨alva rotelementet. Header kan inneh˚alla ytterligare in-formation om till exempel s¨akerhetsrutiner och status. Body ¨ar det element som inneh˚aller den data som skickats till eller fr˚an en Web Service. Exempel p˚a hur ett SOAP-meddelande till v˚ar DealerService ser ut ses i figur 2.4. H¨ar har statusen p˚a varan ”SampleGoods” efterfr˚agats.
2.2. Grunder i datas¨akerhet 7 <?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:Header> ... </soapenv:Header> <soapenv:Body> <getStock soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <arg0 xsi:type="soapenc:string" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> SampleItem </arg0> </exchangeCertificates> </soapenv:Body> </soapenv:Envelope>
Figur 2.4: Ett SOAP-meddelande till v˚ar DealerService d¨ar klienten invokerar metoden getStock med argumentet SampleItem.
Lokalisering - UDDI
En Web Service kan inte som en webbsida n˚as via l¨ankar fr˚an andra Web
Services utan dess adress m˚aste vara k¨and f¨or klienten som vill anropa den. Ist¨allet kan den som publicerar en Web Service anv¨anda sig av ett Web Ser-vice Directory f¨or att offentligg¨ora sin Web SerSer-vice f¨or omv¨arlden. Tekniken f¨or detta kallas Universal Description, Discovery and Integration (UDDI). Det ska dock n¨amnas att anv¨andandet av denna teknik inte ¨ar s¨arskilt ut-bredd d˚a de flesta Web Services inte ¨ar t¨ankta f¨or publikt anv¨andande. Om fallet ¨ar det motsatta brukar ist¨allet en vanligt listning p˚a en publik webbsida vara mer effektivit och anv¨ant n¨ar det g¨aller spridandet av Web Services. [1]
2.2
Grunder i datas¨
akerhet
Det g˚ar inte att lita p˚a ett os¨akert datorsystem. Om det inte finns rutiner f¨or att f¨orhindra och uppt¨acka intr˚ang i ett datorsystem g˚ar det inte att garan-tera att informationen i systemet inte har f¨or¨andrats eller att det skapats av en s¨arskild identitet. Det ¨ar framf¨orallt tre omr˚aden som ska tas om hand f¨or att systemets anv¨andare ska kunna lita p˚a att systemet uppf¨or sig som f¨orv¨antat.
2.2.1
Datas¨
akerhetens tre principer
Om en bok om datas¨akerhet sl˚as upp ¨ar det n¨astan alltid tre principer som det anses att datas¨akerhet bygger p˚a; confidentiality, integrity och
availabil-ity (CIA). Nedan f¨oljer en kort genomg˚ang av vad som menas med dessa
principer.
• Confidentiality
Handlar om att r¨att anv¨andare ska ha l¨astillg˚ang till r¨att information.
Det g¨aller b˚ade att skydda den personliga integriteten gentemot
or-ganisationen samt att insynsskydda oror-ganisationens information fr˚an
anv¨andaren. • Integrity
Handlar om att skydda k¨anslig information fr˚an att ¨andras av andra
anv¨andare ¨an de som har r¨attigheter till det. N¨ar det g¨aller kommu-nikation handlar det ¨aven om att s¨akerst¨alla att det meddelande som kommer fram ¨ar detsamma som skickats.
• Availability
Handlar om att s¨akerst¨alla att anv¨andare som har r¨attighet till en viss information ska ha tillg˚ang till densamma n¨ar anv¨andaren beh¨over den. Detta ¨ar de koncept som fr¨amst beh¨over tas om hand f¨or att s¨akra ett system. Koncepten i sig beskriver inte hur (vilka tekniker som ska anv¨andas) detta ska g˚a till. M˚anga ¨ar de tekniker som skapats f¨or detta ¨andam˚al och i f¨oljande avsnitt kommer n˚agra av dessa g˚as igenom. De utvalda ¨ar de tekniker som ligger till grund f¨or det projekt som utf¨orts. [2,3]
2.3
Kryptering
Allm¨ant ses ofta kryptering som synonymt med datas¨akerhet. V¨art att notera ¨ar att bara f¨or att det i ett system till¨ampas kryptering inneb¨ar inte det direkt att systemet ¨ar s¨akert. Kryptering ¨ar en grund f¨or till exempel digitala signaturer och andra delar av datas¨akerhet. Det ger ett bra skydd n¨ar det g¨aller att uppfylla principen om ”confidentiality” och ”integrity”, men ¨ovriga delar av s¨akerheten m˚aste ocks˚a ses ¨over f¨or att krypteringen ska ha n˚agon effekt. Informationen som kan f¨or¨andrats innan kryptering sker g˚a inte att lita hur stark denna kryptering ¨an ¨ar.
2.3. Kryptering 9
2.3.1
Terminologi
Inom kryptering finns ett antal centrala termer som b¨or k¨annas till. Klar-text syftar p˚a okrypterad data medan chiffertext syftar p˚a krypterad data. En krypteringsalgoritm anv¨ands f¨or att f¨orvandla klartext till chiffertext. N¨ar det g¨aller algoritmer f¨or kryptering b¨or dock inte en algoritm som utf¨or
krypteringen enligt exakt samma procedur varje g˚ang anv¨andas. Risken med
denna typ av algoritmer ¨ar att om tekniken bakom algoritmen blir k¨and kan alla meddelanden dekrypteras. Ist¨allet f¨or att anv¨anda hemliga krypter-ingsalgoritmer har ist¨allet algoritmer som utnyttjar hemlig information ska-pats. Hur krypteringen g˚ar till ¨ar k¨ant, men dessa algoritmer anv¨ander sig av olika parametrar f¨or att skapa olika chiffertexter. Dessa parametrar brukar omn¨amnas som nycklar. Med hj¨alp av nycklar som endast delas mellan in-volverade parter kan algoritmen producera olika chiffertext beroende p˚a vilka nycklar som anv¨ands. Det finns ytterligare f¨ordelar med att anv¨anda sig av en ”¨oppen” algoritm. N¨ar det g¨aller hemliga algoritmer kan det finnas oup-pt¨ackta s¨akerhetsh˚al som kan utnyttjas av den som lyckats hitta dem. I fallet
med ¨oppna algoritmer kommer antagligen dessa s¨akerhetsh˚al att hittas och
t¨appas till d˚a det finns fler kunniga personer som kan ta del av den teknik
som algoritmen bygger p˚a. I en hemlig algoritm kan det ¨aven finnas
medvet-na bakd¨orrar som skaparen av algoritmen har l¨ammedvet-nat f¨or att kunmedvet-na g˚a runt
krypteringen. [1,3]
Viktigt att po¨angtera n¨ar det g¨aller kryptering ¨ar att en stark kryptering inte ¨ar n˚agon garanti f¨or att datan inte ska kunna dekrypteras och l¨asas. Det
starkare kryptering ˚astadkommer ¨ar att processen med att dekryptera datan
utan k¨annedom om nycklarna f¨orsv˚aras. Rent praktiskt inneb¨ar det att tiden och h˚ardvaran som kr¨avs f¨or att dekryptera datan ¨okar. De flesta algoritmer
som anv¨ands idag ¨ar s˚a pass s¨akra att det enda s¨att att ”kn¨acka” dessa
algoritmer ¨ar att gissa sig till vilken klartext ¨ar. Om tillr¨ackligt stora nycklar anv¨ands tar detta oerh¨ort l˚ang tid med tanke p˚a alla m¨ojliga kombinationer som finns. I slut¨andan ¨ar det detta kryptering handlar om, det ska kosta mer att kn¨acka krypteringen ¨an vad f¨ortj¨ansten ¨ar f¨or att lyckas. Kostnad h¨ar beh¨over inte n¨odv¨andigtvis inneb¨ara rena pengar utan kan lika g¨arna handla om tid. [1]
Kryptering delas fr¨amst upp i tv˚a olika typer, symmetrisk och
asym-metrisk. I f¨oljande avsnitt g˚as dessa typer igenom.
2.3.2
Symmetrisk kryptering
I symmetrisk kryptering anv¨ands samma nyckel f¨or b˚ade kryptering och
kedjan ¨ar det av st¨orsta vikt att nyckeln h˚alls hemlig. Det stora problemet med symmetrisk kryptering ¨ar hur den hemliga nyckeln ska distribueras. Den kan inte s¨andas i klartext innan sj¨alva infomationsutbytet sker eftersom det skulle inneb¨ara att den kan bli sedd i n¨atverkstrafiken och d˚a spelar hela krypteringen ut sin roll. Det g˚ar inte heller att kryptera nyckeln och
skic-ka ¨over den eftersom d˚a uppst˚ar samma problem igen; vilken nyckel ska
anv¨andas f¨or att dekryptera nyckeln? I n¨asta avsnitt presenteras en l¨osning p˚a dessa problem. [1,3] Krypterad text Användare 1 Användare 2 Krypterar med nyckel A. Dekrypterar med nyckel A .
Figur 2.5: Symmetrisk kryptering.
2.3.3
Asymmetrisk kryptering
I asymmetrisk kryptering anv¨ands ist¨allet tv˚a nycklar, en f¨or kryptering och en f¨or dekryptering. Detta g¨aller dessutom endast kommunikation ˚at ett h˚all. F¨or kommunikation ˚at motsatt h˚all anv¨ands ett annat nyckelpar. Detta in-neb¨ar att varje person/system besitter tv˚a nycklar och dessa nycklar brukar refereras till som den publika och den privata nyckeln. Den publika anv¨ands f¨or att kryptera ett meddelade som ska skickas till det aktuella anv¨andaren, och anv¨andare anv¨ander i sin tur den privata nyckeln f¨or att dekryptera meddelandet. P˚a detta s¨att kan den publika nyckeln vara just publik, det g¨or
ingenting om n˚agon kommer ¨over den eftersom dess syfte ¨ar att kryptera.
Allt som skickas till en viss anv¨andare ska krypteras med denna publika nyckel. Anledningen till att dessa nycklar kallas publika/privata ist¨allet f¨or
krypterings/dekrypterings beror p˚a deras anv¨andningsomr˚ade inom andra
delar av s¨akerhetstekniken som kommer f¨orklaras i senare avsnitt. Nackde-larna med att anv¨anda asymmetrisk kryptering ist¨allet f¨or symmetrisk ¨ar att
det ¨ar l˚angsammare. Det finns dock inte samma distributionsproblem som
i den symmetriska krypteringen eftersom nycklar genereras lokalt och den
enda nyckeln som l¨amnar systemet ¨ar den publika. Det g˚ar till och med att
l¨osa den symmetriska krypteringens distributionsproblem med hj¨alp av den asymmetriska genom att den symmetriska nyckeln krypteras med hj¨alp av
2.4. Digitala signaturer 11
de asymmetriska nycklarna. Efter att den symmetriska nyckeln distribuerats kan sedan kommunikation ske utan att drabbas av den prestandaf¨orlust det inneb¨ar att kommunicera enbart med hj¨alp av asymmetriska nycklar. Ett schema ¨over asymmetrisk kryptering ses i figur 2.6. [1,3]
Krypterad text Användare 1 Användare 2 Krypterar med nyckel A. Dekrypterar med nyckel B .
Figur 2.6: Asymmetrisk kryptering.
2.4
Digitala signaturer
Digitala signaturer anv¨ands f¨or samma ¨andam˚al som en icke digital signatur; f¨or att s¨akerst¨alla att en viss information st¨ammer och att den inte ¨andrats.
F¨or att ˚astadkomma signaturer i den digitala v¨arlden kombineras ett antal
tekniker. F¨orst kommer den mest centrala g˚as igenom, hashalgoritmer.
2.4.1
Hashalgoritmer
Hashalgoritmer anv¨ands f¨or att f¨orvandla text till ett v¨arde. Ett hashv¨arde ¨ar alltid lika l˚angt (i bitar) oberoende av vilken text som k¨ors genom algoritmen. Centralt f¨or en hashalgoritm ¨ar ocks˚a att ett hashv¨arde endast kan produc-eras av exakt samma indata, det vill s¨aga samma text1. Hashv¨ardet anv¨ands
sedan f¨or unders¨oka om en text har f¨or¨andrats under transporten. Det g¨ors p˚a en s˚adant s¨att att en person som vill skicka en text ber¨aknar textens hashv¨arde och skickar detta tillsammans med texten. Mottagaren tar sedan emot texten och ber¨aknar sedan, med samma algoritm, ett eget hashv¨arde av texten och j¨amf¨or sedan det med hashv¨ardet som s¨andaren skickade med. Om inte hashv¨ardena st¨ammer ¨overens avsl¨ojar detta att texten har f¨or¨andrats under transporten. [1,3]
Detta garanterar dock inte p˚a n˚agot s¨att att det som st˚ar i texten var det s¨andaren skrev eftersom n˚agon kan f¨or¨andrat texten under transporten,
1
Detta ¨ar inte riktigt sant, d˚a alla kombinationer av texter ¨ar fler ¨an exempelvis 32 bitar, men id´en ¨ar den att det ska vara ungef¨ar samma sannolikhet att hitta tv˚a dokument med samma hashv¨arde som att du hittar den aktuella nyckeln som anv¨ants vid signeringen.
ber¨aknat ett nytt hashv¨arde av den nya texten och sedan skickat med detta till mottagaren som d¨armed inte m¨arker att texten har f¨or¨andrats. L¨osningen p˚a detta problem ¨ar digitala signaturer.
2.4.2
Implementation av digitala signaturer
F¨or att kunna s¨akerst¨alla avs¨andaren p˚a ett meddelande anv¨ands
asym-metrisk kryptering, men inte p˚a samma s¨att som ovan n¨amnts. Ist¨allet krypter-ar avs¨andkrypter-aren hashv¨krypter-ardet av meddelandet med hj¨alp av sin privata nyckel innan hashv¨ardet och meddelandet skickas iv¨ag. Mottagaren ber¨aknar sedan precis som vanligt ett hashv¨arde av meddelandet och f¨or att kunna j¨amf¨ora
hashv¨ardet med det medskickade m˚aste mottagren dekrypteras hashv¨ardet.
Detta g¨ors med avs¨andarens publika nyckel (kom ih˚ag att det inte kallades
krypteringsnyckel). Eftersom ett nyckelpar aldrig fungerar annat ¨an ihop kommer det dekrypterade hashv¨ardet st¨amma ¨overns med det ber¨aknade endast om det ¨ar den riktiga avs¨andaren som har skickat det. Detta eftersom det endast ¨ar den riktiga avs¨andaren som kan kryptera hashv¨ardet med den nyckel som passar ihop med den publika nyckeln. [1,3]
2.5
Digitala certifikat
N¨ar en privat nyckel genereras, genereras ¨aven dess publika motsvarighet. Om sedan fel nyckel anv¨ands f¨or att kryptera ett meddelande kommer re-sultatet antingen att bli d˚aligt eller katastrofalt. Det blir ett d˚aligt resultat om mottagaren inte kan dekryptera meddelandet, men ingen st¨orre fara ¨ar skedd. Om det d¨aremot ¨ar fallet att en fiende har bytt ut den publika nyckeln mot en som matchar fiendens egen nyckel kommer information hamna i fel h¨ander och det ¨ar katastrofalt. D¨arf¨or ¨ar det viktigt att nycklar kan bindas till en viss identitet. Genom att titta endast p˚a en nyckel g˚ar det inte att p˚a n˚agot s¨att binda denna till en identitet, nyckeln best˚ar endast av en str¨ang med tecken. F¨or att l¨osa detta problem har digitala certifikat introducerats. [2]
Ett digitalt certifikat inneh˚aller dels en publik nyckel men ocks˚a infor-mation om den identitet som besitter den motsvarande privata nyckeln. In-formationen inkluderar till exempel namn, hemland och plats. Certifikatet inneh˚aller ocks˚a information om vem som utf¨ardat certifikatet, den s˚a kallade ”Certificate Authority” (CA). Vidare finns ett serienummer knutet till var-je certifikat och ¨aven information om hur l¨ange certifikatet ¨ar giltigt. Alla certifikat ¨ar sedan signerade av den CA som utf¨ardat dem. [2]
2.5. Digitala certifikat 13
Det finns ett antal olika standarder p˚a certifikat, men den som anv¨ands
inom detta projekt, och som ocks˚a ¨ar den vanligaste, heter X.509.
2.5.1
X.509
X.509-standarden p˚a certifikat kom i en f¨orsta version 1988. Efter vissa prob-lem med till exempel s¨akerhetsh˚al i f¨oreslagna algoritmer reviderades stan-darden 1993. Certifikatet inneh˚aller lite olika typer av information beroende
p˚a vilken version av standarden som anv¨ands. Den vanligaste, och ¨aven den
version som inneh˚aller mest information, ¨ar version 3. Ett X.509v3-certifikat inneh˚aller f¨oljande information:
• Version
Beskriver vilken version det aktuella certifikatet ¨ar av. • Serial number
Varje certifikat (inom en CA) har ett unikt serienummer. • Signature algorithm identifier
Den algoritm som anv¨ants f¨or att signera certifikatet. • Issuer name
Namn p˚a den CA (organisation) som utf¨ardat certifikatet.
• Period of validity
Tv˚a datum som anger under vilken period certifikatet ¨ar giltigt. • Subject name
Namnen p˚a den anv¨andare (eller det system) som certifikatet ¨ar utf¨ardad till. Det inneb¨ar att certifikatet certifierar den publika nyckel som h¨or ihop med den privata nyckel som anv¨andaren/systemet innehar. Detta namn inneh˚aller ¨aven organisationstillh¨orighet och hemland.
• Subjects public-key information
Den publika nyckeln samt information om vilken algoritm som nyckeln ska anv¨andas med.
• Issuer unique identifier
Ett f¨alt som anv¨ands f¨or att identifiera CA:n som utf¨ardat certifikatet
• Subject unique identifier
Se ovan (g¨aller dock f¨or certifikatsinnehavaren). • Extensions
Extra funktionalitet som endast finns med i version 3 av X.509. Ex-empel ¨ar alternativa namn p˚a innehavaren och anv¨andningsomr˚ade f¨or nyckeln.
• Signature
Inneh˚aller en hash av alla andra f¨alt, som sedan har krypterats med
CA:ns privata nyckel. Inneh˚aller ¨aven information om algoritmen som
anv¨ants.
2.6
Public Key Infrastructure
Digitala certifikat utf¨ardas av en CA och certifikatet ¨ar bundet till den CA:n.
Det betyder att operat¨oren av den aktuella CA:n garanterar det som st˚ar i
certifikatet. Verifikation av en identitet g¨ors dock inte av en CA utan av en s˚a
kallad ”Registration Authority” (RA). En CA och RA h¨or ¨and˚a ihop; n¨ar en
RA har verfierat en identitet instrueras den relaterade CA:n till att utf¨arda ett certifikat. F¨or att publicera certifikatet (den publika nyckeln ska kunna anv¨andas) ¨ar det i X.509-fallet vanligt att en X.500-katalogtj¨anst anv¨ands. Lightweight Directory Access Protocol (LDAP) ¨ar en vanlig katalogtj¨anst f¨or att hantera X.509-certifikat i en X.500-katalog. I de fall ett certifikat beh¨over ˚aterkallas (om till exempel den privata nyckeln relaterad till ett certifikat blivit k¨and) anv¨ands det som kallas ”Certificate Revocation Lists” (CRL), denna lista kan precis som certifikaten sparas i en katalogtj¨anst. [1,2]
Tilsammans utg¨or CA:s, RA:s, X.500-kataloger och CRL:s det som brukar kallas en Public Key Infrastructure (PKI), se figur 2.7. En s˚adan infrastruktur har hand om att utf¨arda, publicera och ˚aterkalla certifikat. [1]
2.6.1
Rotcertifikat
Rotcertifikat kallas PKI:ns egna certifikat. Detta certifikat ¨ar det som anv¨ands f¨or att signera alla andra certifikat som PKI:n tillhandah˚aller. Detta certi-fikat ¨ar sj¨alvsignerat. Det inneb¨ar att det ¨ar signerat med PKI:ns certifkat, allts˚a det aktuella certifikatet.
2.7. S¨akra Web Services 15 Signerad och krypterad data Klient Server Katalog med publika nyckar
Certificate Authority (CA) och
Registration Authority (RA)
Figur 2.7: Schema ¨over en typisk PKI.
2.7
S¨
akra Web Services
N¨ar det g¨aller s¨akerhet inom Web Services finns det huvudsakligen tv˚a v¨agar att g˚a och b˚ada baseras p˚a kryptering av kommunikationen. Den ena ¨ar att kryptera p˚a transportprotokollniv˚a och den andra ¨ar att kryptera p˚a med-delandeprotokollniv˚a. D˚a HTTP ¨ar det f¨oredragna protokollet p˚a
transport-niv˚a anv¨ands HTTPS (som ¨ar en krypterad variant av HTTP-protokollet)
f¨or kryptering. F¨or att kryptera p˚a meddelandeniv˚a har ett speciellt omr˚ade
vuxit fram inom Web Services som f˚att namnet WS-Security (Web Services
Security). WS-Security presenteras kort i f¨oljande avsnitt.
2.7.1
WS-Security
Eftersom HTTPS inte ¨ar specifikt utvecklat f¨or Web Services valde ett antal organisationer (bland annat IBM, Verisign och Microsoft) att utveckla en ny teknik f¨or s¨akerhet inom Web Services och SOAP-meddelanden. Tekniken
bygger i huvudsak p˚a tv˚a grundpelare inom XML-s¨akerhet; XML Encryption
och XML Digital Signature. ¨Aven dessa ¨ar, precis som SOAP, standarder i
W3C:s regi. Den stora f¨ordelen att anv¨anda WS-Security ist¨allet f¨or exem-pelvis kryptering p˚a en l¨agre niv˚a (HTTPS) ¨ar att det fortfarande g˚ar att
identifiera trafiken som SOAP. Detta underl¨attar inte minst f¨or filtrering av trafiken i exempelvis brandv¨aggar. [5]
XML Encryption i SOAP
F¨or att kryptera SOAP-kommunikationen mellan en Web Service och dess klient kr¨avs tv˚a nya komponenter i SOAP-meddelandet. Den f¨orsta ¨ar en s˚a kallad security header som beskriver hur meddelandet ¨ar krypterat. Den an-dra komponenten ¨ar den krypterade datan som l¨aggs i sj¨alva body-elementet.
Ett exempel p˚a ett krypterat SOAP-meddelande ses i figur 2.8. [1,5]
<!xml ... > <soap:Envelope> <soap:Header> <wsse:Security soap:actor="..." soap:MustUnderstand="..." xmlns:wsse="http://schemas.xmlsoap.org/.../secext"> <xenc:EncryptedKey xmlns:enc="..."> ... </xenc:EncryptedKey> </Security> </soap:Header> <soap:Body> <xenc:EncryptedData ... > ... </xenc:EncryptedData> </soap:Body> </soap:envelope>
Figur 2.8: SOAP-meddelande krypterat med hj¨alp av WS-Security.
XML Digital Signature i SOAP
Tekniken f¨or att signera SOAP-meddelanden ser ut p˚a ett liknande s¨att som
tekniken f¨or att kryptera. I wsse-headern beskrivs hur signaturen ¨ar utf¨ord och i samma header finns ¨aven sj¨alva signaturen med. F¨or ett exempel p˚a ett signerat SOAP-meddelande, se figur 2.9. [1,5]
2.7. S¨akra Web Services 17
<soap:Envelope> <soap:Header>
<wsse:Security>
<wsse:BinarySecurityToken ValueType= wsse:x509v3 ... > ... </wsse:BinarySecurityToken> <Signature xmlns: http://.../xmldsig#> <SignedInfo ... > ... </SignedInfo> <SignatureValue> ... </SignatureValue> <KeyInfo> ... </KeyInfo> </Signature> </wsse:Security> </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope>
Kapitel 3
XKMS - specifikation
3.1
Introduktion
Vi har i f¨oreg˚aende kapitel sett hur tekniker som kryptering och signering kan anv¨andas f¨or att konstruera s¨aker kommunikation mellan en Web Service och
dess klient. F¨or att kunna kryptera eller signera sina XML-dokument m˚aste
nycklar och annan viktig information finnas tillg¨anglig. PKI heter som bekant
den arkitektur som skapar och tillhandah˚aller denna information. N¨ar en
applikation, f¨or att f˚a reda till exempel en publik nyckel, ska kommunicera med en PKI uppst˚ar d˚a generellt sett vissa problem:
• Om inte PKI:n och applikationen ¨ar skrivna i samma programmer-ingsspr˚ak m˚aste n˚agon slags mellanhand anv¨andas f¨or att information ska kunna utbytas och anv¨andas i de b˚ada milj¨oerna.
• Om inte PKI:n och klientapplikationen befinner sig i samma datorsys-tem m˚aste n˚agon slags n¨atverkskommunikation uppr¨attas.
XKMS - eller XML Key Management Specification - ¨ar en specifikation fram-tagen av W3C vars fr¨amsta uppgift ¨ar att l¨osa dessa tv˚a problem. Genom att
basera all kommunikation p˚a XML-meddelanden l¨oses det f¨orsta problemet;
XML ¨ar ett spr˚ak som ¨ar plattforms- och programmeringsspr˚aksoberoende.
Genom att vidare specificera det hela som en Web Service l¨oses problem num-mer tv˚a; en Web Service invokeras alltid ¨over n¨atverket. Det som ¨ar viktigt att po¨angtera ¨ar att specifikationen i sig inte ¨ar n˚agon PKI, utan det hela handlar om att publicera en PKI:s tj¨anster i ett mer l¨att˚atkomligt format. Hur en XKMS Service kommer in i bilden ser vi i figur 3.1 (j¨amf¨or g¨arna denna figur med figur 2.7 i f¨oreg˚aende kapitel).
I detta kapitel ges en ¨oversikt ¨over de olika delarna i XKMS-specifika-tionen, och fr¨amst kommer de delarna som ¨ar viktiga f¨or den
Signerad och krypterad data
Klient Server
Katalog med publika nyckar
Certificate Authority (CA) och
Registration Authority (RA)
XKMS Service
Figur 3.1: PKI med XKMS Service som mellanhand.
tion som gjorts i samband med detta examensarbete belysas. Den version av specifikationen som anv¨ants ¨ar den version som sl¨apptes i mars 2001 och som
g˚ar under versionnummer 1.1. Version 2 av specifikationen har varit under
utveckling under en l¨angre tid och blev officiell i juli detta ˚ar (2005). Det be-tyder allts˚a halvv¨ags in i detta examensarbete. Varf¨or version 1 valts framf¨or version tv˚a framg˚ar n¨armre i avsnitt 4.2.1.
3.2
Uppbyggnad
XKMS-specifikationen definierar egentligen tv˚a olika Web Services. Den f¨orsta - XML Key Registration Service Specification (X-KRSS) - hanterar skapan-det och revokeranskapan-det av nycklar. Den andra - XML Key Information Ser-vice Specification (X-KISS) - hanterar information (distribution) av nycklar samt verifikation av dessa nycklar. Med verifikation menas huruvida en ny-ckel ¨ar giltig eller inte. Den kan till exempel vara revokerad eller s˚a har
3.2. Uppbyggnad 21
dess giltighetsperiod passerat. Figur 3.2 visar hur dessa tv˚a delar av XKMS
f¨orh˚aller sig till varandra. [6,7]
Signerad och krypterad data
Klient Server
Katalog med publika nyckar
Certificate Authority (CA) och
Registration Authority (RA)
XKMS Service
X-KISS X-KRSS
Figur 3.2: Schema ¨over hur XKMS tv˚a delar f¨orh˚aller sig till en PKI.
Visserligen ¨ar dessa tv˚a services skilda men det ¨ar ¨and˚a tillsammans de ska ses. Tillsammans utg¨or de ett gr¨anssnitt mot en PKI, men det ¨ar inte
n˚agon s¨arskild implementation av en PKI som det syftas p˚a, utan XKMS ska
fungera med vilken PKI det ¨an handlar om. Det ¨ar h¨ar XKMS styrka ligger;
om alla som tillhandah˚aller en PKI ¨aven tillhandah˚aller en XKMS Service
tillsammans med denna PKI, kan rent teoretiskt alla klientapplikationer som
st¨odjer XKMS kommunicera med den aktuella PKI:n. Dock ska det p˚apekas
att det finns vissa allm¨anna interoperabilitetsproblem med Web Services, men det jag kommer g˚a in p˚a i senare kapitel.
I f¨oljande avsnitt presenteras specifikationerna f¨or X-KISS och X-KRSS.
X-KISS ¨ar den mest centrala f¨or detta projekt och d¨arf¨or kommer den g˚as
3.2.1
Protokoll
XKMS-protokollet ¨ar ett fr˚aga-svar-protokoll vilket inneb¨ar att alla f¨orfr˚agningar f¨oljs av ett svar, ¨aven om det som fr˚agas efter inte kan hittas. Protokol-let bygger p˚a SOAP (vilket ¨ar ganska sj¨alvklart d˚a SOAP ¨ar defacto stan-dard n¨ar det g¨aller kommunikation mellan Web Services). Vidare delar alla f¨orfr˚agningar, oberoende av vilken operation som ¨ar aktuell, ett gemensamt format. I en f¨orfr˚agan kan ¨aven klienten specificera hur mycket data som den maximalt kan ta emot i ett svar. [6,8]
3.3
Specifikation av X-KISS
X-KISS-protokollet ¨ar uppdelat i tv˚a delar, eller metoder ¨ar ett mer korrekt namn n¨ar det g¨aller Web Services. De tv˚a metoderna ¨ar locate och validate.
Locatemetoden svarar p˚a fr˚agan ”Vilken ¨ar den nyckel som ska anv¨andas
f¨or att kommunicera med identitet X?”. Validatemetoden i sin tur svarar p˚a
fr˚agan ” ¨Ar denna nyckel ok att anv¨anda vid kommunikation med identitet
X, ¨ar den validerad?”. [1,6]
3.3.1
Locate
En locateservice fungerar ungef¨ar p˚a samma s¨att som en katalogtj¨anst. Dess uppgift ¨ar att distribuera information om nycklar. Informationen fr˚an en lo-cateservice ¨ar inte p˚a n˚agot s¨att signerad eller garanterad fr˚an servicesidan. Det ¨ar ist¨allet klientens uppgift att validera att den informationen som kom-mer fr˚an servicen st¨ammer.
Som ett resultat av detta anv¨ands oftats en locateservice f¨or att dis-tribuera information som redan ¨ar validerad som ok, till exempel X.509-certifikat som ¨ar signerade av CA:n. En f¨orfr˚agan till en locateservice in-neh˚aller ett objekt kallat KeyInfo. Objektet inneh˚aller information om en
identitet som kan knytas till en viss nyckel, eller som i det flesta fall, kan knytas till ett visst certifikat. Om sedan den information som efterfr˚agas kan hittas, returneras ¨aven ett eller fleraKeyInfo-element. Dessa element inneh˚aller
i sin tur den efterfr˚agade informationen. [1,6]
Exempel 3.1 (figur 3.3): Om Alice vill skicka ett krypterat meddelande till Bob beh¨over Alice tillg˚ang till Bobs publika nyckel. Alice skickar d˚a en locatef¨orfr˚agan till XKMS Service om att f˚a tillg˚ang till Bobs nyckel (1). I det h¨ar fallet ¨ar XKMS Service anknuten till en X.509-katalog, och som svar f˚ar d˚a Alice det X.509-certifikat som ¨ar knutet till Bob. Efter att ha h¨amtat
3.3. Specifikation av X-KISS 23
Namn Element Beskrivning
KeyName <ds:KeyName> Namnet p˚a identiteten
KeyValue <ds:KeyValue> Nyckelparametrar
X509Cert <ds:X509Data> X.509-certifikatet knutet till den aktuella identiteten Tabell 3.1: Objektet KeyInfo.
nyckeln ur certifikatet kan Alice sedan kryptera meddelandet och skicka det till Bob (2). Alice Bob XKMS Service 1 Locateförfrågan 2 Krypterat meddelande Figur 3.3: Exempel 1. Meddelandesyntax - fr˚aga
Locateservicen accepeterar som indata ett KeyInfo-objekt. En beskrivning av
de viktigaste delarna av detta objekt ˚aterges i tabell 3.1. F¨orfr˚agan kan ¨aven inneh˚alla ett objekt av typen Respond som specificerar vilket svar som
klien-ten f¨orv¨antar sig. Det kan till exempel vara ett X.509-certifikat knutet till den efterfr˚agade identiteten, men det finns ¨aven andra alternativ. Det XML-schema som definierar en ”LocateRequest” ˚aterges i figur 3.4. [1,6]
Om vi ˚aterg˚ar till exempel 1 tidigare i detta avsnitt skulle ett
SOAP-meddelande d¨ar Alice fr˚agar efter Bobs X.509-certifikat se ut som i figur
<element name="Locate"> <complexType>
<sequence>
<element name="Query" type="ds:KeyInfo"/> <element name="Respond" >
<complexType> <sequence>
<element name="string" type="string" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> </complexType> </element>
Figur 3.4: XML-schema f¨or XKMS LocateRequest.
<Locate> <Query> <ds:KeyInfo> <ds:KeyName>Bob</ds:KeyName> </ds:KeyInfo> </Query> <Respond> <string>KeyName</string> <string>X509Cert</string> </Respond> </Locate> Figur 3.5: XKMS LocateRequest. Meddelandesyntax - svar
Svaret p˚a locatef¨orfr˚agan inneh˚aller i huvudsak tv˚a element. Det f¨orsta ele-mentet ¨ar ett Result-objekt som anger hur f¨orfr˚agan har behandlats. De fyra
olika svarskoderna redovisas i tabell 3.2. [6]
Det andra elementet ¨ar ett sammansatt element av ett eller flera KeyInfo
-objekt. Dessa objekt inneh˚aller den efterfr˚agade nyckeln eller certifikatet samt namnet p˚a den identitet som ¨ar knuten till nyckeln/certifikatet. F¨oljande figurer illustrerar dels det XML-schema som svaret bygger p˚a (figur 3.6), och hur det svar ser ut som Alice f˚ar tillbaka baserat p˚a sin f¨orfr˚agan (figur 3.7). [6]
3.3.2
Validate
En locateservice tillhandah˚aller bara information om en nyckel, den s¨ager
3.3. Specifikation av X-KISS 25
Svarskod Antal element Beskrivning
Success ˚Atminstone ett element Operationen lyckades,
lokaliserade efterfr˚agad data.
NoMatch Inga element Operationen lyckades,
men ingen data hittades.
Incomplete ˚Atminstone ett element Operationen lyckades,
lyckades inte lokalisera all efterfr˚agad data.
Failure Inga element Operationen misslyckades.
Tabell 3.2: Objektet ResultCode.
<element name="LocateResult"> <complexType>
<sequence>
<element name="Result" type="xkms:ResultCode"/> <element name="Answer" >
<complexType> <all>
<element name="ds:KeyInfo" type="ds:KeyInfo" minOccurs="0" maxOccurs="unbounded"/> </all> </complexType> </element> </sequence> </complexType> </element>
Figur 3.6: XML-schema f¨or XKMS LocateResult.
som en ren distribut¨or som ¨overl˚ater allt ”jobb” med att validera nycklarna till klienten. Det existerar dock fall d˚a klienten inte sj¨alva kan validera till exempel signaturen p˚a ett certifikat; det kan vara s˚a att klienten ¨ar en mobil enhet som helt enkelt saknar resurser f¨or dessa operationer, eller ¨ar fallet att klienten inte kan h˚alla sig uppdaterad om vilka certifikat som dragits in. F¨or att l¨osa dessa fall har validatemetoden definierats. En f¨orfr˚agan till en vali-date inneh˚aller en nyckel eller ett certifikat som beh¨over valideras och svaret anger helt enkelt om det ¨ar s¨akert eller inte att anv¨anda detta certifikat. [6] Exempel 3.2 (figur 3.8): Om Alice innan hon skickar sitt krypterade
meddelande till Bob vill validera att det certifikat hon mottagit fr˚an sin
locateservice ¨ar giltigt kan hon i ett mellansteg utnyttja en validateservice f¨or att utf¨ora denna operation. Om hon f˚ar det svar hon vill ha fr˚an sin vali-dateservice (att certifikatet ¨ar giltigt) kan hon sedan i lugn och ro skicka sitt krypterade meddelande till Bob.
<LocateResult> <Result>Success</Result> <Answer> <ds:KeyInfo> <ds:KeyName>Bob</ds:KeyName> <ds:X509Cert>...</ds:X509Cert> </ds:KeyInfo> </Answer> </LocateResult> Figur 3.7: XKMS LocateResult. Alice Bob 1 Locateförfrågan 3 Krypterat meddelande XKMS Service Locate Validate 2 Validateförfrågan Figur 3.8: Exempel 2. Meddelandesyntax - fr˚aga
En validatefr˚aga kan vara v¨aldigt komplex. Den kan till exempel inneh˚alla ett tidsintervall d˚a klienten vill anv¨anda en nyckel och d˚a f˚a svar p˚a om nyckeln ¨ar giltig att anv¨anda under hela intervallet. Den kan ocks˚a inneh˚alla information om vad nyckeln ska anv¨andas till (kryptering, signering etc). Men det enda elementet som kr¨avs f¨or att f¨orfr˚agan ska kunna behandlas ¨ar ett KeyId-objekt. Objektet inneh˚aller den nyckel eller det certifikat som ska
valideras. XML-schema f¨or en validatef¨orfr˚agan ˚aterfinns i figur 3.9. [6] Om vi igen ˚aterg˚ar till exemplet med Alice meddelande till Bob skulle en f¨orfr˚agan om att validera Bobs certifikat se ut enligt figur 3.10. [6]
Meddelandesyntax - svar
Ett svar p˚a en validatef¨orfr˚agan inneh˚aller framf¨orallt ett viktigt element
3.4. Specifikation av X-KRSS 27
<element name="Validate"> <complexType>
<all>
<element name="query" type="xkms:KeyBinding"/> <element name="respond">
<complexType> <all>
<element name="string" type="s:string" minOccurs="0" maxOccurs="unbounded"/> </all> </complexType> </element> </all> </complexType> </element>
Figur 3.9: XML-schema f¨or XKMS ValidateRequest.
<Validate> <Query> <ds:KeyInfo> <ds:KeyName>Bob</ds:KeyName> <ds:X509Cert>...</ds:X509Cert> </ds:KeyInfo> </Query> </Validate> Figur 3.10: XKMS ValidateRequest.
tv˚a; Valid och Invalid. Det syftar d˚a p˚a det certifikat/den nyckel som skulle valideras. Precis som i fallet med ett locatesvar finns ¨aven det element som
anger resultatkod med, ResultCode. Nedan ˚aterges dels det XML-schema som
specificerar en ValidateRequest (figur 3.11) och det svar Alice kan f¨orv¨antas f˚a i fallet med validering av Bobs certifikat (figur 3.12). [6]
3.4
Specifikation av X-KRSS
Den andra halva av XKMS-protokollet, X-KRSS, anv¨ands f¨or att hantera nycklar. Med hantera syftas hela livscykeln f¨or en nycklar, fr˚an skapandet till ˚aterkallandet. Det till˚ater en klient att registrera ett nyckelpar s˚av¨al som det till˚ater samma klient att ˚aterkalla sitt nyckelpar. De tj¨anster som kan finnas tillg¨angliga via X-KRSS ¨ar Register, Revoke och Key Recovery. Av dessa ¨ar
det endast Register som m˚aste finnas med vid en implementation. D˚a
X-KRSS-delen av XKMS-protokollet inte ¨ar intressant i detta examensarbete kommer dessa endast g˚as igenom ¨oversiktligt.
<element name="ValidateResult"> <complexType>
<all>
<element name="Result" type="xkms:ResultCode"/> <element name="Answer" >
<complexType> <sequence>
<element name="KeyBinding" type="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element> </all> </complexType> </element>
Figur 3.11: XML-schema f¨or XKMS ValidateResult.
<ValidateResult> <Result>Success</Result> <Answer> <KeyBinding> <Status>Valid</Status> <ds:KeyInfo> <ds:KeyName>...</ds:KeyName> <ds:KeyValue>...</ds:KeyValue> <ds:X509Cert>...</ds:X509Cert> </ds:KeyInfo> </KeyBinding> </Answer> </ValidateResult> Figur 3.12: XKMS ValidateResult.
3.4.1
Register
Register Handlar om registrering av en ny identitet i PKI:n. Ett nytt nyck-elpar ska skapas och ett certifikat ska utf¨ardas. Denna procedur kan enligt specifikationen g¨oras p˚a tv˚a olika s¨att:
• Klientbaserad generering av nyckelpar • Serverbaserad generering av nyckelpar
F¨ordelen med klientbaserad generering av nyckelpar ¨ar att den privata nyck-eln aldrig beh¨over l¨amna den klient d¨ar den faktiskt ska anv¨andas. P˚a detta
s¨att undviks de distributionsproblem som uppst˚ar med centralt genererade
nycklar. Nackdelen ¨ar att det m˚aste kr¨avas en autentisering av anv¨andare i de fall d¨ar vem som helst inte ska kunna registrera sig. [1,6]
3.4. Specifikation av X-KRSS 29
3.4.2
Revoke
Revoke handlar precis som namnet antyder om revokering, eller ˚aterkallning,
av tidigare registrerade nycklar. Eftersom detta ¨ar k¨ansligt och endast ¨agaren av ett nyckelpar ska kunna utf¨ora en ˚aterkallning, kr¨avs n˚agon slags auten-tisering. I specifikationen l¨oses det genom att en revokeringsf¨orfr˚agan m˚aste vara signerad av ¨agaren till nyckelparet. [6]
3.4.3
Key Recovery
Om en anv¨andare har tappat bort sin privata nyckel kan en ”Key
Recovery”-service finnas tillhands f¨or att p˚a nytt ¨overl¨amna nyckeln. Denna del av
specifikationen ¨ar det dock upp till utvecklaren att komplettera sj¨alv. F¨orslag finns i specifikationen att n˚agon extern information skickas med i f¨orfr˚agan f¨or att p˚a s˚adant s¨att s¨akerst¨alla identiteten. Detta eftersom det av f¨orklarliga sk¨al inte kan ske en signering som i revokeringsfallet. [6]
Kapitel 4
XKMS - implementation
4.1
Uppgiftsbeskrivning
Uppgiften fr˚an FOI har best˚att av att utveckla en version av XKMS-protokollet. Tanken med denna version ¨ar att dels n¨armre kunna utv¨ardera hur protokol-let fungerar, men denna XKMS-service ¨ar ¨aven t¨ankt att anv¨andas som cer-tifikatserver i ett av institutets andra projekt. Under detta arbetes uppstart var det framf¨or allt de delar av protokollet som har hand om distribution (X-KISS/Locate) och validering (X-KISS/Validate) av certifikat som var
in-tressanta. Registrering och ˚aterkallning av nycklar (X-KRSS/Register) lades
till en b¨orjan ˚at sidan av den anledningen att FOI inte till¨ampar distribution av nya nyckelpar p˚a detta s¨att. Senare under arbetets g˚ang best¨amdes det att denna del av specifikationen (X-KRSS) inte skulle implementeras alls.
Sj¨alva huvudfunktionaliteten (lokalisering och validering) i XKMS-specifika-tionen ligger p˚a serversidan, men det finns ¨aven en klientsida att koncentrera sig p˚a n¨ar det g¨aller denna typ av fr˚aga-svars-protokoll. FOI hade h¨ar som ¨onskem˚al att ett API skulle implementeras f¨or klientsidan, d¨ar ˚atkomsten till sj¨alva XKMS-servern skulle underl¨attas f¨or utvecklare av andra applikation-er.
XKMS ¨ar t¨ankt att fungera som en gr¨anssnitt mot en PKI. I detta fall har ingen central PKI funnits att tillg˚a, utan FOI hade ist¨allet ¨onskem˚al om att denna t¨ankta PKI skulle simuleras. Exakt p˚a vilken niv˚a simuleringen skulle ligga var inte helt klart innan arbetet p˚ab¨orjades och hur ”simuleringen” l¨osts framg˚ar senare i detta kapitel.
4.1.1
Avgr¨
ansningar
XKMS-protokollet st¨odjer som bekant ett antal olika standarder f¨or certifikat och nycklar. D˚a X.509-standarden generellt sett ¨ar vanligast och den ¨ar ¨aven
s˚a inom FOI har uppgiften avgr¨ansats p˚a s˚a s¨att att den endast g¨aller den del av specifikationen som tar upp st¨od av X.509-certifikat och nycklar.
4.2
Designbeslut
Under arbetets g˚ang har ett antal ¨overv¨aganden beh¨ovt g¨oras: • Vilket tillv¨agag˚angss¨att ska anv¨andas f¨or att utf¨ora arbetet? • Vilken utvecklingsmilj¨o ska anv¨andas?
• Vilket programmeringsspr˚ak ska anv¨andas?
I detta avsnitt ska jag g˚a i p˚a de viktigaste av dessa fr˚agor. Vissa har mer sj¨alvklara svar ¨an andra som har kr¨avt l¨angre ¨overv¨aganden.
4.2.1
Val av XKMS-version
Vid starten av detta examensarbete var version 1.1 av specifikationen fort-farande den officiella versionen. Version 2 fanns f¨ardig men hade inte blivit godk¨and fullt ut av W3C. Det finns ett antal skillnader mellan version 1.1 och version 2, men de viktigaste skillnaderna ligger inte i funktionaliteten
i protokollet utan snarare har strukturen p˚a vissa av protokollets
medde-landen f¨or¨andrats. Till exempel har meddelandestrukturen f¨orberetts f¨or att kunna anv¨anda sig av autentisering i samband med vissa meddelanden. Den st¨orsta f¨or¨andringen som jag ser det ¨ar dock den f¨or¨andring av fr˚ aga-svars-protokollet som gjorts. I version 1.1 f¨oljs varje fr˚aga av ett f¨ors¨ok till svar
fr˚an servicen. Detta f˚ar den effekten att om servicen ¨ar upptagen med en
annan f¨orfr˚agan kommer det ta l¨angre tid att f˚a sitt svar ¨an om den hade varit ledig. Detta i sin tur betyder l˚anga svarstider vid stora k¨oer. I version 2 har ist¨allet m¨ojligheten att k¨oa svar lagts till. Det fungerar s˚a att om servicen ¨ar upptagen kan den informera klienten direkt n¨ar fr˚agan kommer in.
Klien-ten blir d˚a medveten om v¨antetiden och kan eventuellt forts¨atta med andra
uppgifter under tiden svaret behandlas. N¨ar sedan servicen har behandlat fr˚agan ˚aterupptar den sedan kontakten med klienten och levererar ett svar.
Dessa f¨or¨andringar av protokollet har gjorts efter utv¨arderingar av version 1.1 av protokollet. F¨or¨andringarna ¨ar i sig f¨orb¨attringar, men de har ¨aven h¨ojt
komplexitetsgraden en bit. Under detta examensarbete var fr¨amsta m˚alet att
titta p˚a just funktionaliteten av protokollet och eftersom den inte utt¨okats, fr˚an version 1.1 till version 2 har valet gjorts att anv¨anda version 1.1. Att dokumentationen av version 2 ¨ar sparsam p˚a grund av att den ¨ar s˚a ny har ocks˚a spelat in vid valet av version.
4.2. Designbeslut 33
4.2.2
Designfilosofi
Eftersom XKMS ¨ar en specifikation i sig har designen av systemet sj¨alvfallet anpassats till denna specifikation. Detta har inte l¨amnat mycket utrymme till att utnyttja n˚agon viss designfilosofi. Ist¨allet har objektorientering anv¨ants i de fall m¨ojlighet funnits. Modularitet har f¨ors¨okt uppn˚as i de fall d¨ar det har funnits utrymme, till exempel mellan k¨arnan i servicen och interaktionen med den t¨ankta PKI:n.
4.2.3
Java
FOI hade som krav att API:t p˚a klientsidan skulle skrivas i Java. P˚a server-sidan var valet av implementationsspr˚ak mer ¨oppet, men ¨aven h¨ar fanns ett ¨onskem˚al om att det skulle g¨oras i Java. Detta ledde naturligt till att Java valdes som spr˚ak p˚a b˚ada sidor om protokollet. N¨armare best¨amt har Java v1.4 anv¨ants under utvecklingen, men tester har ¨aven skett under Java v1.5 och protokollet fungerar ¨aven d¨ar.
4.2.4
Utvecklingsmilj¨
o
N¨ar det g¨aller utveckling av Web Services i Java finns det ett antal v¨agar att g˚a. Ett alternativ ¨ar att utveckla sin Web Service fr˚an grunden med hj¨alp av den HTTP-implementation som finns i Java-API:t. Detta ¨ar dock v¨aldigt
tidskr¨avande d˚a strukturen p˚a den XML som skickas ¨ar r¨att komplex, och
framf¨orallt tar det on¨odig tid att bygga upp meddelandeprotokollet. Det van-ligaste tillv¨agag˚angss¨attet ¨ar ist¨allet att anv¨anda sig av en befintlig SOAP-implementation. I stort sett alla dagens stora applikationsservrar kommer
med en SOAP-implementation f¨ardig att anv¨andas. Stora akt¨orer p˚a
mark-naden som BEA, Oracle och IBM har alla servrar med SOAP-st¨od. Problemet med dessa ¨ar att de kostar mycket pengar i drift och ink¨op. P˚a FOI har man tittat mycket p˚a de gratisvarianter som finns att tillg˚a p˚a marknaden och
deras ¨onskem˚al var att se en XKMS-implementation baserad p˚a antingen
Tomcat/Axis eller Systinet/WASP.
Axis ¨ar ett till¨agg till den popul¨ara Open source applikationsservern
Tom-cat. Axis utvecklas precis som Tomcat av Apache Foundation. B˚ade Tomcat
och Axis ¨ar helt gratis att anv¨anda b˚ade f¨or utvecklingssyften och
kom-mersiella diton. Systinets Java Server (eller WASP som tidigare versioner kallades) ¨ar en applikationsserver med inbyggd support f¨or Web Services. Denna server ¨ar dock endast gratis f¨or utvecklingssyften.
Systinets server kom ¨aven med ett utvecklingspaket som bland annat inneh¨oll en plugin till Javaeditorn Eclipse. Detta samt ett b¨attre st¨od f¨or att
generera kodskelett utifr˚an WSDL-filer gjorde till slut att beslutet f¨oll p˚a Systinets Java Server v5.
4.3
Server
I detta kapitel kommer inte en fullst¨andig design med alla klasser och dess egenskaper att ˚aterges. Ist¨allet kommer fokus ligga p˚a de centrala delarna av XKMS-servern. Vidare information om klasser och metoder samt fullst¨andiga WSDL-definitioner finns i bilagorna till rapporten.
4.3.1
Arkitektur
Eftersom en Web Service egentligen ¨ar uppdelad efter olika metoder gjordes en s˚adan uppdelning p˚a serversidan precis som specifikationen f¨oreskriver.
En klass (KeyManagementPortTypeImpl) med tv˚a metoder (Locate och
Val-idate) skapades f¨or att motsvara funktionaliteten i XKMS-specifikationen.
N¨ar det g¨aller modulariteten valdes tv˚a huvudmoduler, en som motsvarar
XKMS-logiken och en som tar hand om kopplingen mot den bakom t¨ankta PKI:n. Figur 4.1 ger en ¨oversikt ¨over hur dessa moduler f¨orh˚aller sig till
app-likationsservern, klienten och till varandra. PKIHandler-modulen g˚as igenom
senare i detta kapitel, d¨aremot tittar vi n¨armre p˚a Locate och Validate nedan.
Systinet Server
Web Service container
XKMS
Service PKIHandler med nycklarKatalog
SOAP Klient
4.3. Server 35
4.3.2
Locate
Locate ¨ar den metod som svarar p˚a en f¨orfr˚agan efter ett certifikat knutet
till en viss identitet. Eftersom denna implementation fokuserar p˚a
X.509-certifikat syftar identiteten i detta fallet p˚a innehavaren av ett visst
certi-fikatet. Som indata till en LocateQuery f˚as en struktur som heter
Locate-Type. LocateType best˚ar i sin tur av tre undertyper. Av dessa tre ¨ar det
en struktur vid namn KeyInfoType som ¨ar intressant. KeyInfoType ¨ar den typ som inneh˚aller identiteten, eller namnet, p˚a den nyckel/det certifikat
som efterfr˚agas. Som svar ges ett Answer-objekt som inneh˚aller dels hela
X.509-certifikatet knutet till identiteten, samt sj¨alva nyckeln extraherad ur det efterfr˚agade certifikatet.
Som en j¨amf¨orelse med Exempel 3.1 fr˚an f¨oreg˚aende kapitel visas nedan, i figur 4.2 respektive i figur 4.3, hur de SOAP-meddelanden som det im-plementerade XKMS-protokollet producerar ser ut. Av utrymmessk¨al visas
inte meddelandet komplett, men alla meddelanden ˚aterfinns i sin fulla form
i bilaga C. <?xml version="1.0" encoding="UTF-8"?> <e:Envelope xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:d="http://www.w3.org/2001/XMLSchema" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:wn0="http://www.w3.org/2000/09/xmldsig#" xmlns:wn1="http://www.xkms.org/schema/xkms-2001-01-20"> <e:Body> <wn1:Locate i:type="wn1:LocateType"> <wn1:Query i:type="wn1:KeyInfoType"> <wn0:KeyInfo i:type="wn0:KeyInfoType"> <wn0:KeyName i:type="d:string">Bob</wn0:KeyName> </wn0:KeyInfo> </wn1:Query> </wn1:Locate> </e:Body> </e:Envelope> Figur 4.2: XKMS LocateRequest.
4.3.3
Validate
Validate-metoden p˚aminner i uppbyggnaden om Locate. F¨or att skicka med
det certifikat som ska valideras anv¨ands strukturen ValidateType, som i
sin tur best˚ar av en KeyBindingType. I metoden anropas via PKIHandlern
klassen CertValidation som i sin tur har hand om sj¨alva valideringen.
Om vi igen j¨amf¨or med motsvarande exempel fr˚an f¨oreg˚aende kapitel
<?xml version="1.0" encoding="UTF-8"?> <e:Envelope xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:d="http://www.w3.org/2001/XMLSchema" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:wn0="http://www.w3.org/2000/09/xmldsig#" xmlns:wn1="http://www.xkms.org/schema/xkms-2001-01-20"> <e:Body> <wn1:LocateResult i:type="wn1:LocateResultType"> <wn1:Result i:type="wn1:ResultCodeType">Success</wn1:Result> <wn1:Answer i:type="wn1:LocateResultAnswerType"> <wn0:KeyInfo i:type="wn0:KeyInfoType"> <wn0:KeyName i:type="d:string">Alice</wn0:KeyName> <wn0:KeyValue i:type="wn0:KeyValueType"> <wn0:RSAKeyValue i:type="wn0:RSAKeyValueType"> <wn0:Modulus i:type="wn0:CryptoBinary"> AMg18... </wn0:Modulus> <wn0:Exponent i:type="wn0:CryptoBinary">AQA...</wn0:Exponent> </wn0:RSAKeyValue> </wn0:KeyValue> <wn0:X509Data i:type="wn0:X509DataType"> <wn0:X509Certificatei:type="wn0:CryptoBinary"> MIIDuDC... </wn0:X509Certificate> </wn0:X509Data> <wn0:PGPData i:nil="true"/> <wn0:SPKIData i:nil="true"/> <wn0:MgmtData i:nil="true"/> </wn0:KeyInfo> </wn1:Answer> </wn1:LocateResult> </e:Body> </e:Envelope> Figur 4.3: XKMS LocateResult.
SOAP-meddelanden ser ut.
4.4
Klient
Klientdelen av XKMS-protokollet har handlat om att implementera ett l¨att-arbetat API f¨or att koppla upp sig och utnyttja XKMS-serverns tj¨anster. Grundtanken med API:t ¨ar ett centralt objekt som kallas XKMSClient som ska motsvara en XKMS Service tj¨anster. Vidare har API:t ut¨okats med yt-terligare funktionalitet i form av cachning av nycklar. Ett testprogram f¨or att snabbt kunna avg¨ora om en serverinstallation lyckats har ¨aven skapats. Detta program anv¨ander i sin tur API:t f¨or att visa hur API:t kan nyttjas.
4.4. Klient 37 <?xml version="1.0" encoding="UTF-8"?> <e:Envelope xmlns:e="http://schemas.xmlsoap.org/soap/envelope/" xmlns:d="http://www.w3.org/2001/XMLSchema" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:wn0="http://www.w3.org/2000/09/xmldsig#" xmlns:wn1="http://www.xkms.org/schema/xkms-2001-01-20"> <e:Body> <wn1:Validate i:type="wn1:ValidateType"> <wn1:Query i:type="wn1:KeyBindingType"> <wn0:KeyInfo i:type="wn0:KeyInfoType"> <wn0:X509Data i:type="wn0:X509DataType"> <wn0:X509Certificate i:type="wn0:CryptoBinary"> MIIDt... </wn0:X509Certificate> </wn0:X509Data> </wn0:KeyInfo> </wn1:Query> </wn1:Validate> </e:Body> </e:Envelope> Figur 4.4: XKMS ValidateRequest.
4.4.1
API
I detta avsnitt kommer en ¨oversikt ¨over API:t att ges. Det kommer ¨aven ges
kodexempel p˚a hur ett klientobjekt skapas och hur det anv¨ands f¨or att
in-vokera metoder p˚a XKMS-servern. XKMSClient-objektet kan sammanfattas
i f¨oljande metoder:
• setupWASPConnection
Kopplar upp sig mot XKMS-servern. Verifierar med hj¨alp av serverns WSDL-fil om servern st¨odjer de metoder och datatyper som kr¨avs. • locate
Utf¨or en locatef¨orfr˚agan mot servern. Som indata tas en str¨ang som
beskriver namnet p˚a den identitet som efterfr˚agas. • validate
Utf¨or en validatef¨orfr˚agan mot servern baserat p˚a det X.509-certifikat som ges som indata.
• addToCache
N¨ar ett certifikat knutet till en viss identitet h¨amtats kan detta certi-fikat sparas undan lokalt hos klienten i en cachefil. Detta ¨ar inte funk-tionalitet som kr¨avs i specifikationen utan ett extratill¨agg f¨or att g¨ora API:t mer l¨attanv¨ant.
