Distributed Systems Security Protocols (Application Layer) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck https://www.itm.uni-luebeck.de/people/fischer
Overview Security on the Application Layer Mostly message-based security Example: Email Basics of Email (Format, MIME, SMTP) System Examples: PGP and S/MIME Example: XML Messaging / Web Service Security XML Encryption and XML Signature WS-Security Security - 07c Network and Transport Layer #2
SMTP and Email Security Basics Security - 04 Cryptology #3
Security - 04 Cryptology #4 SMTP Basics Mail client (MUA, mail user agent) sends a mail to its mail server (MSA, mail submission agent) MSA delivers mail to mail transfer agent (MTA) MTA look up the mail exchanger record (MX record) for the recipient's domain Forwards mail to destination MTA Destination MTA forwards mail to mail delivery agent (MDA) Saves the message in the recipients mailbox Clients use IMAP, POP, web interfaces, etc. to receive emails MUA MSA MTA MTA MDA MUA SMTP SMTP POP, IMAP,...
Email Message Format Simple, text-based format Message comprised of headers and body Header Blank line Body From: Dennis Pfisterer <XXXXXX@itm.uniluebeck.de> To: XXXXXX@informatik.uni-luebeck.de Subject: HiWi Job zu vergeben Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit [...more headers...] Hallo allerseits, [...] Viele Grüße, Dennis Security - 04 Cryptology #5
Email Message Format: Issues Only supports 7-bit ASCII characters What about other characters? What about binary data? Traditional solution: Base64 encoding (increases size by ~30%) Solution: Multipurpose Internet Mail Extensions (MIME) Defined in RFC 5322 MIME extends the email format to support Non-ASCII characters (body and headers) Message body comprised of multiple parts Security - 04 Cryptology #6
Security - 04 Cryptology #7 MIME Headers MIME defines new headers Inform receivers about the content type and format of messages Indication that the MIME format is used Header MIME-Version: 1.0 is present Identification of the content type Comprised of a type and subtype E.g. Content-type: text/plain; charset=iso-8859-15 Identification of the content encoding during transfer 7bit for standard SMTP or 8bit for extended SMTP quoted-printable : encodes non-printable characters (e.g., Universit=E4t zu L=FCbeck ) Base64 : content is Base64-encoded E.g., Content-Transfer-Encoding: quoted-printable
Security - 04 Cryptology #8 MIME Types RFC 2046 defines a set of major and minor types for different types of content Originally only intended for the Content-Type header field Today, the MIME-type is used in many different contexts File Extensions.htm.html.txt.gif.png.jpg.jpeg.gz.ai.eps.ps.exe.bin.zip.avi.pdf MIME Content Type text/html text/plain image/gif image/png image/jpeg application/x-gzip application/postscript application/octet-stream application/x-zip-compressed video/x-msvideo application/pdf Important major types Text, Image, Audio, Video Application Multipart Message.doc.docx application/msword.js text/javascript.qt.mov video/quicktime.mpeg.mpg.mpe video/mpeg.wav audio/x-wav.rtf application/rtf
Security - 04 Cryptology #9 MIME Type multipart Allow messages to be composed of several parts Major type multipart supports a variety of different minor types multipart/alternative Allows the same content to be represented in different formats (e.g., text/plain and text/html) Only the most suitable one is shown to the user multipart/digest Groups multiple text messages into one email document multipart/mixed Allows an email to be composed of multiple parts with different content types multipart/related Each part is a component of an aggregate whole E.g., HTML-email (text/html) plus referenced images (text/jpg)
MIME Type multipart Parts are separated by boundaries Boundary ID specified in the contenttype header Individual parts are separated with boundary lines Start of a part: -- + Boundary ID After last part -- + Boundary ID + -- Multiparts may be nested MIME-Version: 1.0 From: Dennis Pfisterer <XXXXXXX@itm.uniluebeck.de> To: Dennis Pfisterer <XXXXXXX@itm.uni-luebeck.de> Content-Type: multipart/alternative; boundary= boundary" This is a multi-part message in MIME format. --boundary Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Das ist eine Testmail. --boundary Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Example multipart/alternative on the first level to allow for non-html MUAs multipart/related on the second level to include images referenced in the HTML document <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso- 8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> Das ist eine Testmail. </body> </html> --boundary-- Security - 04 Cryptology #10
Security - 04 Cryptology #11 Example: Nested multiparts From: Dennis Pfisterer <XXXXXX@itm.uni-luebeck.de> MIME-Version: 1.0 To: Dennis Pfisterer <XXXXXXX@itm.uni-luebeck.de> Subject: Testmail mit Bild Content-Type: multipart/alternative; boundary= 070705070901090202020705" This is a multi-part message in MIME format. --070705070901090202020705 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --060002020904090506090804 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit <html><head><meta http-equiv="content-type" content="text/html; charset=iso-8859-1"></head> <body bgcolor="#ffffff" text="#000000"> Das ist eine Testmail mit Bild. <br><br> <img src="cid:part1.08090308.02040507@itm.uniluebeck.de"><br><br> </body> </html> Das ist eine Testmail mit Bild. --070705070901090202020705 Content-Type: multipart/related; boundary= 060002020904090506090804" [...] --070705070901090202020705-- --060002020904090506090804 Content-Type: image/png; name="logoitm.png" Content-Transfer-Encoding: base64 Content-ID: <part1.08090308.02040507@itm.uni-luebeck.de> Content-Disposition: inline; filename="logoitm.png" ivborw0kggoaaaansuheugaaasaaaabxcayaaack05hn AAAAAXNSR0IArs4c6QAAAAZiS0dE [...] +yygtayedap/dxjmkwtsbjanaaaaaelftksuqmcc --060002020904090506090804--
SMTP Protocol Text-based, human-readable protocol Client issues commands, server responds with status code and human-readable description Initially, the client sends a HELO command (e.g., HELO example.com) and server replies (e.g., 250 itm01.itm.uniluebeck.de) SMTP sessions consists of zero or more SMTP transactions Each transaction comprises a sequence of MAIL, one or more RCPT, and one DATA command After the DATA command, the email is sent Finalized by a blank line with. Security - 04 Cryptology #12
SMTP Protocol Example Client initially performs a HELO handshake Client then communicates sender, recipient, and message 220 itm01.itm.uni-luebeck.de ESMTP Postfix (Debian/GNU) HELO example.com 250 itm01.itm.uni-luebeck.de MAIL FROM: XXXXXXX@itm.uni-luebeck.de 250 2.1.0 Ok RCPT TO: XXXXXX@itm.uni-luebeck.de 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> From: Dennis Pfisterer <XXXXXXX@itm.uni-luebeck.de> To: XXXXXX@informatik.uni-luebeck.de Subject: HiWi Job zu vergeben Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hallo allerseits, [...] Viele Grüße, Dennis. 250 2.0.0 Ok: queued as 8664783F8E1 quit 221 2.0.0 Bye Security - 04 Cryptology #13
Security - 04 Cryptology #14 SMTP Protocol Example Example shows received message at the client Contains more / different headers than the original message Headers are modified by transit systems E.g., to support debugging or to add antispam headers Return-Path: <XXXXXXX@itm.uni-luebeck.de> X-Original-To: XXXXXXX@itm.uni-luebeck.de Delivered-To: XXXXXXX@itm.uni-luebeck.de Received: from example.com (localhost.localdomain [127.0.0.1]) by itm01.itm.uni-luebeck.de (Postfix) with SMTP id 8664783F8E1 for <XXXXXXX@itm.uni-luebeck.de>; Mon, 18 Jun 2012 11:05:03 +0200 (CEST) From: Dennis Pfisterer <XXXXXXX@itm.uni-luebeck.de> To: XXXXXX@informatik.uni-luebeck.de Subject: HiWi Job zu vergeben Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20120618090511.8664783F8E1@itm01.itm.uniluebeck.de> Date: Mon, 18 Jun 2012 11:05:03 +0200 (CEST) Hallo allerseits, [...] Viele Grüße, Dennis
ESMTP Extensions Instead of sending HELO, clients send EHLO (Extended HELLO) Servers supporting ESMTP answer with a list of supported extensions ip2.rz.uni-luebeck.de EHLO example.com 250-ip2.rz.uni-luebeck.de 250-8BITMIME 250 SIZE 52428800 itm01.itm.uni-luebeck.de EHLO example.com 250-itm01.itm.uni-luebeck.de 250-PIPELINING 250-SIZE 200000000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN Servers not supporting ESMTP answer with an error code Server not supporting ESMTP EHLO example.com 502 5.5.2 Error: command not recognized Security - 04 Cryptology #15
ESMTP Extension: STARTTLS Generic extension to plain text protocols Method to upgrade existing, unsecured connections to TLS protected ones Allows offering the same service unencrypted and encrypted on the same port (e.g., 25 for mail) Protocol remains unchanged after the initial upgrade Defined for many well-known protocols SMTP (RFC 3207) IMAP and POP3 (RFC 2595) XMPP (RFC 3920) LDAP (RFC 2830) NNTP (RFC 4642) 220 mail.example.org ESMTP service EHLO example.org 250-mail.example.org welcomes you 250 STARTTLS STARTTLS 220 Go ahead <client and server TLS negotiation> EHLO example.org... Unmodified protocol over secure TLS connection Security - 04 Cryptology #16
ESMTP Extension: STARTTLS for SMTP Mostly used for MUA MTA interactions i.e., clients sending mail Due to spam issues, many MTAs only accept mail for the served domain or require clients to authenticate before relaying mail Often, authentication involves transmission of the password in plain text Requires a safe communication channel Often provided using TLS and the STARTTLS extension of SMTP Security - 04 Cryptology #17
Email Security: Motivation Data passed in plaintext between SMTP servers No protection of confidentiality, integrity, and authenticity Sender Often TLS secured and authenticated No confidentiality, no authenticated connections Data processed on untrusted systems Receiver Sender SMTP Organization Outgoing SMTP Intermediate SMTP Organization Incoming SMTP SPAM Filter Appliance Receiver SMTP Security - 04 Cryptology #18
Security Objectives for Email Which security objectives are important for email? Confidentiality? Authenticity? Integrity? Non-Repudiation? Access Control? Availability? Typically implemented security objectives Confidentiality End-to-end encryption Integrity Avoid undetected changes Authenticity Detect forged emails Non-Repudiation Requires electronic signatures Security - 04 Cryptology #19
Pretty Good Privacy (PGP) Security - 04 Cryptology #20
Pretty Good Privacy Pretty Good Privacy (PGP) First Release by Phil Zimmermann (1991) For practical and simplified use of strong cryptography Designed for confidential and authenticated email Extended for securing documents and network traffic... SET PGP Kerbero s HTTP IP / IPSec SMTP S/MIM E PGP initially limited to the US Due to laws limiting export of weapons Code published as a book and sold world-wide (freedom of speech) Text was scanned and OCRed by volunteers PGPi Since 1998 OpenPGP is standardized by the IETF [rfc4880-2007] An open source implementation of OpenPGP is Security - 07b Application Layer #21
Pretty Good Privacy A user owns one or multiple asymmetric key pairs Users claim to own a certain public key Public & Private Key Pair... Public & Private Key Pair PGP doesn t use a classical public key infrastructure to certify <identity, public-key> pairs + Public Key Requires a safe key distribution scheme Security - 04 Cryptology #22
Security - 04 Cryptology #23 PGP Key Distribution Physical exchange USB stick, CD,... Exchange via Internet Via email, web pages, PGP key server,... Requires follow-up checks E.g., phone connection with verification of key fingerprint Alternative: web of trust Users digitally sign key of others
PGP Web of Trust Users sign <identity, public-key> pairs of others Forms a directed graph of signatures Different trust levels associated with the signature (depending on the types of checks performed) Unknown Not Trusted Marginal (some checks performed) Complete (full trust) Ultimate (own private key) Complete Alice Bob Peter Ultimate Marginal Carl Marginal Security - 04 Cryptology #24
PGP Web of Trust Signatory Trust Bob signs Carl s key; Alice trusts Bob Only complete or marginal signatures are used Alice assigns Carl s key the same trust level as Bob Key Legitimacy Trust in key authenticity is calculated from signatory trust Complete Marginal Alice Bob x: Number of signatures with signatory trust marginal y: same with complete X: Number of required marginal signatures for a key to be considered authentic (often 2) Y: same with complete signatures (often 1) Carl key_leg = (x/x) + (y/y) = 0: untrusted; < 1: partially authentic; >=1 fully authentic Security - 04 Cryptology #25
Security - 04 Cryptology #26 Figure source: http://fachschaft.informatik.uni-stuttgart.de/archiv/inf.misc/ws07/keysigning-2008/wot-2008-04-09.png PGP Key Signing Parties People meet in person to sign a number of keys They upload their signatures to a key server Improves web of trust by adding a lot of strongly verified keys
PGP: Authentication & Integrity PGP uses cryptographic hash values to protect integrity These are digitally signed to proof the authenticity of messages Algorithms Cryptographic hashes: RIPEMD-160, MD5, SHA-1, SHA-2, and Tiger Digital signatures algorithms: DSA and RSA M h(m) E KPriv,a (h(m)) M + signed hash Zip Zip -1 M + signed hash h(m) Compare D KPub,a (signed-hash) Security - 04 Cryptology #27
PGP: Confidentiality PGP uses hybrid encryption (asymmetric + symmetric) A temporary symmetric key is generated (session key) Message is encrypted symmetrically with the session key Session key is encrypted asymmetrically (one or more times and appended to the message ciphertext) Public keys used are those of the sender and all receivers Advantages of hybrid encryption Multiple recipients with only one message ciphertext (less bandwidth) Symmetric encryption is much faster Algorithms Block ciphers: CAST5, Camellia, Triple DES, AES, Blowfish, and Twofish Asymmetric-key ciphers: ElGamal and RSA Security - 04 Cryptology #28
Security - 07b Application Layer #29 PGP: Confidentiality Sender Generates random session key K Message is compressed and symmetrically encrypted with K K is asymmetrically encrypted with receivers public key and appended to the message Receiver Uses its private key to decrypt K Decrypt message with K and decompress message Sender A Receiver B M Z M' E K E C D D K M' Z -1 M KUB KRB
PGP: Compatibility with Email PGP generates binary data Compressed and encrypted data Standard email format only supports 7 bit data Solution could be to use MIME For compatibility, another solution has been chosen PGP encodes binary data with printable ASCII characters Uses Base64 algorithm with additional CRC appended This extension is called Radix-64 (see next slide) Application Data Add Signature Compress Encrypt Add KeyInfo Base64 + CRC Security - 07b Application Layer #30
Security - 04 Cryptology #31 Radix-64 Blocks of three bytes are encoded with four characters Replacement characters determined by 6 Bit value (0-63) Text length % 3!= 0: zero bits padded Number of padded characters indicated by one or two = characters at the end Additionally adds a CRC-24 value Polynomials specified in RFC2440 Properties Increases text size by ~30% Not even partially readable (cf. quoted printable) Byte #1 Byte #2 Byte #3 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 5 4 3 2 1 0 5 4 3 2 1 0 5 4 3 2 1 0 5 4 3 2 1 0 Character #1 Character #2 Character #3 Character #4 Value Char Value Char Value Char Value Char 0 A 16 Q 32 g 48 w 1 B 17 R 33 h 49 x 2 C 18 S 34 i 50 y 3 D 19 T 35 j 51 z 4 E 20 U 36 k 52 0 5 F 21 V 37 l 53 1 6 G 22 W 38 m 54 2 7 H 23 X 39 n 55 3 8 I 24 Y 40 o 56 4 9 J 25 Z 41 p 57 5 10 K 26 a 42 q 58 6 11 L 27 b 43 r 59 7 12 M 28 c 44 s 60 8 13 N 29 d 45 t 61 9 14 O 30 e 46 u 62 + 15 P 31 f 47 v 63 /
PGP Standard Message Format Header Body From: Dennis Pfisterer <XXXXX@itm.uni-luebeck.de> MIME-Version: 1.0 To: Dennis Pfisterer <XXXXXX@itm.uni-luebeck.de> Subject: Test message - PGP signed and encrypted Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP MESSAGE----- Charset: ISO-8859-1 Version: GnuPG v1.4.10 (MingW32) Comment: GnuPT v3.6.3 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ =20 hqioa00tjphncwtneagaqmlfk63y4seux5idrqo4acajerndurcwtpsxwprw ZQs4 [...] cysmpuqwdejdmggydy3mbo0b4ifi1kvbjqxnj1kvwzhvqjadvqdymbkcuttyn 6XG GCNce+M=3D =3DBKO7 -----END PGP MESSAGE----- Security - 07b Application Layer #32
Security - 07b Application Layer #33 PGP/MIME Message Format To: Dennis Pfisterer <xxxxxx@itm.uni-luebeck.de> From: Dennis Pfisterer <xxxxxx@itm.uni-luebeck.de> MIME-Version: 1.0 Subject: Test message - PGP signed and encrypted Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="enigf6545c92" This is an OpenPGP/MIME encrypted message (RFC 2440 and 3156) --enigf6545c92 Content-Type: application/pgp-encrypted Content-Description: PGP/MIME version identification Version: 1 --enigf6545c92 Content-Type: application/octet-stream; name="encrypted.asc" Content-Description: OpenPGP encrypted message Content-Disposition: inline; filename="encrypted.asc" -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.10 (MingW32) hqioa00tjphncwtneagaz+vwfstebf/jd0tl5jtfq84m6ozpqkmjgmb4hymzmldw [...] =1JfL -----END PGP MESSAGE----- --enigf6545c92--
Issues with PGP No infrastructure / PKI Users select trust level of keys Users must transitively trust others Hard to revoke compromised keys Privacy Private key contains personal data (email addresses) Web of Trust can be used to analyze relationships with other users Security - 07b Application Layer #34
Secure/Multipurpose Internet Mail Extensions (S/MIME) Security - 04 Cryptology #35
Secure/Multipurpose Internet Mail Extensions Standard for public key encryption and signing of MIME data Mostly used by organizations that operate and use a PKI Signatures based on X.509 certificates... SET PGP Kerbero s HTTP IP / IPSec SMTP S/MIM E Originally developed by RSA Data Security Inc. Now standardized by the IETF RFC 3850 (Certificate Handling) [rfc3850-2004] RFC 3851 (Message Specification) [rfc3851-2004] Initially used PKCS#7 as format Later changed to Cryptographic Message Syntax Specified in RFCs 3369, 3370 [rfc3369-2002, rfc3370- Security - 04 Cryptology #36
S/MIME Definition of new MIME Content Types Enveloped Data Encrypted content of arbitrary (inner) type Use of hybrid encryption (just like PGP) Symmetric session key encrypted with public keys of sender and recipients Signed Data Message digest (cryptographic hash) of a MIME part are digitally signed with the private key of the sender Signed-and-Enveloped Data Combination of both Security - 04 Cryptology #37
Security - 07b Application Layer #38 S/MIME Entity: Enveloped (Encrypted) Data MIME entity K E KUB E Certs Key info C b64 S/MIME Header S/MIME body S/MIME envelope S/MIME entity
S/MIME Entity: Enveloped (Encrypted) Data From: Dennis Pfisterer <xxxxxx@itm.uni-luebeck.de> MIME-Version: 1.0 To: Dennis Pfisterer <xxxxxx@itm.uni-luebeck.de> Subject: S/MIME Test Content-Type: application/pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxggGjMIIBnwIBADCBhjB7MQswCQYDVQQGEwJERT EgMB4G A1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2ZXJ z [ ] dko7r+9413cb/fcwgayjkozihvcnaqcbmbqgccqgsib3dqmhbagdlezkiy+2oqcabhiehjf j 134+krNo74glU1Ozungs9NMlBYL3Jx18Pvat/ENUV2MWkjGA85kYFYZigvG2+gbL0epJjfYm HPGgWmmwY93VFaTfm9ixbh9k5/IlP/CjISR9YDBkJVnKYiMdJqqTaW+6U/a0MIXXa/eQZ3c4 Security - 04 Cryptology #39
Security - 07b Application Layer #40 S/MIME Entity: Signed Data MIME entity H KRA E Certs Sig MIME entity b64 S/MIME Header S/MIME body S/MIME signed-data S/MIME entity
S/MIME Entity: Signed Data From: Dennis Pfisterer <xxxxxx@itm.uni-luebeck.de> MIME-Version: 1.0 To: Dennis Pfisterer <xxxxxx@itm.uni-luebeck.de> Subject: S/MIME signature test Content-Type: multipart/signed; protocol="application/pkcs7-signature ; micalg=sha1; boundary="------------ ms000830001090405" This is a cryptographically signed message in MIME format. --------------ms000830001090405 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is an S/MIME signature test --------------ms000830001090405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOcjCC [...] byoqr9x22qplroaarhoqxacrpt5oqfnvbl5v48f1f/k84mnymrgjbovsf7aryqhqusdur8tb feu/aaaaaaaa --------------ms000830001090405-- Security - 04 Cryptology #41
Security - 04 Cryptology #42 S/MIME Entity: Signed Data with Attachment From: Dennis Pfisterer <pfisterer@itm.uni-luebeck.de> MIME-Version: 1.0 To: Dennis Pfisterer <pfisterer@itm.uni-luebeck.de> Subject: S/MIME attachment test Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070101010502010207060701" This is a cryptographically signed message in MIME format. --------------ms070101010502010207060701 Content-Type: multipart/mixed; boundary="------------060204010305060803070801" This is a multi-part message in MIME format. --------------060204010305060803070801 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is an S/MIME attachment test --------------060204010305060803070801 Content-Type: image/png; name="screenshot.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="screenshot.png" ivborw0kggoaaaansuheugaaa14aaanjcayaaac6pmubaaaaaxnsr0iars4c6qaaaarnqu1b [...] ig6uva24aaaaaelftksuqmcc --------------060204010305060803070801-- --------------ms070101010502010207060701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOcjCC [...] QYkMtV8lI7ov6Hpm4YEoYPdSRASo1IFm57RQMS+quVsrz5DZ9GBcywmWmcVAsWn2ZZGTypoJ iwkwaaaaaaaa --------------ms070101010502010207060701--
Web Service Sicherheit Security - 04 Cryptology #43
Sicherheit Die Kombination von Authentifizierung und HTTPS schützt vor Mithören der Nachrichten Unbefugtem Zugriff auf die Ressourcen Einfache und trotzdem mächtige Kombination Trotzdem sind Verbesserungen nötig Schutz der Nachrichten vor Veränderungen Transportunabhängige Verschlüsselungen
Sicherheit auf Nachrichtenebene Deshalb setzt man oft auf Sicherheitsmechanismen, die auf Nachrichtenebene ansetzen. Aktuelle Ansätze: XML Encryption XML Signature XML Encryption: Verschlüsselung auch von Teilen einer Nachricht die Nachricht kann zwischen mehreren Stationen weiter vermittelt werden XML Signature: liefert Authentifizierung des Senders, Integrität der Nachricht, Zurechenbarkeit zu einer Person und Nicht- Anfechtbarkeit der Transaktion
XML Encryption Granularität der Verschlüsselung: Es kann ein komplettes Element verschlüsselt werden, also dessen Inhalt (der selbst wieder aus Kindelementen bestehen kann) und sein Name (Tag). Damit wird sowohl der eigentlich wichtige Inhalt als auch die Tatsache, dass ein Element dieses Typs übertragen wird, verschleiert. Es kann nur der Inhalt des Elements verschlüsselt werden. Dies ist eine sinnvolle Variante, wenn es keine Rolle spielt, ob die Tatsache der Übertragung eines bestimmten Elements bekannt wird. Schließlich kann auch ein ganzes XML-Dokument verschlüsselt werden. Unterschiedliche Teile eines Dokuments können für unterschiedliche Empfänger verschlüsselt werden. Es kann eine Vielzahl Verschlüsselungsverfahren eingesetzt und kombiniert werden. Je weniger verschlüsselt wird, desto schneller ist der Prozess.
Beispiel: Kreditkartennummer <soapenv:body> <ns1:buche xmlns:ns1="http://www. webair.de/buchung"> <flugnummer>wa417</flugnummer> <sitze>3</sitze> <datum>2003-07-11t12:00:00.000z</datum> <preis>eur 1399,00</preis> <karte> <typ>easycredit</typ> <nummer>1234 5678 9876 5432</nummer> <besitzer>ws-reisen</besitzer> <gueltig-bis>09-2004</gueltig-bis> </karte> </ns1:buche> </soapenv:body>
Verschlüsselung <soapenv:body> <ns1:buche xmlns:ns1="http://www.web-air.de/buchung"> <flugnummer>wa417</flugnummer> <sitze>3</sitze> <datum>2003-07-11t12:00:00.000z</datum> <preis>eur 1399,00</preis> <EncryptedData Id="ed1" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/ xmlenc#rsa-1_5"/> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <KeyName>Web Air</KeyName> </KeyInfo> <CipherData> <CipherValue>MEn/q Nc2OwS</CipherValue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>aQgT RGOqoh5Y=</CipherValue> </CipherData> </EncryptedData> </ns1:buche> </soapenv:body>
XML Signature Realisierung von digitalen Signaturen für XML-Dokumente. Eine XML-Signatur kann auf drei verschiedene Arten mit dem unterschriebenen Objekt in Verbindung stehen. Sie kann selbst in das Objekt eingebettet sein, dann spricht man von einer Enveloped Signature. Das Objekt kann in die Signatur eingebettet sein, dann bezeichnet man dies als Enveloping Signature. Das Objekt kann sich an einem ganz anderen Ort befinden, der über eine URI referenziert wird, wobei man dann von einer Detached Signature spricht. Unterschiedliche Teile eines Dokuments können von unterschiedlichen Empfängern signiert werden. Es kann eine Vielzahl Signatur- und Normalisierungsverfahren eingesetzt und kombiniert werden.
XML-Normalisierung Problem: Logisch gleiche XML-Dokumente können aufgrund von Leerzeichen, Zeilenumbrüchen, etc. unterschiedlich serialisiert sein. Gleiche Dokumente können unterschiedliche Hash- Werte haben. Lösung: Normalisierung Transformation von XML-Dokumenten in eine XML- Teilmenge, die logisch gleiche Dokumente immer gleich serialisiert. Hash-verfahren können nun angewendet werden. XML Signature setzt Normalisierung voraus.
Beispiel <?xml version="1.0" encoding="utf-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo Id="2ndDecemberNewsItem"> <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.news_company.com/news/2004/12_02_04.htm"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> <Reference URI="#AMadeUpTimeStamp" Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference>...... </SignedInfo> <SignatureValue>MC0E~LE= </SignatureValue> <KeyInfo> <X509Data> <X509SubjectName> CN=News Items Inc., O=Today s News Items, C=USA </X509SubjectName> <X509Certificate> MIID5jCCA0+gA...lVN </X509Certificate> </X509Data> </KeyInfo> <Object> <SignatureProperties> <SignatureProperty Id="AMadeUpTimeStamp" Target="#2ndDecemberNewsItem"> <timestamp xmlns="http://www.ietf.org/rfcxxxx.txt"> <date>2004122</date> <time>18:30</time> </timestamp> </SignatureProperty> </SignatureProperties> </Object> </Signature>
Web-Services-Sicherheitserweiterungen WS- SecureConversation WS-Federation WS-Authorization WS-SecurityPolicy WS-Trust WS-Privacy WS-Security SOAP XML-Signature XML-Encryption
WS-Security Spezifikation für XML-basierten Container für Sicherheitsmetadaten Ermöglicht die Verwendung/Anbindung von Vielzahl Sicherheitslösung an Webservice- Technologie (z.b. Kerberos) Schwerpunkt: Verwendung von XML Signature und XML Encryption in Webservice-Kommunikation
WS-Security structure
WS-SecurityPolicy Web Service Security Policy Language Erweiterung von WS-Policy um Möglichkeiten zur Beschreibung von Sicherheitsrichtlinien Definition von sicherheitsrelevanten Zusicherungen auf verschiedenen Ebenen: Transportebene Nachrichtenebene
Beispiel <definitions [ ]"> [ ] <ns8:policy xmlns:ns8="http://schemas.xmlsoap.org/ws/2004/09/policy" wsu:id="calculatorwsportbinding_add_input_policy"> <ns8:exactlyone> <ns8:all> <ns9:encryptedparts xmlns:ns9="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <ns9:body></ns9:body> </ns9:encryptedparts> <ns10:signedparts xmlns:ns10="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <ns10:body></ns10:body> <ns10:header Namespace="http://www.w3.org/2005/08/addressing" Name="ReplyTo"></ns10:Header> <ns10:header Namespace="http://www.w3.org/2005/08/addressing" Name="To"></ns10:Header> [...] </ns10:signedparts> </ns8:all> </ns8:exactlyone> </ns8:policy>
Beispiel (Fortsetzung) [...] <message name="add"> <part name="parameters" element="tns:add"></part> </message> [...] <porttype name="calculatorws"> <operation name="add"> <input message="tns:add"></input> <output message="tns:addresponse"></output> </operation> </porttype> <binding name="calculatorwsportbinding" type="tns:calculatorws"> <ns14:policyreference xmlns:ns14="http://schemas.xmlsoap.org/ws/2004/09/policy" URI="#CalculatorWSPortBindingPolicy"></ns14:PolicyReference> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"></soap:binding> <operation name="add"> <soap:operation soapaction="add"></soap:operation> <input> <ns15:policyreference xmlns:ns15="http://schemas.xmlsoap.org/ws/2004/09/policy" URI="#CalculatorWSPortBinding_add_Input_Policy"></ns15:PolicyReference> <soap:body use="literal"></soap:body> </input> [...] </operation> </binding> [...] </definitions>