Distributed Systems Security Overview
Transcription
Distributed Systems Security Overview
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 1 SMTP Basics MUA • 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) SMTP MSA – MTA look up the mail exchanger record (MX record) for the recipient's domain MTA SMTP – Forwards mail to destination MTA MTA • Destination MTA forwards mail to mail delivery agent (MDA) MDA – Saves the message in the recipients mailbox • POP, IMAP, ... Clients use IMAP, POP, web interfaces, etc. to receive emails MUA Security - 04 Cryptology #4 Email Message Format • Simple, text-based format Header Blank line • Message comprised of headers and 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...] Body 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 - 04 Cryptology – Non-text attachmentsSecurity (images, documents, executables, …) #6 2 MIME Headers • MIME defines new headers – Inform receivers about the content type and format of messages • Indication that the MIME format is used • Identification of the content type – Header „MIME-Version: 1.0“ is present – 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 #7 MIME Types File Extensions MIME Content Type .htm .html text/html • .txt text/plain .gif image/gif .png image/png .jpg .jpeg image/jpeg .gz application/x-gzip .ai .eps .ps application/postscript .exe .bin application/octet-stream .zip application/x-zip-compressed .avi video/x-msvideo .pdf application/pdf .doc .docx application/msword .js text/javascript .qt .mov video/quicktime • • • 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 Important major types – Text, Image, Audio, Video – Application .mpeg .mpg .mpe video/mpeg – Multipart – Message .wav audio/x-wav .rtf application/rtf Security - 04 Cryptology #8 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 • multipart/mixed – – • Groups multiple text messages into one email document 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) Security - 04 Cryptology #9 3 MIME Type “multipart” • Parts are separated by boundaries – Boundary ID specified in the contenttype header • This is a multi-part message in MIME format. Individual parts are separated with boundary lines – Start of a part: „--“ + Boundary ID – After last part „--“ + Boundary ID + „--“ • Multiparts may be nested • Example 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" --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 <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Das ist eine Testmail. </body> </html> --boundary-Security - 04 Cryptology – „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 #10 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 Das ist eine Testmail mit Bild. --070705070901090202020705 Content-Type: multipart/related; boundary=“060002020904090506090804" [...] --070705070901090202020705-- --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> --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-- Security - 04 Cryptology #11 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 4 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 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 Security - 04 Cryptology #14 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 Server not supporting ESMTP EHLO example.com 502 5.5.2 Error: command not recognized • Servers not supporting ESMTP answer with an Security - 04 Cryptology error code #15 5 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 – – – – – 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 SMTP (RFC 3207) IMAP and POP3 (RFC 2595) XMPP (RFC 3920) LDAP (RFC 2830) NNTP (RFC 4642) 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 Sender SMTP Organization Outgoing SMTP No confidentiality, no authenticated connections Intermediate SMTP Organization Incoming SMTP Security - 04 Cryptology Data processed on untrusted systems SPAM Filter Appliance Receiver Receiver SMTP #18 6 Security Objectives for Email • Typically implemented • Which security security objectives objectives are important – Confidentiality for email? • End-to-end encryption – Confidentiality? – Integrity – Authenticity? • Avoid undetected changes – Authenticity – Integrity? • Detect forged emails – Non-Repudiation? – Non-Repudiation – Access Control? • Requires electronic signatures – Availability? 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 Kerbero s HTTP PGP S/MIM E SMTP IP / IPSec 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 Application OpenPGP Security - 07b Layer is GnuPG #21 7 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 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 Security - 04 Cryptology #23 PGP Web of Trust • Users sign <identity, public-key> pairs of others Bob Marginal – Forms a directed graph of signatures Complete Carl • Different trust levels associated with the signature (depending on the types of checks performed) – – – – – Alice Marginal Unknown Not Trusted Marginal (some checks performed) Complete (full trust) Ultimate (own private key) Security - 04 Cryptology Peter Ultimate #24 8 PGP Web of Trust • Alice 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 • Complete Bob Key Legitimacy – Trust in key authenticity is calculated from signatory trust Marginal – 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 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 Security - 04 Cryptology Figure source: http://fachschaft.informatik.uni-stuttgart.de/archiv/inf.misc/ws07/keysigning-2008/wot-2008-04-09.png #26 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) EKPriv,a(h(M)) M+ signed hash Zip Zip-1 Security - 04 Cryptology M+ signed hash h(M) Compare DKPub,a(signed-hash) #27 9 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 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 C E M Z D M' M' E D KUB KRB K Z-1 M K Security - 07b Application Layer #29 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) Security - 07b Application Layer Application Data Add Signature Compress Encrypt Add KeyInfo Base64 + CRC #30 10 Radix-64 • Byte #1 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 • Byte #3 5 4 3 2 1 0 5 4 3 2 1 0 5 4 3 2 1 0 5 4 3 2 1 0 – Replacement characters determined by 6 Bit value (0-63) • Byte #2 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 Blocks of three bytes are encoded with four characters Properties – Increases text size by ~30% – Not even partially readable (cf. quoted printable) Character #3 Character #4 Value Char Character #1 Value Char Character #2 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 / Security - 04 Cryptology #31 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 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-- Security - 07b Application Layer #33 11 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 ... SET Kerbero s HTTP PGP S/MIM E SMTP IP / IPSec – Signatures based on X.509 certificates • 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, rfc3370Security - 04 Cryptology 2002] #36 12 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 S/MIME Entity: Enveloped (Encrypted) Data KUB K MIME entity E E S/MIME Header Certs Key info C S/MIME envelope b64 S/MIME body S/MIME entity Security - 07b Application Layer #38 S/MIME Entity: Enveloped (Encrypted) From: Dennis Pfisterer <xxxxxx@itm.uni-luebeck.de> Data 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 hnjKLIA3Kj8ECCtTa4K+UIoEAAAAAAAAAAAAAA== 13 S/MIME Entity: Signed Data KRA S/MIME Header Certs Sig MIME entity H E MIME entity b64 S/MIME signed-data S/MIME body S/MIME entity Security - 07b Application Layer #40 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 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-- Security - 04 Cryptology #42 14 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 – Notariats Service 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 NichtAnfechtbarkeit der Transaktion 15 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> 16 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 HashWerte haben. • Lösung: Normalisierung – Transformation von XML-Dokumenten in eine XMLTeilmenge, 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> 17 Web-Services-Sicherheitserweiterungen WSSecureConversation WS-SecurityPolicy WS-Federation WS-Trust WS-Security SOAP XML-Signature XML-Encryption WS-Authorization WS-Privacy WS-Security • Spezifikation für XML-basierten Container für Sicherheitsmetadaten • Ermöglicht die Verwendung/Anbindung von Vielzahl Sicherheitslösung an WebserviceTechnologie (z.B. Kerberos) • Schwerpunkt: Verwendung von XML Signature und XML Encryption in Webservice-Kommunikation WS-Security structure 18 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> 19 WS-Trust • Aufbau von Vertrauensverhältnissen zwischen Kommunikationspartnern • WS-Trust spezifiziert: – Security Token Services (STS) – Nachrichtenformat zum Austausch von Security Tokens WS-Trust-Kommunikationsablauf STS Client Webservice Aufruf Mitteilung STS TokenAnfrage Token Aufruf mit Token Autorisierung Antwort Conclusion • Security on the Application Layer – Mostly message-based security: Email – Important email standard: MIME – Two important standards: PGP and S/MIME • PGP – Secure email w/o PKI Web of Trust • S/MIME – Industrial PGP counterpart – Requires X.509-based PKI Security - 07b Application Layer #60 20 Literature • PGP / GPG / OpenPGP – [rfc4880-2007] OpenPGP Message Format. http://tools.ietf.org/html/rfc4880 • S/MIME – [rfc3369-2002] RFC 3369: Cryptographic Message Syntax (CMS). http://tools.ietf.org/html/rfc3369 – [rfc3370-2002] RFC 3370: Cryptographic Message Syntax (CMS) Algorithms. http://tools.ietf.org/html/rfc3370 – [rfc3850-2004] RFC 3850: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling. http://tools.ietf.org/html/rfc3850 – [rfc3851-2004] RFC 3851: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. http://tools.ietf.org/html/rfc3851 Security - 04 Cryptology #61 21