02267: Software Development of Web Services

Transcription

1 02267: Software Development of Web Services Week 11 Hubert Baumeister Department of Applied Mathematics and Computer Science Technical University of Denmark Fall

2 Contents WS-Policy Web Service Security Basic Cryptography WS Security Project Presentation 2

3 WS-Policy WS-Policy is a general framework for defining rules that Web services have to follow Web services either support a WS-Policy or not A WS-Policy is similar to a boolean expression (e.g. A 1 (A 2 A3)) WS-Policy does not have standard assertions Assertions are defined in their own name space (e.g. WS-SecurityPolicy ( committees/download.php/16569/) WS-Policy 1.2: 3

4 WS-Policy Example 4

5 Assertions (Atomic) assertions are written in a domain specific assertion language (represented by a namespace) Assertions can contain again WS-Policy elements Eg. WS-RM: /02/rm/wsrm-policy.xsd <InactivityTimeout>, <BaseRetransmissionInterval>, <ExponentialBackoff>, <AcknowledgementInterval> 5

6 Attaching policies to operations WSDL for a service that contains a WS-Policy element <wsp:policy wsu:id="calculatorwsportbindingpolicy"> <wsp:exactlyone> <wsp:all> <wsaws:usingaddressing xmlns:wsaws=" <wsrm:rmassertion/> </wsp:all> </wsp:exactlyone> </wsp:policy>... <binding name="calculatorwsportbinding" type="tns:calculatorws"> <wsp:policyreference URI="#CalculatorWSPortBindingPolicy"/>... 6

8 Web Services and Security In the context of SOAP messages transported via HTTP, which of the following statements are correct (several answers are possible) 1) It is easy for a third person to read a SOAP message 2) It is easy for a third person to change a SOAP message 3) It is easy for the receiver of a SOAP message to detect that a SOAP message has been modified by a third person 8

9 Web Services and Security Web Services as such are insecure Third parties can easily Read SOAP messages Intercept and exchange/change SOAP messages Problem with the Internet and B2B communications 9

10 Basic Security Requirements I Identification: Identity Authentication: prove of identity 10

11 Basic Security Requirements II Authorization: What is some allowed to do? 11

12 Basic Security Requiremetns III Confidentiality / Privacy: the message cannot be read by others 12

13 Basic Security Requirements IV Integrity and Authenticity The message contents cannot be changed without the receiver knowing about it The message comes from the source it claims it comes from 13

14 Why is HTTPS not sufficient? HTTPS HTTP through a secure channel (Secure Socket Layer (SSL)) Ensures confidiantiallity of the channel Does not ensure integrity nor authenticity 14

15 Contents WS-Policy Web Service Security Basic Cryptography Encryption Digital Signatures WS Security Project Presentation 15

16 Basic idea Encryption encrypted text := encrypt(key1, text) Decryption text := decrypt(key2, encrypted text) It is difficult to get text from encrypted text without the knowledge of key2 i.e. exponential in the length of the key for guessing the key However, both encrypt and decrypt are easy to compute, i.e. are polynomial in the length of the keys used 16

17 Difficulty of decrypting a message: E.g. Brute Force search for the key Find key such that decrypt(key, encrypted text) = text by enumerating all possibilities Each computation of the decrypt function takes a millisecond Key length: 1 possibilities: 2 time: 2 msec Key length: 2 possibilities: 4 time: 2 * 2 = 4 msec Key length: 4 possibilities: 16 time: 4 * 4 = 16 msec Key length: 8 possibilities: 256 time: 16 * 16 = 256 msec Key length: 16 possibilities: > time: 1 min Key length: 32 possibilities: >4 billion time: 7 weeks Key length: 64 possibilities: > time: >500 million years Key length: n n + 1 possibilities: 2 n 2 = 2 n+1 17

18 AES Brute Force 128-key search Prerequisits Computer checking 1 billion AES 128-bit keys per sec. (costs 200$) 4 trillion dollar budget for buying computers (more than yearly US federal budget) 18

19 AES Brute Force 128-key search Prerequisits Computer checking 1 billion AES 128-bit keys per sec. (costs 200$) 4 trillion dollar budget for buying computers (more than yearly US federal budget) How long will it take to brute force a single 128-bit AES key with these machines? 1 More than a 100 years but less than a million years 2 More than an hour but less than a day 3 More than a day but less than a week 4 More than a million years but less than a billion (10 9 ) years 5 More than a billion (10 9 ) years 19

20 AES Brute Force 128-key search Prerequisits Computer checking 1 billion AES 128-bit keys per sec. (costs 200$) 4 trillion dollar budget for buying computers (more than yearly US federal budget) How long will it take to brute force a single 128-bit AES key with these machines? 1 More than a 100 years but less than a million years 2 More than an hour but less than a day 3 More than a day but less than a week 4 More than a million years but less than a billion (10 9 ) years 5 More than a billion (10 9 ) years Time used = seconds Factor seconds to years (i.e ):

21 Symmetric-key Cryptography Encryption encrypted text := encrypt(key, text) Decryption text := decrypt(key, encrypted text) Same key for encrypting and decrypting Advantage Relatively simple and fast Disadvantage Sender and receiver need to know the same key: Problem of key exchange Algorithms: E.g. Data Encryption Standard (DES), 3DES, Advanced Encryption Standard (AES),... 21

22 Public-key Cryptography Encryption encrypted text := encrypt(public key, text) Decryption text := decrypt(private key, encrypted text) Use of different keys public key of the receiver for encryption Known to everyone private key of the receiver for decryption Only known to the receiver 22

23 Public-key Cryptography Advantage No key exchange is necessary Disadvantage Encrypt and decrypt functions are expensive to compute ( times slower than symmetric algorithms) combinations of symmetric and public-key approaches, e.g. to transmit a symmetric key using a public-key approach Algorithms: E.g. RSA 23

24 RSA Keys are based on the product n of two prime numbers p and q Possibility of deriving the private key from n by finding p and q Importance of fast algorithms for integer factorization 256 bits: factored in a few hours on a personal computer 663 bits: is as of 2008 the largest number factored by general-purpose methods RSA keys are typically bits long (but 1024 bits are considered too short) 24

25 Digital Signatures I Provides: authenticity and integrity but not privacy Signing a message encrypted text := encrypt(private key sender, text) Checking the signature text = decrypt(public key sender, encrypted text) Everybody can read the message But only the sender has the private key the recipient is sure who sent the message Disadvantages It is expensive to encrypt the whole text Use of a cryptographic hash function Possible attack: signature forgery 25

26 Digital Signatures II: Improvements Signing a message digest := hash(text) signature := encrypt(private key sender, digest) Important: original text and signature are sent Checking the signature digest := hash(text) digest := decrypt(public key sender, signature) digest = digest 26

27 Example for a Cryptographic Hash Function Wikipedia: Cryptographic Hash Function 27

28 Cryptographic Hash Function Principle Input: string of any length output: string of fixed length called message digest or digital fingerprint Requirements for an ideal hash function it is easy to compute the hash value for any given message, it is infeasible to find a message that has a given hash, it is infeasible to modify a message without changing its hash, it is infeasible to find two different messages with the same hash. Algorithms: E.g. Message-Digest algorithm 5 (MD5), Secure Hash Algorithm 1 (SHA-2/3) (SHA-1 is considered unsecure and is being phased out) 28

29 Combining Encryption with Digital Signatures (Public Key) Encryption The sender uses the public key of the recipient to encrypt the message Only the recipient can read the message But the everybody could have sent the message as the public key is known to all Digital Signature The sender uses its own private key to encrypt the message (or the digest for the message) Everybody can read the message using the public key of the sender But the recipient knows who sent the message Combination of both First encrypt the message with the public key of the recipient so that only the recipient can read it Then sign the message by encrypting it with the private key of the sender so that the recipient knows who sent the message 29

30 Contents WS-Policy Web Service Security Basic Cryptography WS Security WS-Security Security Tokens Encryption Digital Signature Misc Summary Project Presentation 30

31 WS-Security Security Issues addressed by WS-Security Message level security Identification and authentication ( security token / digital signature) Privacy of messages ( encryption) Integrity of messages ( digital signature) Standards: WS-Security 1.1 Adds elements to WS-Security 1.0 (but WS-Security 1.0 documents are WS-Security 1.1 documents) home.php?wg_abbrev=wss Reuse existing XML standards for encryption and signature 31

32 Namespaces WS-Security related namespaces and their prefixes used in the examples wsse: WS-Security /01/oasis wss-wssecurity-secext-1.0.xsd wsse11: WS-Security oasis-wss-wssecurity-secext-1.1.xsd (the URL of the schema definition is oasis-wss-wssecurity-secext-1.1.xsd) wsu: WS-Security Utilities /01/oasis wss-wssecurity-utility-1.0.xsd xenc: XML-Encryption specification: ds: XML-Signature specification: Documents conforming to the WS-Security 1.1 specification contain the WS-Security 1.0 namespace and the 1.1 extension in the WS-Security 1.1 namespace. 32

33 Example WS-Security: Signing the body 33

34 Basic Structure WS-Security adds the wsse:security header block which contains security relevant information The security element is extensible Standard (i.e. defined by by WS-Security) elements are: Security tokens References to security tokens Signatures for parts of the SOAP message References to encrypted information Timestamps The body can contain encrypted and/or normal data 34

35 Security Token A security token contains one or more claims: e.g. about a name, identity, key, group, privilege, capability, e.t.c. E.g. Username Username <wsse:usernametoken wsu:id="uri"> <wsse:username> Hubert Baumeister </wsse:username> </wsse:usernametoken> E.g. Binary Token: Kerberos ticket, a X.509 certificate... BinarySecurityToken <wsse:binarysecurity wsu:id="uri" ValueType=".." EncodingType=".."> data </wsse:binarysecurity> 35

36 Encryption Envelope Header Body app:applicationdata Other information 36

37 Encryption Envelope Header wsse:security Body wsse:referencelist wsse:datareference name="#1" xenc:encrypteddata ID="1" ds:keyinfo xenc:cypherdata Encrypt data Replace the original data with the encrypted data Add a security header which references the encrypted data Other information 37

38 Decryption Envelope Header wsse:security wsse:referencelist wsse:datareference name="#1" Body xenc:encrypteddata ID="1" ds:keyinfo xenc:cypherdata Other information 38

39 Encryption Encryption is based on the XML-Encryption standard Header and Body elements of a SOAP message can be encrypted Overlapping encryptions are possible Encrypted elements are replaced by xenc:encrypteddata elements However, the result must be a valid SOAP message Supported are symmetric and public key encryption where the key is known to both partners and is not part of the SOAP message the key is transmitted encrypted as part of the SOAP message 39

40 Signing Envelope Header Body app:applicationdata Other information 40

41 Signing Envelope Header wsse:security Body wsse:signature wsse:signedinfo ds:reference wsse:signaturevalue app:applicationdata Other information ID="1" Add ID attribute to the element to be signed Compute the digest from the element to be signed Add a signedinfo security header with the reference to the signed element containing the digest Encrypt signedinfo with the private key of the sender and add it as the signaturevalue to the signature 41

42 Checking the signature Envelope Header wsse:security Body wsse:signature wsse:signedinfo ds:reference wsse:signaturevalue app:applicationdata Other information ID="1" 1. Decrypt SignatureValue with the public key of the sender 2. Check that this corresponds to SignedInfo 3. Compute the digest for the element referenced in SignedInfo 4. Check that digest is the same as stored in the reference 42

43 Digital Signature Within the wsse:security element, the header contains the digital signature for some other element, e.g. in the body of the SOAP message. The digital signature (ds:signature) contains a ds:signedinfo, i.e. which contain information about the signature like ds:canonicalizationmethod, i.e. which method has been used to compute a canonical representation of the ds:signedinfo element ds:signaturemethod, i.e. which method has been used to compute the signature ds:references to the data that is to be signed with information on ds:transforms, i.e. which algorithms were used to compute the input for the digest method (e.g. canonicalization, special encodings etc.) ds:digestmethod, i.e. which digest method were used ds:digestvalue, the digest value a ds:signaturevalue element that contains the signature value using base 64 encoding and is computed from the the ds:signedinfo element ds:keyinfo (optional) information about the key used for the signature 43

44 Canonicalization Canonicalization The same XML information can be represented in different ways as an XML document Canonicalization produces a canonical representation of an XML element Example 1 <xx:tag xmlns:xx=... > <xx:tag1 xmlns:xx=... >äö<xx:tag1> </xx:tag> Example 2 <xy:tag xmlns:xy=".."><xy:tag1>ä&ouml</xytag1></xy:tag> 44

45 Transformation The same as Canonicalization but on the level of SOAP messages e.g. env:mustunderstand="false" can be removed by SOAP nodes 45

46 Timestamps Timestamps <wsse:timstamp wsu:id=".."> <wsse:created>utc time</wsse:created> <wsse:expired>utc time</wsse:expired> </wsse:timestamp> Timestamps are, among others, important to counter replay attacks Each message gets a timestampe Time advances with each message Old messages cannot be sent anymore Problems with timestamps is clock synchronization there is no guarantee that the clocks of the sender and receiver of a message are synchronized 46

47 Encryption and Signature 1 Encrypting signed information First decryption then signature verification encryption element signature element.. 2 Signing encrypted information signature element encryption element First signature verification then decryption 47

48 Example 48

49 Summary WS-Security is a base standard for message level security Security tokens can make security claims, e.g. who sent the message Parts of the SOAP message can be signed integrity / message authentication Parts of the SOAP message can be encrypted privacy The use of WS-Security as such does not guarantee security! E.g. one needs to ensure The relevant message parts are encrypted The relevant message parts are signed, e.g., security tokens and time stamps WS-Security addresses only a small part of possible attacks Consequence New standards built on top of WS-Security for higher level security e.g. trust, security contexts for conversations etc. Tools to prove that protocols and encryption/signature strategies indeed satisfy certain security properites 49

51 Project Presentation Next weeks 23.11: Guest lecture by NetCompany (10:15 12:00); Exercises 8:15 10:00 Use of SOA in industry 30.11: No lecture; Exercises 8:15 10:00 Report delivery: Monday 30.11, midnight Project Presentation Participation mandatory Duration 45 min for each group Approx. 10 min presentation Overview over the project Focus on the highlights and important aspects Comparison between REST and SOAP based services Who did what Remaining time: questions and answers Prepare for the possibility of a demonstration of your software Be prepared to run the tests 51