Distributed Systems Security Overview

Transcription

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
#4
Email Message Format
• Simple,
text-based
format
Header
Blank line
• Message
comprised
of
headers
and body
From: Dennis Pfisterer <[email protected]>
To: [email protected]
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
#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“
#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
#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)
#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
To: Dennis Pfisterer <[email protected]>
Content-Type: multipart/alternative;
boundary=“boundary"
--boundary
Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
Das ist eine Testmail.
--boundary
Content-Type: text/html; charset=ISO-8859-1
<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“
MIME-Version: 1.0
Subject: Testmail mit Bild
Content-Type: multipart/alternative;
boundary=“070705070901090202020705"
--070705070901090202020705
Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
Das ist eine Testmail mit Bild.
--070705070901090202020705
Content-Type: multipart/related;
boundary=“060002020904090506090804"
[...]
--070705070901090202020705--
--060002020904090506090804
Content-Type: text/html; charset=ISO-8859-1
<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:[email protected]"><br><br>
</body>
</html>
--060002020904090506090804
Content-Type: image/png; name="LogoITM.png"
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
Content-Disposition: inline; filename="LogoITM.png"
iVBORw0KGgoAAAANSUhEUgAAASAAAABXCAYAAACk05hN
AAAAAXNSR0IArs4c6QAAAAZiS0dE
[...]
+yYGTAyEDAP/DxJmKwTsbjAnAAAAAElFTkSuQmCC
--060002020904090506090804--
#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 „.“
#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: [email protected]
250 2.1.0 Ok
RCPT TO: [email protected]
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Hallo allerseits,
[...]
Viele Grüße,
Dennis
.
250 2.0.0 Ok: queued as 8664783F8E1
quit
221 2.0.0 Bye
#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: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from example.com (localhost.localdomain
[127.0.0.1])
by itm01.itm.uni-luebeck.de (Postfix) with SMTP id
8664783F8E1
for <[email protected]>; Mon, 18 Jun 2012
11:05:03 +0200 (CEST)
Message-Id:
<[email protected]>
Date: Mon, 18 Jun 2012 11:05:03 +0200 (CEST)
Hallo allerseits,
[...]
Viele Grüße,
Dennis
#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
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)
#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
#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
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?
#19
Pretty Good Privacy (PGP)
#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
#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
#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)
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
#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
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
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
#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)
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
/
#31
PGP Standard Message Format
Header
Body
MIME-Version: 1.0
Subject: Test message - PGP signed and encrypted
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
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--
#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)
#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
#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
#38
S/MIME Entity: Enveloped (Encrypted)
From:
Dennis Pfisterer <[email protected]>
Data
MIME-Version: 1.0
Subject: S/MIME Test
Content-Type: application/pkcs7-mime; name="smime.p7m"
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
#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
#40
S/MIME Entity: Signed Data
MIME-Version: 1.0
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
This is an S/MIME signature test
--------------ms000830001090405
Content-Type: application/pkcs7-signature; name="smime.p7s"
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
MIME-Version: 1.0
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"
--------------060204010305060803070801
This is an S/MIME attachment test
--------------060204010305060803070801
Content-Type: image/png; name="ScreenShot.png"
Content-Disposition: attachment; filename="ScreenShot.png"
iVBORw0KGgoAAAANSUhEUgAAA14AAANjCAYAAAC6PMuBAAAAAXNSR0IArs4c6QAAAARnQU1B
[...]
iG6uva24AAAAAElFTkSuQmCC
--------------060204010305060803070801--
--------------ms070101010502010207060701
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOcjCC
[...]
QYkMtV8lI7ov6Hpm4YEoYPdSRASo1IFm57RQMS+quVsrz5DZ9GBcywmWmcVAsWn2ZZGTypoJ
iwkWAAAAAAAA
--------------ms070101010502010207060701--
#42
14
Web Service Sicherheit
#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
#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.
– [rfc3851-2004] RFC 3851: Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification.
#61
21

Distributed Systems Security Overview

Transcription

Similar documents

Dateien anzeigen - Heinrich-Heine

Client Server - ITwelzel.biz