An Overview and Evaluation of Web Services Security Performance Optimizations Robert van Engelen & Wei Zhang Department of Computer Science Florida State University 9/24/081IEEE ICWS 2008

Presentation Overview  Web services security (WS-Security) protocol  WS-Security processing performance issues  WS-Security operations breakdown and analysis  Performance enhancements  Impact on performance of security token choices  C14N-based optimizations  Streaming versus buffering techniques  Digest-based caching strategies  Prehashing optimizations  Performance results  Conclusions 9/24/082IEEE ICWS 2008

WS-Security 9/24/08IEEE ICWS  Essential component of the WS stack  Based on open standards  XML-dsig  XML-enc  Provides end-to-end security solution for messaging  Integrity  Confidentiality  Authentication (+ non-repudiation, replay attack protection)  Secures all or specific parts of an XML message

Related Work 9/24/08IEEE ICWS  [Shirusamaet al., 2004]  Reports as much as 100x slowdown when using WS-Security for SOAP/XML messaging in Grid systems  [Makino et al., 2004]  Sender-side WS-Security streaming techniques (DOM’less solution)  [Chen et al., 2007] and [Liu et al., 2005]  Compare WS-Security to non-secure messaging using various messages and message sizes, also showing significant impact  [Juric et al., 2006]  Compare WS-Security impact with SOAP/XML against RMI and EMI-SSL messaging  [Lu et al., 2005]  Receiver-side streaming model for signature validation with C14N  [Suzumura et al., 2005] and [Abu-Ghazaleh et al., 2005]  Differential (de)serialization techniques

TLS versus WS-Security 9/24/08IEEE ICWS  Transport-layer security (TLS)  Transport-layer encryption and peer authentication  Example: HTTPS  Pro: encryption is fast:  TLS negotiation for key exchange of ephemeral symmetric key  Symmetric key speeds up encryption significantly  Pro: peer authentication is fast  WS-Security message-level security  Encryption, integrity, authentication, non- repudiation  Cons: message encryption and signing are slow:  No ephemeral symmetric key (no handshake mechanism!)  Multi-pass operations over XML for encryption and signing of elements  Pro: end-to-end security

TLS versus WS-Security Round-Trip Messaging Performance 9/24/08IEEE ICWS TLS (XML+C14N) WS-Security (HMAC sign+auth) WS-Security (DSA/RSA sign+auth) Better performance Transport WS-Security operations

WS-Security Signatures 9/24/08IEEE ICWS XML elements to be signed are first normalized  C14N XML-exc canonicalization standard  Ensures that any XML reformatting does not change signature  Receiver must re-canonicalize the elements to verify signature 2. Then a hash digest value (typically SHA1) is computed for each XML element and its content to be signed 3. The set of hash digest values are put in a “signedInfo” element in the signature 4. The “signedInfo” element is hashed and signed using a security token based on choice of RSA, DSA, or HMAC 5. Operations for sender and receiver are the same (except receiver verifies the signature)

WS-Security Signature Example 9/24/08IEEE ICWS 20088

WS-Security Choice of Security Tokens 9/24/08IEEE ICWS  HMAC security tokens based on symmetric (shared) keys  Pro: fast  Cons: peers must keep a shared secret  RSA/DSA security tokens based on asymmetric keys  Pro: based on well-established PKI with private and public keys  Cons: slow (up to 10x)  For efficiency should consider special mechanisms for shared key establishment to support HMAC  WS-SecureConversation language can be used to establish and share security contexts  Password-authentication-based schemes often allow “shared secrets”, e.g. a hash of password for password verification

WS-Security HMAC Signature and Digest Authentication Time Breakdown 9/24/08IEEE ICWS XML Canonicalization XML Re-Canonicalization Parsing & Deserialization Serialization & SOAP composition

C14N Optimizations 9/24/08IEEE ICWS  [Lu et al., 2005]: a streaming model for signature validation  Optimize C14N re-canonicalization phase by passing inbound XML through a “streaming re-canonicalizer”  Avoids DOM storage and re-canonicalization pass (saves 12%) DOM Verify signature Re-canonicalize XML (signed) XML processor C14N streamer Verify signature XML (signed) XML processor Streaming model Standard model

C14N Optimizations (cont’d) 9/24/08IEEE ICWS  A retry model re-canonicalizes only on failure (saves <12%)  Assumes majority of cases XML is already canonicalized  Re-canonicalize only when signature verification failed DOM Verify signature Re-canonicalize XML (signed) XML processor Verify signature XML (signed) XML processor Retry model Standard model DOM Re-canonicalize

C14N Optimizations (cont’d) 9/24/08IEEE ICWS  Eliminate C14N requirements (saves 26%)  Pro: sending is faster (saves 14%)  Pro: receiving is faster (saves 12%)  Pro: lower memory requirements (no DOM)  Cons: not possible when XML is changed by intermediaries  Cons: creates tighter coupling between sender and receiver Verify signature XML (signed) XML processor Create signature XML XML processor XML (signed)

Streaming versus Buffering 9/24/08IEEE ICWS  To produce a signature, sender must process the message twice!  First pass: determine signed elements in body and put signature in header  Second pass: send header followed by body  Sender can:  Stream: serialize message twice (first sign and then send)  Buffer: serialize message once (sign and send buffered content)

Digest-Based Caching Optimizations 9/24/08IEEE ICWS  [Suzumura et al., 2005] and [Abu-Ghazaleh et al., 2005] propose differential deserialization techniques  Retrieved objects (deserialzed from XML) are kept in a cache  Inbound XML is matched against object fingerprint (hash value)  A match avoids deserialization by copying the object from cache  Can use a similar approach by storing previously parsed signed elements and deserialized content in a cache  Hash value (digestValue) already in signature!  Pro: comparing hashes is efficient and suffices to retrieve data  But performance gain is small or non-existent (saves <5%)  Cons: deserialization overhead is not critical

Prehashing Optimizations 9/24/08IEEE ICWS  Prior to sending, objects are serialized in XML and hashed  Kept in a cache with SHA1 hash value  Pro: saves hashing and serialization time  Cons: memory overhead  Improves performance for messages with lots of individually signed elements  Performance gain for body-signed messages is small or non-existent  Also serialization overhead may be low in some cases (<2.2%)

Performance of Sender-Side C14N Optimization 9/24/08IEEE ICWS C14N overhead when signing each array element C14N overhead when signing one element (Body) Signing the Body instead of all array XML elements is faster Performance of message construction and signing using WS-Security on messages with arrays of objects

Performance of Receiver-Side C14N Optimization 9/24/08IEEE ICWS C14N overhead when verifying each array element C14N overhead when verifying one element (Body) Performance of message parsing and signature verification using WS-Security on messages with arrays of objects Verifying the Body instead of all array XML elements is faster

Performance of Sender-Side Optimizations 9/24/08IEEE ICWS Streaming can be slower! Streaming is faster with prehashing Signing one element (Body) No signature (base line) Performance of message construction and signing using WS-Security on messages with arrays of objects

Performance of Receiver-Side Optimizations 9/24/08IEEE ICWS Verifying one element (Body) No signature (base line) Digest-based caching (100% hit rate) Verifying each array element Performance of message parsing and signature verification using WS-Security on messages with arrays of objects

Conclusions 9/24/08IEEE ICWS  WS-Security is still much slower than TLS-based security  Factor 2 to 10x slower for the best cases with HMAC tokens  Up to 100x slower with DSA/RSA tokens  Biggest performance gain results from HMAC tokens  C14N optimizations have the next biggest impact  Streaming and retry-based models  Differential techniques have the lowest impact  Deserialization time not critical  Memory overhead of caching  If possible, sign fewer elements in the message  Remember: nested elements are signed too  Only sign the SOAP Body when permissable