Mr. Abdelkrim Boujraf, Unisys Mr. Andreas Schaad, SAP Research

1. R4eGov Inter-Agency Collaboration– Security Performance Measurement Mr. Abdelkrim Boujraf, Unisys Mr. Andreas Schaad, SAP Research Mr. Mohammad Ashiqur Rahaman, SAP Research funded by EU Integrated Project R4eGov

2. AGENDA R4eGov Inter-agency collaboration WS Performance Criteria Evaluating WS * vs. SOAP Accounts Evaluation Results

3. The problem…. • The majority of eGovernment systems is and may have to remain heterogeneous. • Their configuration and definition of processes is likely to remain under local administration. • eGovernment interoperability in the EU follows an ad hoc approach and systems are only made interoperable when there is a shared purpose and some general legal guidelines. • We believe the majority of systems to require the methodologies, systems and tools for achieving the maturity level of collaborative organisations. * Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

4. EU Interagency Collaboration - The reality…. • During a routine check Spanish customs intercept a shipment of coffee containing cocaine in the harbour of Malaga. • The container came from Caracas, Venezuela and was supposed to be transported by road to Antwerp and to be delivered to a trade company called BE. • A number of persons are taken into custody, whilst investigations start….. • The involved authorities (Europol and Eurojust)* need to collaborate in a quick and efficient manner. • European Arrest Warrant • Rogatory Letter • Joint Investigation Teams • …. • They need to remain in control of their systems • They need to follow local as well as EU-wide laws and agreements * Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

5. Requirements • Local case management • Exchange of documents • Access Control on documents • Traceability • Chain of evidence • European and Local Directives on Data Usage • Collaboration agreements Can in parts be addressed by using OASIS WS* standards.

6. Claims Security Token Claims Security Token Security Token Claims General WS Security Setup WS-Policy describes the capabilities and constraints on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms) Policy Security Token Service WS-Trust describes a framework for trust models that enables Web services to trust other domains Policy Policy Requester Web Service WS-SecureConversation describes how to manage and authenticate a series of message exchanges WS-Security attaching signature and encryption headers / security tokens to SOAP messages e.g. X.509 certificates and Kerberos tickets, to messages

7. Performance / A general Web Service invocation flow • Some Performance Relevant Criteria (incomplete) • Methods for issuing, renewing, and validating security tokens; • Establishing security contexts for a conversation of messages. • Amending, Renewing, and cancelling the security contexts. • Computing and passing derived keys and session keys. • Verify Subjects / Security Attributes

8. Approach to Performance Measurement • Our Problem: • What can we measure performance against? • No real benchmarks for WS* Performance Measurement. • Our Approach: • Build our own solution for defined purpose scope • Measure WS* key performance indicators against this • Our (simplified) requirements: • Preservation of message confidentiality / integrity • Handling of complex / large messages • Focus on prevention of XML re-writing attacks • Our Proposal: • SOAP Account: Keeps record of SOAP message structure / elements. • Requires small component to be deployed on each SOAP processing node.

9. SOAP Account: Message flow in the proposed technique

10. A SOAP request using a SOAP Account RST token is signed <Envelope>…… <Header> <Security> <BinarySecurityToken Id=" Id-2" ValueType="...X509v3"> MIIEZzCCA9CgAwIBAgIQEmtJZc0...</BinarySecurityToken> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="..xml-exc-c14n#"/> <SignatureMethod Algorithm="...#rsa-sha1"/> <Reference URI="#Id-1"> <DigestMethod Algorithm="...#sha1"/> <DigestValue>d5AOd..=</DigestValue> </Reference> <Reference URI="#Id-2>...</Reference> <Reference URI="#Id-3>....</Reference> </SignedInfo> <SignatureValue>e4EyW...=</SignatureValue> <KeyInfo><SecurityTokenReference><Reference URI="#Id-2" ValueType="...#X509v3" /></KeyInfo> SOAP Account added <SoapAccount Id=”#Id-3”> <NoChildOfEnvelope>2</> <NoOfHeader>2</> </SoapAccount> Receiver can verify <Body Id="Id-1"> <RequestSecurityToken> <TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct </TokenType><RequestType>http://schemas.xmlsoap.org/ ws/2004/04/security/trust/Issue </RequestType> <Base>...</Base> </RequestSecurityToken> </Body>

11. Simulated SOAP, WS Policy, SOAP Account SOAP Account SOAP • <SoapAccount Id=”#Id-3”> • <NoOfHeader>2</> • </SoapAccount> • <Envelope> • …… • <Header> • <Security> • <BinarySecurityToken Id=" Id-2" ..> • ...</BinarySecurityToken> • <Signature> • <SignedInfo> • …… • <Reference URI="#Id-1"> • …..</Reference> • <Reference URI="#Id-2”> • ....</Reference> • </SignedInfo> • <SignatureValue>e4EyW...= • </SignatureValue> • <KeyInfo>…</KeyInfo> • <Body Id="Id-1"> • <RequestSecurityToken> • <TokenType>http://schemas.xmlsoap • .org/ws/2005/02/sc/sct • </TokenType> • <RequestType>http://schemas.xml • soap.org/ ws/2004/04/security • /trust/Issue </RequestType.. </RequestSecurityToken> 197 bytes WS Policy • <wsp:Policy …..> ….. • <sp:SignedParts> • <sp:Body/> • </sp:SignedParts> • </wsp:Policy> 388 bytes 2695 bytes to 51551 bytes

12. xmlRewriting Attack Detection Time Comparison xmlRewritngAttackDetectionTimeUsing Policy xmlRewitingAttackDetectionTimeUsingSoapAccount 35 30 25 Results/Chart 20 15 10 5 0 Received Soap size With Soap Account(Bytes) Performance Criteria 1. SOAP Account Processing. 2. Policy processing. 3. Signature Processing. 4. Attacker Simulation Comparison Criteria • Request SOAP size vs. requestor Soap Account header size and Policy file size. • SOAP Account size vs. Policy file size. • Relative comparison of signature processing in both ends. • Enforcement time of SOAP Account and Policy in sender (requestor). • Enforcement time of SOAP Account and Policy in the receiver. • XML rewriting attack detection time using SOAP Account and Policy. SOAP Size 2695 to 51551 bytes SOAP Account 197 bytes ~0.72% of SOAP Policy File 388 bytes ~1.42% of SOAP Scalability. ~15% more time in the Requestor Comparable enforcement time for both in the Requestor. • ~30% less Enforcement time using SOAP Account in the Receiver. • SOAP size > 4500 bytes..SOAP Account Enforcement Time ~ Policy Enforcement Time. ~1.50 % faster XML Rewriting Attack Detection using SOAP Account. SOAP Account is scalable. ~15% less time in the Receiver

13. Summary & Conclusion • We presented a „real-world“ collaboration scenario and security requirements • WS* can be deployed to satisfy some of these requirements • WS* Security performance indicators • Measure these indicators against our own SOAP account solution • In summary, our solution is more performant due to being purpose-built for avoiding XML rewriting attacks (overly simplified). • Not really „scientific“ approach but valuable lessons learnt on: • Establishing a set of Security / Web Service Performance Indicators • Implementation and Setup, Memory Consumption, Processing, Key Generation, Validation, Message Sizing etc. • Current research work is focusing on XACML testing • Overall goal is a general test tool suite for standards evaluation

14. Thank You & Questions abdelkrim.boujraf@be.unisys.com andreas.schaad@sap.com mohammad.ashiqur.rahaman@sap.com * Europol and Eurojust are SAP EU project partners but not SAP or Unisys customers. The case study is for illustration / requirements engineering purposes only.