A Novel Approach to Implement Message Level Security in RESTful Web Services
AA Novel Approach to Implement Message Level Security in RESTful Web Services
Gyan Prakash Tiwary a , Abhishek Srivastava b Discipline of Computer Science and EngineeringIndian Institute of Technology IndoreIndore, India 452020 a Email: [email protected] b Email: [email protected]
Abstract
The world is rapidly adopting RESTful web services for most of its tasks. The once popular SOAP-based web services are fast losingground owing to this. RESTful web services are light weight services without strict message formats. RESTful web services, unlikeSOAP, are capable of message transfer in any format be it XML, JSON, plain-text. However, in spite of these positives, ensuringmessage level security in REST is a challenge. Security in RESTful web services is still largely dependent upon transport layersecurity. There has been some work recently towards message level security in such environments wherein the transfer of messagelevel security metadata is done through utilising new HTTP headers. We feel, however, that any method that compromises thegenerality of the HTTP protocol should be avoided. In this paper, therefore, we propose two new ways of encryption that promiseto ensure message level security in RESTful web services without the need for special HTTP headers. This approach worksseamlessly on most famous content-types of RESTful web services: XML, JSON, HTML, plain-text and various ASCII printablecontent types. Further, the proposed approach removes the need for content negotiation in cases where the content comprises XML,JSON, HTML, plain-text, and ASCII printable content types and also removes the need for XML or JSON canonicalization.
Keywords:
RESTful Web Services, Message level Security
1. Introduction
Web services are a means to access the web in a ‘program-matic’ manner. A website and a web service are similar in thatboth respond to requests made by clients on the web. Web-sites respond with content that can easily be comprehended bya human eg. HTML, CSS and Javascript, whereas web servicesrespond with content meant for consumption by other applica-tions eg. XML, JSON. The response from web services has agreater focus on data whereas that from websites is more to-wards an interactive representation of data.Web services may be categorised into two broad types:SOAP-based web services and RESTful web services. SOAP-based web services deal with properly structured messagescomprising formal XML-based formats for a request and re-sponse. RESTful web services, on the other hand, lack suchformal formats. This contributes to the flexibility and ‘lightweight’ nature of RESTful web services. SOAP request andresponse messages usually utilise HTTP or SMTP packets ascontainers, whereas REST requests comprise a simple HTTPrequest with the use of the common HTTP verbs CRUD (cre-ate, read, update and delete) for executing operations on theresource [1]. The response from a RESTful web service to a re-quest is also an HTTP response containing XML, JSON, CSV,HTML, or plain-text.In REST, any content or service on the web for which a clientmakes a request to a server is known as a ‘resource’. A resourceis content available with the server side and may get transferred or even modified based on a client’s request. A resource maybe a text or a binary file or may be data stored in a database.Each resource is identified by a unique ID called the UniformResource Identifier (URI). A resource may be represented invarious formats such as XML, JSON, CVS, HTML, plain-textand others with the most popular representation today beingXML and JSON.RESTful web services, unlike SOAP, do not have aformal description language, therefore, it is common forservices to publish their resource representations on publicdomains like websites. For example, Google publishes theresource representation of its drive API at the following URL https: // developers.google.com / drive / v3 / reference / about . In addition to this, web service providers also describethe capabilities of the various HTTP verbs for performingoperations on a given resource in a similar manner.An important requirement for web services while connectingwith their clients is a robust security mechanism. This is alonglines similar to ordinary websites. Security is imperative forthe following three purposes: confidentiality, integrity and au-thenticity. Confidentiality implies that a conversation betweenthe server and the client makes no sense to a potential intrudereavesdropping on the conversation. Confidentiality can be pro-vided by encryption of the message. Integrity implies that amessage in transit between a client and a server must remainunchanged during transit. Authenticity ensures that a client andserver talking to each other are indeed talking to each other and Preprint submitted to Journal Name January 10, 2018 a r X i v : . [ c s . N I] S e p ot a third entity. Digital signature provides integrity and au-thenticity.Web services and websites both work at the application layer.To use a website or web service a client first needs to con-nect with the server providing the service at the transport layer.This type of connection is called a TCP (Transmission ControlProtocol) connection. TCP contains and carries the applicationlayer data in the form of HTTP or SMTP inside it. There arequite a few Security mechanisms available at the transport layerthat are quite robust and provide encryption, authentication andauthorization. One such mechanism is Transport Layer Secu-rity (TLS) [2].TLS makes use of two types of encryption algorithms: sym-metric key encryption and asymmetric key encryption algo-rithms. In asymmetric key encryption, the server maintainstwo keys of which one is ‘public’ and the other ‘private’. Theserver makes the public key available to all, and the private keyis kept hidden. A message that is encrypted using the publickey can only be decrypted using the private key. The clientencrypts the message using this public key and sends it to theserver. The server subsequently decrypts the message using thesecret private key. In symmetric key encryption, both the serverand client maintain a shared secret key between them called thesymmetric session key. The symmetric session key is used bothfor encryption and decryption. To send a message, the client en-crypts the message with this key and upon reaching the server,the same key is used for decryption.To transfer a large amount of data symmetric key algorithmsare e ffi cient as these are relatively light weight. To transferfewer data asymmetric key algorithms are deemed more appro-priate. The big question with symmetric key encryption is: howto transfer the symmetric key initially from the client to serverover a non-secure channel? A server provides its public key toall its clients. A client that wants to connect to the server pro-vides the symmetric shared key information encrypted with theserver’s public key to the server. The server sees this shared keyinformation after decrypting the client’s message using the pri-vate key. After the server’s agreement on the shared key bothstart to transfer their data encrypted by the shared symmetrickey. This is the normal sequence followed in encryption: first,the asymmetric key encryption, as described earlier, is usedonly to securely get the symmetric key for a session. Subse-quent to this, in all further communications in that session be-tween client and server symmetric key encryption is used.Transport Layer Security (TLS), as described above, is nor-mally used to encrypt the TCP container that contains the HTTPor SMTP container (application layer data) of the web servicerequest and response. We know that both SOAP and REST-ful web services contain XML, JSON etc inside the applicationlayer packet (HTTP or SMTP), which is contained in the trans-port layer packet (TCP). TLS is e ff ective with web services ifthe transfer of messages is between two parties only. In scenar-ios where several intermediate nodes need to access di ff erentparts of the content of the same HTTP or SMTP container, how-ever, TLS becomes ine ff ective and the need arises for a messagelevel security mechanism at the application layer [3]. This isa typical requirement of a web service composition scenario, where several nodes interact with each other to provide a largercomposite application.For better comprehension of the scenario, let us consider asimple real world example of a big box containing a small boxinside which there are several tennis balls with some relevantinformation written on them. Each ball belongs to a di ff erentperson. The big box here can be looked upon as the HTTPcontainer, the small box represents the entire XML or JSONmessage, and the balls represents various tags in XML or fieldsin JSON. The message written on one ball should be such thatit cannot be understood by a person to whom it does not belong.What TLS does is: it encrypts the big box (Fig. 1.). When aperson decrypts this big box, the small box and the informa-tion written on all the balls inside the small box become visibleto that person irrespective of whether the ball belongs to himor not. Message level security, on the other hand, encrypts theinformation written on each ball and therefore only the personto whom a ball belongs is given the rights to decrypt the mes-sage. The balls here are the di ff erent tags of XML (or fieldsin JSON) that may be intended for di ff erent intermediate webservice nodes in a web-service composition scenario. The en-tire XML should be encrypted so that the intermediate nodesare only able to understand and / or edit tags that are meant forthem. The need, therefore, is to encrypt the message written oneach tag separately with di ff erent keys (Fig. 2.). Encrypting thevarious parts of an XML or JSON document with di ff erent keysis known as message level encryption. Message level encryp-tion has the potential to provide message level security to webservices. Figure 1:
Encryption by TLS
Figure 2:
Message Level Encryption
SOAP based services do have formal mechanisms for mes-sage level security defined by W3C and OASIS [3] which pro-2ide authentication, authorization and encryption. These ser-vices are broadly based on XML Signature [4] and XML En-cryption [5]. XML signature and XML encryption may workon the whole document, a part of the document, or even on bi-nary documents. After encryption and signature, however, theencrypted document gets represented as XML only.XML encryption uses existing block or stream ciphers to en-crypt the document. Some of these algorithms are AdvancedEncryption Algorithm (AES) [6], Data Encryption Algorithm[7] etc. Both XML encryption and signature use di ff erent ver-sions of the Standard Hash Algorithm [8] for creating the mes-sage digest. For key agreement they use the Elliptic CurveDi ffi e-Hellman (ECDH) [9] Key Agreement. All these encryp-tion and hash algorithms work on the data at the byte level.The issue with byte level encryption and signature is that twoXML documents that represent the same data may not be iden-tical byte-by-byte and as such even a slight cosmetic di ff erencebetween the documents changes the whole encryption or sig-nature. An example of this is: interchanging the position ofattributes in a tag does not change the nature of the XML docu-ment, however, it completely changes the encryption and signa-ture of that document. The normal procedure to overcome thisproblem is through XML cannonicalization [10]. Here, severalstrict rules need to be applied on the XML documents such thattwo XML documents that represent the same data become iden-tical down to the last byte. E ff ective implementation of XMLbased signature and encryption requires the compulsory step ofXML canonicalization.This technique is ine ff ective if the two parties in conversationsupport di ff erent technologies, e.g. one supports XML contentand the other supports JSON. Also, XML canonicalization isa compulsory step in XML based security and it is a cumber-some process indeed. All this contributes to making such secu-rity techniques unsuitable for RESTful web services. Currently,there is no formal model for the provision of message level se-curity in RESTful web services. In RESTful web services, bothmessage encryption and authentic connection are still majorlydependent upon Transport Layer Security (TLS).Web service composition is a typical example where inter-mediate nodes need to access the same RESTful message andwhere TLS is not e ff ective. In web service composition sev-eral service providers work together to form a large compositeservice o ff ering. Each web service in a service compositiondoes its bit and the larger composite task gets done. We arealso moving towards a scenario where individual web servicesdynamically partake in a composition and after providing theirrespective services exit with the group. To realise such a sce-nario in a secure environment, it is imperative that an e ff ectivemessage level security mechanism be in place that would en-able a web service only partial access to a message and keepthe rest of it hidden.We need to keep the various REST principles in mind whiledesigning message level security models for RESTful services.In recent work by Gabriel Serme et. al [11] use of HTTP head-ers is made to transfer names of encryption algorithms, keysand other security meta data. Encryption and signature in thisapproach are done through the use of existing algorithms. We feel that sending new headers in HTTP packet makes the HTTPprotocol itself non general. Further, use of existing encryptionalgorithms results in large sized HTTP contents.In this paper, we propose a novel approach to encryptingRESTful web services at the message level that works well si-multaneously with most popular content types (XML, JSON,HTML and plain-text). The main idea in this approach is to re-place the ASCII printable characters with a series of numbersduring encryption and doing the reverse during decryption. En-cryption and decryption through this simple approach becomeeasy and e ff ective. This is because the encrypted message isquite small in size as compared to that of existing algorithms.In fact, in certain situations, the encrypted message is smallerthan the message itself. The character to number conversionproposed also removes the need for XML cannonicalization be-cause it is not a byte-by-byte encryption.The proposed approach also eliminates the need for contentnegotiation wherein the client and server negotiate on the typeof content (XML, JSON) to be used for communication. Thisis because a resource gets converted into the same encryptionirrespective of the type of representation. The series of num-bers that constitutes the encryption will always be placed in theHTTP body as text / plain content type. The approach does notrequire special HTTP headers to pass security meta-data nordoes it violate REST principles.Resource Representation is all about one to one mapping ofXML tag-name and data type supported inside that tag, or datatype supported by the value of the JSON name. Several webservice providers represent their resources in their API docu-mentation. In the proposed approach the server does not needto publish its resource representation. This is because all rep-resentations (XML, JSON etc.) get converted to the same en-cryption and can be decrypted to any representation. Data typesin between the tags and JSON names are specified explicitly inthe encryption itself. The client comes to know about resourcerepresentation in the encrypted form after its first request forthe resource.It should be noted that in this paper we do not intend to pro-vide a complete security solution for web service compositionscenario. The idea is to introduce a novel, and much simplertechnique for encryption that is also secure, reliable, fast, andresults in much smaller sized encrypted messages. The tech-nique also removes the need for XML canonicalization and con-tent negotiation.The paper is organized as follows: in Section 2, we discussthe system architecture for our approach. In Section 3 we de-scribe our proposed approach in detail with a running examplefor better understanding. We discuss various advantages of ourapproach in Section 4 and conclude the paper in Section 5.
2. System Architecture
In RESTful communications and in general XML-tags,XML-attributes, values of XML-attributes and JSON-nameschange less frequently and therefore we call these the non-variable parts of the request and response messages. The values3n between XML-tags or the values of JSON names on the otherhand change much more frequently and we call these the vari-able parts of request and response messages. For example:
XML 1:
JSON 1: "root": {"-attr1": "value1","-attr2": "value2","name": "iiti","value": "2"}
XML and JSON can be easily converted into each other. AnXML and its corresponding JSON are shown above as XML 1and JSON 1. In XML 1 the “root”, “name”, “value”, “attr1”,“attr2”, “value1” and “value2” are the non-variable parts and“iiti” and “2” are the variable parts of the message. In the corre-sponding JSON message JSON 1, we have similar non-variable and variable parts.In our approach of encryption both the non-variable and variable parts of the message are represented by a string ofnumbers. The encrypted message is sent to the receiver en-capsulated within an HTTP packet as plain-text. We knowthat XML and JSON can be easily converted to each other andas stated earlier the strength of this algorithm is that it doesnot matter whether the content to be encrypted is in JSON orXML the result is the same encrypted message which can sub-sequently be decrypted into JSON and / or XML as the need be.Encryption and decryption can be done by a shared symmetrickey among parties. In case of web service composition wheredi ff erent intermediaries have access to the same RESTful mes-sage, di ff erent parts of the same message can be encrypted withdi ff erent symmetric keys. We initially discuss message levelencryption between two parties only. Subsequently, in Section3 we escalate the discussion to multiple party web-service com-position.Figure 3 shows the various components at the client andserver ends that are used for encryption / decryption. At theserver side, there is a message level encryption / decryptionmodule (Encryption-Decryption Engine) that lies between theRESTful service application and the HTTP service. At theclient side, the same lies between the RESTful client and theHTTP client. There is a ‘Key Manager’ at both ends that isconnected to the corresponding HTTP server and client. Prior to the start of a conversation, both ends require a sym-metric session key. The key manager at both ends manages thesymmetric key. First, the client’s key manager sends a key re-quest to the server’s key manager as a special command (“Get
Figure 3:
Cliet Server Interaction key”). The “Get key” command goes to the HTTP client sec-tion at the client side. The HTTP client section at the clientside places the “Get key” command in the body of the HTTPPOST request with the content type being plain-text as shownin Figure 4.
Figure 4:
Client’s request for key
The HTTP service at the server side receives the request andfinds the “Get key” string in the POST request’s body. Subse-quently, the server’s key manager generates 10 random integerswithin a given range and creates a unique
10 element key . Theserver’s key manager passes this
10 element key to the HTTPservice at the server side. The HTTP service at the server sidecreates an HTTP response, places the key in the response bodywith the content type being plain text and sends the HTTP re-sponse to the HTTP client at the client side (Fig. 5). The HTTPclient at the client side reads the response body and passes thecontent to the client’s key manager.The conversation between the client and the server for a keyis a matter between just two parties and therefore the key ex-change can utilise TLS for security. Both sides store the sharedkey in a key database for further use. The number of keys main-tained by each member in a web services composition groupdepends on the structure of the web services composition. Atmost, each member in a group of n service providers may need4 igure 5:
Server’s response with key to maintain n secret keys (n-1 keys to communicate with theother n-1 members and one group key). The shared key getsstored in key-databases of the client and the server. The clientis responsible for a change in key. To change the key the clientsends a new key request to the server.
This symmetric key is at the heart of the proposed approachand comprises 10 elements. Using just this key both the clientand server can create various tables that take part in messagelevel encryption and decryption. We have seen an example ofthe
10 element key randomly generated by the server in Figure5 ([12,6,1,1,1,14,4,0,3,2]) . In general, the key is representedas key = [rows, cols, start with, row rev, col rev, symbol type,group size, reverse, final sum, power] . In this paper di ff erentelements of the key are referred to by using indexing startingfrom , for example key[0] for rows , key[1] for cols etc. Wewill now understand the various elements of the key one byone. The Encryption-Decryption engine at both the client andserver sides maintains a table that we choose to call the
Tem-porary Table (TT) . rows at key[0] specifies the number of rowsin this table. The number of rows in TT = key[0] + . key[0] ranges from to any integer depending upon the capability ofthe system. at key[1] specifies the number of columns in the TT .The number of columns in TT = key[1] + . For key = [12,6,1,1,1,14,4,0,3,2] the TT at both the client and serversides will have rows and columns (including the coloured‘header’ rows and columns) as shown in Figure 6. The colouredcells of the table are used to store table headers, whereas thewhite cells are for normal entries. key[1] ranges from to anyinteger depending upon the capability of the system. We have two types of headers in TT , one is a row header (rh) and the other is the column header (ch) . As part of the encryp-tion process, we need to number both rh and ch . Numberingalways starts with . Numbering can start from either rh or ch depending upon the value of key[2] . The header numbering of Figure 6:
Temporary Table (TT) TT starts with rh if the value of key[2] is and it starts with ch ifthe value of key[2] is . Range of key[2] is {
0, 1 } . If the number-ing of the header starts with numbering rh , then the same countcontinues while numbering ch and vice-versa. For example, in key = [12,6,1,1,1,14,4,0,3,2] the header numbering starts with ch . In Figure 6, therefore, the count to has been used fornumbering ch and in continuation with that to have beenused for numbering rh . If key[3] is then the rh numbering starts from the top mostrow (top to bottom) and if key[3] is then the rh number-ing starts from the bottom row (bottom to top). For key = [12,6,1,1,1,14,4,0,3,2] the rh numbering starts from the bottomand progresses towards the top as shown in Figure 6. The rangeof key[3] is {
0, 1 } . If key[4] is then the ch numbering starts from the left mostcolumn (left to right) and if key[4] is then the ch number-ing starts from the right most column (right to left). For key = [12,6,1,1,1,14,4,0,3,2] , the ch numbering starts from the rightand progresses towards the left as shown in Figure 6. The rangeof key[4] is {
0, 1 } . There are four types of characters that can be used in thistable as elements in the non-header cells: small alphabet, cap-ital alphabet, digits, and special symbols. The total possiblearrangements in this table are: C × (1!) + C × (2!) + C × (3!) + C × (4!) =
64. For all these 64 arrangements key[5] ranges from 0 to 63. Each value defines a unique occur-rence, non occurrence, and order of occurrence of the variousprintable ASCII characters in the non header cells of the TT .For each value of key[5] , the entry of characters in TT startsfrom the top left corner non-header cell and sequentially movestowards the bottom right corner non-header cell. For example,1) If value key[5] is then only small alphabet characters areallowed in TT , 2) If it is then only capital alphabet charactersare allowed in TT . Similarly, if key[5] is then the order ofentering characters in TT is digits , followed by capital alpha-bets , further followed by small alphabets . The value ignoresspecial symbols. There are various other arrangements of char-acters for other values of key[5] . Another value of key[5] may5ave included special symbols and the various characters mayhave been in a di ff erent order of occurrence. Figure 6 showsthe entry of TT if key = [12,6,1,1,1,14,4,0,3,2] . key[5] and thecorresponding arrangement of characters are only assumptionsof the authors. During implementation, these may be di ff erent,but the total possible combination is always fixed. Various groups of consecutive elements in TT are created.Each group has a size indicated by key[6] . The last groupof TT can have fewer elements than key[6] . For key = [12,6,1,1,1,14,4,0,3,2] since key[6] is , TT has various groupsof elements each. In Figure 6 we represent the various groupsas alternately underlined and non-underlined elements. The el-ements are in the same group and are in a di ff er-ent group, similarly elements
8, 9, A, B are in the same groupand
C, D, E, F are in a di ff erent group, and so on. key[6] rangesfrom to (key[0]-1) × (key[1]-1) . If key[7] is 1 then the elements in all the groups will be in agroup wise reverse order with respect to their initial positionsin the group. If this value is 0 then no such reverse operationoccurs. For key = [12,6,1,1,1,14,4,0,3,2] , the TT is shown inFigure 6. For key = [12,6,1,1,1,14,4,1,3,2] the groups get re-versed and the corresponding TT is shown in Figure 7. Figure 7:
Temporary Table (TT) will be explained later.
In the process of message level encryption, we need to cal-culate a unique integer corresponding to each character presentin TT . This integer may be calculated as ( rh ) key [9] + ( ch ) key [9] .For example, for the following key = [12,6,1,1,1,14,4,1,3,2] theinteger value of G is (15) + (5) = is (17) + (2) = ff erent characters may end up in the same integer, thissituation is called integer collision. If integer collision occursthen we keep on increasing the integer value of the later charac-ters in TT until it gets a unique value. Powering ch and rh with key[9] has two benefits. 1). It makes the encryption itself morerandom and 2). The Probability of integer collision becomes very less. Range of key[9] from to any integer depends on thecapabilities of the service provider and consumer.It is important to note that the rules outlined for the Tag Tableare for demonstrating the idea and are open to modification.The main idea is to bring in as much randomness as possible soas to make it impossible for an adversary to guess the contents. A client’s PUT or POST request that may be in XML, JSONor plain text is first sent to the Encryption-Decryption engine. Inthe Encryption-Decryption engine at the client side, the requestmessage gets converted into a string of numbers. Subsequentto this, the HTTP / S client encapsulates this string of numberswithin an HTTP / S request (PUT or POST) packet and sends itto the server. At the server end, the HTTP / S server reads thestring of numbers and sends it to the Encryption-Decryptionengine at the server end. The Encryption-Decryption engineat this end decrypts the string of numbers into the correspond-ing XML and / or JSON form and finally delivers it to the Webservice. The same process repeats with the response from theserver to the client. The Encryption and decryption enginesused here comprise the following sub-components: Temporary Tables (TT) have been discussed at length in theearlier sub-sections. We assume that the contents of this tablecomprise only printable ASCII characters. Each element in thetable, comprising printable ASCII characters, is uniquely de-fined by a corresponding pair of rh and ch . The Structure ofthe table and the position of various characters in the cells isestablished by the parties in conversation using the symmetrickey as discussed earlier. The TT is deleted after the creation ofthe symbol table. This comprises a table with two columns without a row orcolumn header. The table maps each printable ASCII characterto a unique integer derived from TT using the symmetric key.The table is mainly used for special encryption and decryptionof ASCII printable RESTful content called symbol table basedencryption (STBE) and symbol table based decryption (STBD) .The Creation of ST , its purpose, and the various steps of STBE and
STBD are covered in the next section.
This component includes a table with two columns withouta row or column header. The table maps the non-variable partsof a RESTful message (XML, JSON or HTML) to a uniqueinteger. The table is used for another encryption and decryptionon ASCII printable RESTful contents called tag table basedencryption (TATBE) and tag table based decryption (TATBD) .The creation of
TAT , its purpose and the various steps involvedin
TATBE and
TATBD are covered in the next section.6 . The Approach
Before further discussion we assume that the
10 element key ( key = [12,6,1,1,1,14,4,1,3,2] ) has already been exchanged be-tween the two parties and TT has been created at both ends. Inthe following subsections, the remaining encryption procedureis discussed based on the and the TT createdbased on this key (Fig. 7). We will be using a running examplefor better understanding of the approach. Figure 8 summarisesour approach. The figure describes both encryption and decryp-tion. Figure 8:
Flow Chart of our Approach
Our purpose is to provide a substitution cipher which con-verts the plain-text into a series of numbers. Such substitutioncipher removes the need of XML canonicalization. As shownin Figure 8, after the creation of TT , the Symbol Table ( ST )gets created as shown in Figure 9. Refer to the various variable and non-variable parts of both encrypted and plain messages aswords. The symbol table maps each character in a non-headercell of the TT to a unique integer. We use this table to replaceeach character in the XML or JSON documents to a correspond-ing unique integer. For example, the word “iiti” gets convertedinto “122122104122” . This is called ST Based Encryption i.e
STBE . Decrypting “122122104122” back into “iiti” is called ST based decryption ( STBD ). The process of ST creation, STBE and
STBD are discussed in the following sub-sections. Sincethe ST can be created based on the key, both partiescan start encryption and decryption using ST without knowingthe structure of the message. Using STBE results in a large sizeencrypted message because each character either in the variableor non-variable parts gets converted to a unique integer. This iswhy we introduced the concept of Tag Table (
TAT ). The
TAT maps the whole variable parts of the message to a unique inte-ger (Fig. 10). Using the Tag Table Based Encryption (
TATBE )results in an encrypted message size that is smaller than the
STBE . For example, the tag “root” can be converted into “04” using the
TATBE instead of “0117126126104” using the
STBE .Decrypting “04” back in “root” is called the Tag Table BasedDecryption (
TATBD ). The process of the
TAT creation,
TATBE and
TATBD are discussed in the following subsections. Theidea is to use the
STBE and
STBD for variable parts and forthose non-variable parts of the message whose
TAT entries stilldo not exists on either side. When the
STBE and
STBD are be-ing used for the non-variable parts, the Tag Table (
TAT ) entryfor the same must be created for later use. Use
TATBE for those variable parts whose entries are present in the
TAT at both sides.
The Symbol Table ( ST ) gets created by the client and serverbased on the Temporary Table ( TT ) in the following manner:The ch and rh of all non-header characters inside the TT areidentified and the corresponding unique number for each non-header symbol in the same is calculated. The procedure forcreating ST is shown below:1. For each non-header and non-empty cell in TT , the print-able character is taken out and its corresponding uniqueinteger value is calculated as value = ( rh ) key [9] + ( ch ) key [9] .For example TT in Fig. 7, character ‘j’ has rh = and ch = . The calculated value = (11) + (2) . So value corre-sponding to ‘j’ in TT is .2. The number of digits in value is made the same as the valueof key[8] . In doing this, we first calculate di ff = key[8] - (no. of digits in value) and then proceed to step 3.For example if key = [12,6,1,1,1,14,4,1,3,2] ( key[8] is )then di ff = - = .3. We calculate the final value that is to be inserted in ST cor-responding to the given non-header character of TT . Wedo it as final value = value × di f f .For example final value of ‘j’ is × = .4. The final record to be inserted in ST is the (character, fi-nal value) pair. The final value is the primary key of ST .If a record in ST exists with the same final value then goto step 5 otherwise, go to step 6 .For example (‘j’,125) is going to be inserted in ST . Beforeinsertion of this record, we first check if a record in ST ex-ists with the same final value (125). For now, we assumethat no such record exists, and therefore go to step 6. If (‘j’,125) is already in ST and (‘o’,125) has to be insertedwe go to step 5.5. When a record with the same final value already exists in ST , the final value of the record is incremented by andchecked for uniqueness. This is continued until a unique fi-nal value is found. Subsequently, step 6 is executed. Notethat even if we considered final value as a primary keymore than one entry of a character is not possible, becauseeach character is unique in TT .For example before inserting a record for character ‘o’ , weincrease its final value to . If a record with final value126 also exists then we make it (‘o’,127) , otherwise, werecord (‘o’,126) and proceed to step 6.6. Insert the record (character, final value) in ST .A subset of ST is shown in Fig.9.7 igure 9: A Subset of ST
By now both the client and server should have the same Tem-porary Table ( TT ) and Symbol Table ( ST ). The client now sendsits first request to the server. The requested resource wouldcomprise several variable and non-variable parts (either XMLor JSON). The non-variable part could be any name and vari-able part could be of any data-type. Until this point, the clientonly knows the URI of the resource and does not know anythingabout the resource representation. If the client makes an HTTPrequest that does not require an HTTP body (e.g GET) then theserver responds after encrypting the response message using ST as STBE . The client decodes this using the Symbol Table BasedDecryption (
STBD ). The decrypted message gets converted intoXML or JSON. In the decrypted document the name of the non-variable parts and data type of the variable parts will be clearto the client. We will explore
STBD in a later sub-section.If the client request requires an HTTP body (e.g PUT, POST)and the client does not have any idea about the resource repre-sentation in the request body (i.e what to send in the requestbody) then the client will send an empty POST request on theURI. In such a case, the server sends an encrypted resourcerepresentation using the
STBE . The
STBE is used by the serverwhen the client is not in the know of the non-variable parts ofthe message. As soon as the client becomes aware of the non-variable parts, the server stops encrypting the message usingthe
STBE and starts encrypting it using the Tag Table BasedEncryption (
TATBE ). We will explore
TATBD in a later sub-section.In the eventuality that the server introduces a new non-variable part in between a conversation, the new non-variable part is encrypted using
STBE and the encryption of the rest ofthe non-variable parts is done through
TATBE . The variable parts of the message always get encrypted using
STBE . Theclient never needs to encrypt the non-variable parts of its re-quest body using the
STBE . This is because the client can neverintroduce a new non-variable part in the request. The client,however, needs to decrypt the non-variable parts of the re-sponse sent out by the server that is encrypted using
STBE . Theprocess of encrypting
XML1 using
STBE and creation of TagTable (
TAT ) for each non-variable parts of the message happens simultaneously at the server side is depicted in the steps below.Lets assume that the encrypted message gets stored in a stringvariable
STEnc . The initial value of
STEnc is null . We have twomore variables noOfNonVars and noOfDigitsForNonVars , bothare initially . The variable and non-variable parts of the XMLare taken in the same order that they appear in the document.We together call these parts (the variable and non-variable partsof the XML) a word . For example in XML1 the order of oc-currence of the words are “root” , “attr1” , “value1” , “attr2” , “value2” , “name” , “iiti” , “ / name” , “value” , “2” , “ / value” and “ / root” .In the case of web service composition di ff erent tags may be-long to di ff erent service providers. Di ff erent tags are thereforeencrypted using di ff erent keys. The receiver must be notifiedabout tag numbers which have been encrypted by its key. Thereare therefore comma separated tag numbers appended at the be-ginning of STEnc followed by space. For a tag number presentat the beginning of
STEnc , the client has access to all child ele-ments of the given tag.For example (1,) at the beginning of
STEnc says that the re-ceiver has access to the tag “root” and its children in
XML1 (i.ewhole document). If (2,) present at the beginning of
STEnc saysthat the receiver has access to the tag “name” and its children in
XML1 . The presence of (2,3,) at the beginning of
STEnc saysthat the receiver has access to the tags “name” and “value” andtheir children in
XML1 . Normally common tags like “root” getencrypted using an agreed upon group-key among members.If word (1,) gets added in STEnc, then STEnc which wasinitially null becomes:
STEnc = “1, ” .1. Repeat step-2 to step-7 for each word in the XML.2. If the word is a tag then the same is converted into a stringof numbers preceded by using the ST reference for eachcharacter of the word. This string of numbers is then con-catenated into a single string STEnc followed by a spaceand step 7 is executed.For example, the first word of XML1 is a tag “root” . Thisconsists of four characters ‘r’ , ‘o’ , ‘o’ and ‘t’ . The ST en-tries corresponding to these characters are ‘117’ , ‘126’ , ‘126’ and ‘104’ respectively. These numbers get con-catenated as “0117126126104” . Therefore, the encryptedform of the tag root along STBE is “0117126126104” .Concatenate the encrypted form of the word in STEnc fol-lowed by a space. If STEnc was initially “1, ” and then itgets updated as:
STEnc = “1, 0117126126104 ” .3. If the word is an attribute-name, the same is converted intoa string of numbers preceded by using the ST referencefor each character of the word. This string of numbers isthen concatenated into STEnc followed by a space and step7 is executed.For example, the second word of XML1 “attr1” is anattribute-name. This consists of five characters ‘a’ , ‘t’ , ‘t’ , ‘r’ and ‘1’ . The Symbol Table ST entries cor-responding to these characters are ‘153’ , ‘104’ , ‘104’ , ‘117’ and ‘340’ respectively. These numbers are con-8atenated as “00153104104117340” . The encryptedform of the attribute-name attr1 along STBE is therefore “00153104104117340” . Concatenate the encrypted formof the word in
STEnc followed by a space. If STEnc wasinitially “1, 0117126126104 ” , it gets updated as:
STEnc = “1, 0117126126104 00153104104117340 ” .4. If the word is an attribute-value, the same is converted intoa string of numbers preceded by using the ST refer-ence for each character of the word. This string of num-bers is then concatenated into STEnc followed by a spaceand step 7 is executed.For example, the third word of XML1 ‘value1” is anattribute-value. This consists of six characters ‘v’ , ‘a’ , ‘l’ , ‘u’ , ‘e’ and ‘1’ . The ST entries corresponding to thesecharacters are ‘850’ , ‘153’ , ‘137’ , ‘820’ , ‘146’ and ‘340’ respectively. These numbers get concatenated as “000850153137820146340” . Therefore, the encryptedform of the attribute-value value1 along STBE becomes “000850153137820146340” . As earlier, this is concate-nated with
STEnc followed by a space. If STEnc was ini-tially “1, 0117126126104 00153104104117340 ” , it getsupdated as:
STEnc = “1, 0117126126104 00153104104117340000850153137820146340 ” .5. is used to represent a closing tag. Whenever a closingtag is encountered is concatenated with the string STEnc followed by a space.6. If the word is a variable part of the XML the same isconverted into a string of numbers using the ST referencefor each character of the word. This string of numbers isthen concatenated into STEnc followed by a space.For example, the seventh word of XML1 “iiti” is a variable part of the XML . This consists of four characters ‘i’ , ‘i’ , ‘t’ and ‘i’ . The ST entries corresponding to thesecharacters are ‘122’ , ‘122’ , ‘104’ and ‘122’ respectively.These numbers are concatenated as “122122104122” .This string of numbers is then concatenated into STEnc followed by a space. After completion of the encryptionof the whole
XML 1 , the encrypted message
STEnc lookslike this:
STEnc = “1, 0117126126104 00153104104117340000850153137820146340 00153104104117349000850153137820146349 0116153109146122122104122 1 0 0850153137820146 349 2 0 0” .Since key[8] decides the size of the Symbol Table BasedEncrypted message, the range of key[8] is from to aninteger depending on the network latency between theservice provider and the client.7. This step is the TAT creation step. This step is arrived atonly for non-variable parts of the XML. The numbers cor-responding to each character in the non-variable words areadded and stored in the variable sum . The number of digitsin the integers representing the non-variable parts of theXML (say noOfDigitsForNonVars ), should be minimumand such that it can accommodate all non-variable partsin it. It can be decided by the server and client separatelyand automatically based on the number of non-variable parts currently in use for communication (say noOfNon-Vars ). The following calculations are next done:(a) noOfNonVars can be calculated as a summation ofthe number of new non-variable parts introduced inthe current message and the number of entries al-ready present in the
TAT .(b) noOfDigitsForNonVars = (cid:100) log ( noO f NonVars + (cid:101) Here we add , because noOfNonVars as a mul-tiple of gives a wrong impression about the noOfDigitsForNonVars , if noOfDigitsForNonVars = (cid:100) log ( noO f NonVars ) (cid:101) . This is because we are us-ing zero for indicating the type of the word, there-fore we should not include zero in the non-variable part of the number mapping. If noOfNonVars is then (cid:100) log ( noO f NonVars ) (cid:101) results in . This im-plies that in such a case we need to necessarily useall digits from to to map the various non-variable parts in TAT . Adding in the above formula removesthis limitation.(c) di ff = noOfDigitsForNonVars - (no. of digits in sum) (d) sum = sum × di f f (e) Finally, the record (word, sum) is stored in TAT .However if the corresponding sum is alreadypresent in
TAT then repeat: sum = ( sum + )%10 noO f DigitForNonVars until sum gets a unique valueother than .For example, the tag “root” consists of four characters ‘r’ , ‘o’ , ‘o’ , ‘t’ . The ST entries corresponding to these char-acters are ‘117’ , ‘126’ , ‘126’ and ‘104’ respectively. Thesteps followed for the word “root” are:(a) sum = + + + = .(b) noOfNonVars = number of new non-variable partsintroduced in the current message ( ) + number ofentries already present in the TAT ( ) = .(c) noOfDigitsForNonVars = (cid:100) log (7 + (cid:101) = .(d) di ff = - = -2 .(e) sum = × − = .(f) The record (root, 4) is stored in TAT , because noother sum is present in
TAT with a value of . Ifanother entry was indeed present in TAT with sum = , then the entry corresponding to “root” storedin TAT would have been (“root”, 5) . The Tag Table(
TAT ) is created simultaneously with
STBE as shownin Figure 10. The
TAT stores the agreed upon inte-gers corresponding to each non-variable part of theXML.
Figure 10:
Tag Table (TAT) non-variable parts be included in the conversation, and so noOfDig-itsForNonVars may increase. Consequently the Tag Ta-ble (
TAT ) would also need to be updated in future to ac-commodate new non-variable parts. In general, a REST-ful communication does not need more than di ff erent non-variable parts (although the same non-variable partsmay be repeated more than times in a message). It istherefore rare for noOfDigitsForNonVars to be more than two .Let us suppose that three new tags are introduced later in“XML 1” as t1 , t2 and t3 , then the following calculationswould need to done:(a) The tag “t1” consists of two characters ‘t’ and ‘1’ with ST mapping of ‘104’ and ‘340’ respectively. sum = + = .(b) noOfNonVars = number of new non-variable partsintroduced in the current message ( ) + number ofentries already present in the TAT ( ) = .(c) noOfDigitsForNonVars = (cid:100) log (10 + (cid:101) = .(d) di ff = - = -1 .(e) sum = × − = .The newly updated Tag Table ( TAT ) is shown in Fig. 11.
Figure 11:
Updated Tag Table
8. The server sends the
STEnc to the client within an HTTPresponse body in the form of plain-text.
Prior to receiving a response to its first request, the clientdoes not have the Tag Table (
TAT ). The client receives the
STEnc as plain-text as a part of the response. The client de-crypts the
STEnc and simultaneously creates the
TAT . Eachspace separated sub-string of numbers in
STEnc is called aword. “(1,)” , “0117126126104” , “00153104104117340” etc.are the various words in STEnc . There are a few global variablesas well. Global variables noOfNonVars and noOfDigitsForNon-Vars are initially and the global variable closed is initially .A global string STDec is defined which is initially null , and aglobal stack s is defined which is initially empty. The followingsteps are next followed:1. The first word conveys the tag number that has been en-crypted using the receiver’s key. In our example, thefirst word is (1,) which implies that the entire encryption (STEnc) has been carried out using the client’s key. Theclient can therefore decrypt the whole encryption.2. Step-3 through step-15 are repeated from the second wordonwards in STEnc .3. If the word starts with a , it implies a tag. The preceding is removed from the word.For example, to decrypt the word , thepreceding is first removed and the word becomes .4. If the word starts with a , it implies an attribute-name.The preceding are removed from the word.For example, to decrypt the word ,the preceding are first removed and the word becomes .5. If the word starts with a , it is an attribute-value. Thepreceding are removed from the word.For example, to decrypt the word , the preceding are re-moved and the word becomes .6. If the word does not start with a , it is a variable part ofthe message.For example, the word does not have a pre-ceding and hence it is a variable part of the message.7. The remaining word is sliced into sub-strings of key[8] characters each.For example, the remaining word is slicedinto substrings of three characters each because key[8] inthis case is . Post slicing the client gets the following foursub-strings: “117” , “126” , “126” and “104” .8. The sub-strings are next converted to integers.9. If the word is non-variable then all its integers are addedand the result is stored in a variable called sum .For the word , sum = + + + = .10. If the word is non-variable then the following calculationsare done:(a) noOfNonVars can be calculated as a summation ofthe number of new non-variable parts introduced inthe current message and the number of entries al-ready present in the TAT .(b) noOfDigitsForNonVars = (cid:100) log ( noO f NonVars + (cid:101) (c) di ff = noOfDigitsForNonVars - (no. of digits in sum) (d) sum = sum × di f f For example the following calculations are done for theword in STEnc :(a) noOfNonVars = number of new non-variable partsintroduced in the current message ( ) + number ofentries already present in the TAT ( ) = .(b) noOfDigitsForNonVars = (cid:100) log (7 + (cid:101) = .(c) di ff = - = -2 .(d) sum = × − = . noOfDigitsForNonVars gets calculated for each word, andgets updated when the number of non-variable words getsincreased. In general a RESTful communication does notneed more than di ff erent non-variable parts (although10ame non-variable parts may be repeated more than times in a message). It is rare therefore, for noOfDigits-ForNonVars to be more than two . This type of examplewas also discussed in the last sub-section.11. The corresponding character for each number found afterslicing the word is identified in ST .In the word for example, “117” belongs to “r” , “126” belongs to “o” and “104” belongs to “t” .12. These characters are concatenated in the same order thatthe corresponding integers appeared in the encryptedword. The concatenated string is stored in the variable var .For example, in the encrypted word thecharacters “r” , “o” , “o” and “t” are concatenated tomake it “root” . var = “root”
13. If var is a non-variable part then the following is done:(a) The record (var, sum) is stored in the
TAT . Howeverif the corresponding sum is already present in
TAT then repeat: sum = ( sum + )% 10 noO f DigitForNonVars until the sum gets a unique value other than .For example the record (root, 4) is stored in TAT , be-cause no other sum is present in
TAT with a valueof . If an entry was present in TAT with sum = ,then the entry corresponding to “root” that would bestored in TAT would be (“root”, 5) . The Tag Table(
TAT ) is created simultaneously with
STBD , which isthe same as the server as shown in Figure 10.(b) If the variable var is a tag and the variable closed = , then STDec = STDec + > + < + var . If closed = then STDec = STDec + < + var . var is pushed into thestack s . The variable closed is updated to closed = .For var = “root” , STDec = “ < root ”. “root” ispushed into the stack and the variable closed is up-dated to closed = .(c) If the var is an attribute-name then STDec = STDec + [space] + var + “ = ” + “‘”.After making var = “attr1” , STDec = “ < rootattr1 = ‘” .(d) If the var is an attribute-value then STDec = STDec + var + ”’”.After making var = “value1” , STDec = “ < rootattr1 = ‘value1’” .14. If var is a variable part then the steps below are followed:(a) If the variable closed = then STDec = STDec + > + var . If closed = then STDec = STDec + var . The variable closed is updated to closed = .(b) Based on the data type of the decrypted variable part,the client decides on the data type contained by itscontainer tag. For example the variable part “iiti” indicates that the container tag < name > contains astring data type.15. If the word comprises a single character 0, a ‘pop’ oper-ation is done on the stack s to find the innermost openedtag. If closed = then STDec = STDec + > + < /+ pop( s ) + > .If closed = then STDec = STDec + < /+ pop( s ) + > . Update closed = . Subsequent to working on all the words of STEnc , the clientgets
STDec as:
STDec = “ < root attr1 = ‘value1’attr2 = ‘value2’ >< name > iiti < / name >< value > < / value >< / root > ” .The created TAT is the same as that of the server and is shownin Figure 10.
The
TATBE exists at both the client and server sides. Afterthe creation of the Tag Table (
TAT ) both the client and serveruse it to encrypt further communications. In between a con-versation, if the server introduces a new non-variable part thenthe new non-variable part gets encrypted using Symbol TableBased Encryption (
STBE ) and the rest of the non-variable partsgets encrypted using
TATBE . A client never needs to introducea new non-variable part of the message. The variable parts ofthe message always gets encrypted using
STBE . TATBE is very similar to
STBE with the only di ff erence beingthat the Symbol Table ( ST ) is used for character-by-characterencryption of the message, and here we use the Tag Table ( TAT )to map the non-variable parts with unique numbers.Lets assume that the encrypted message gets stored in a stringtype global variable
TATEnc . The initial value of
TATEnc is null . The non-variable and variable parts of the XML are con-sidered in the same order in which they appear in the XML. The non-variable and variable parts of the XML together consti-tute a word . For example, in XML1 the order of occurrence ofthe words is “ < root > ” , “attr1” , “value1” , “attr2” , “value2” , “ < name > ” , ”iiti” , “ < / name > ” , “ < value > ” , “2” , “ < / value > ” and “ < / root > ” .Just like STBE there is a comma separated list of tag numbersappended at the beginning of
TATEnc followed by a space. Thislist of tag numbers is an indication to the receiver on which tagand its children have been encrypted using the client’s key.For example, the number (1,) at the beginning of
TATEnc im-plies that the receiver has access to the tag “root” and its chil-dren in
XML1 (i.e the whole document). The number (2,) at thebeginning of
TATEnc implies that the receiver has access to thetag “name” and its children in
XML1 . The presence of (2,3,) atthe beginning of
TATEnc indicates that the receiver has accessto the tags “name” and “value” and their children in
XML1 .We assume here that the whole XML has been encrypted usingthe client’s key.
TATEnc is updated to:
TATEnc = TATEnc + “1,” . The steps involved in the TATBE are as follows.1. Step-2 through step-7 are repeated for each word in theXML.2. If the word is a tag, the
TAT is searched for this word. Ifthe word is found in the
TAT , its corresponding integer isfetched. The fetched integer is converted into a string andis appended with a . We store this string of numbers invariable the var . TATEnc is next updated to:
TATEnc = TATEnc + [space] + var . If the tag is not available in TAT then go to step-6.For example, the first word of
XML1 is a tag “root” . Thistag is found in
TAT . The corresponding integer of the tag,11 , is fetched from the
TAT . This integer is converted toa string and appending with a . var = . TATEnc isupdated to:
TATEnc = TATEnc + [space] + “04” .3. If the word is an attribute-name, the TAT is searched forthis word. If the word is found in the
TAT , its correspond-ing integer is fetched. The fetched integer is convertedinto a string and is appended with with a . This stringof number is stored in the variable var . TATEnc is nextupdated as:
TATEnc = TATEnc + [space] + var . If theattribute-name is not available in TAT then goto step-6.For example, the second word of
XML1 is the attribute-name “attr1” . This attribute-name is available in
TAT . Thecorresponding integer of the attribute-name, , is fetchedfrom the TAT . This integer is converted to a string and ap-pended with . var = . TATEnc is updated to:
TATEnc = TATEnc + [space] + “008” .4. If the word is an attribute-value, the TAT is searched forthis word. If the word is found in the
TAT , its correspond-ing integer is fetched. The fetched integer is convertedinto a string and is appended with a . This string ofnumbers is referred to as var . TATEnc is next updated as:
TATEnc = TATEnc + [space] + var . If the attribute-name isnot available in TAT then goto step-6.For example, the second word of
XML1 is the attribute-value “value1” . This attribute-name is available in
TAT .The corresponding integer of the attribute-name, , isfetched from the TAT . This integer is converted to a stringand appending with . var = . TATEnc is updatedto:
TATEnc = TATEnc + [space] + “0002” .5. is used to represent the closing tag. Whenever a clos-ing tag occurs, is concatenated with the string TATEnc separated by a space.6. If the word constitutes the non-variable part of the XMLwhich is not found in
TAT , the word is converted intoa string of numbers using
STBE . TATEnc is updated as
TATEnc = TATEnc + [space] + result of STBE for word .7. STBE is explored for the given variable word and
TATEnc is updated as:
TATEnc = TATEnc + [space] + result ofSTBE for the word .On completion of the encryption of XML 1 the encryptedmessage
TATEnc looks like
TATEnc = “1, 04 008 0002 0090003 05 122122104122 0 06 349 0 0” .As long as an entry for a word is present in TAT , the serverdoes not use
STBE to encrypt the word. If, however, a new non-variable part is introduced in the XML as shown in
XML2 , the newly introduced non-variable part would need to beencrypted using
STBE while the rest of the non-variable partswould be encrypted using
TATBE . For the XML given in
XML2 the final encrypted message becomes:
TATEnc = “1, 04 0080002 009 0003 05 122122104122 0 06 349 0 0116850 1533400 0” . XML 2:
TAT based decryption and this exists atboth the client and server ends. The Client gets
TATEnc asplain-text in the response whereas the server gets it within therequest body. The receiver decrypts the
TATEnc . Each spaceseparated sub-string of numbers in the
TATEnc is called a word. (1,) , , etc. are the various words in TATEnc . We definea global variable called closed that is initially , a globally de-fined string TATDec that is initially null , and a global stack s that is initially empty.1. The first word indicates the tag numbers that have been en-crypted using the receiver’s key. In our running examplethe first word is (1,) . This indicates that the whole encryp-tion (TATEnc) has been done using the client’s key, andtherefore the client can decrypt the whole XML.2. Step-3 through 12 are repeated for the second word on-wards in TATEnc .3. If the word starts with a , it implies that it is a tag. Thepreceding is removed from the word and it is convertedto an integer.For example to decrypt the word , the preceding is firstremoved and it becomes . The same is then converted toan integer.4. If the word starts with , it implies that it is an attribute-name. The preceding is removed from the word and thesame is converted to an integer.For example to decrypt the word , the preceding isfirst removed and it becomes . The same is then convertedto an integer.5. If the word starts with , it implies that it is an attribute-value. The preceding is removed from the word andthe same is converted to an integer.For example to decrypt the word , the preceding is removed and it becomes . The same is converted to aninteger.6. If the word does not have a preceding , it implies that it isthe variable part of the message. The variable part of themessage gets decrypted using the STBD .7. The non-variable words are first searched in
TAT . If theword is not found in
TAT then the same is decrypted us-ing the
STBD . If, however, the word is found in the
TAT then the corresponding name is fetched and stored in thevariable var .8. If the word is a tag and closed = then TATDec = TAT-Dec + > + < + var . If closed = then TATDec = TATDec + < + var . var is pushed into the stack s and closed is up-dated: closed = .For var = “root” , TATDec = “ < root” . Word “root” ispushed into the stack and closed is update closed = .9. If the word is an attribute-name then TATDec = TATDec + [space] + var + “ = ” + “‘”.After making var = “attr1” , TATDec = “ < root attr1 = ‘” .120. If the word is an attribute-value then TATDec = TAT-Dec + var + “’”.After making var = “value1” , TATDec = “ < rootattr1 = ‘value1’” .11. If the word is a variable part of the XML and closed = then TATDec = TATDec + > + var . If closed = then TAT-Dec = TATDec + var . Variable closed is update to closed = .12. If a single character is found as a word then a pop opera-tion is done on the stack s to find innermost opened tag. If closed = then TATDec = TATDec + > + < /+ pop( s ) + > . If closed = then TATDec = TATDec + < /+ pop( s ) + > . closed is updated: closed = .Subsequent to working on all the words of TATEnc the clientgets
TATDec as “ < root attr1 = “value1”attr2 = “value2” >< name > iiti < / name >< value > < / value >< / root > ” . In a web service composition scenario, there is multiple ser-vice providers that work on the same message but need to haveaccess to only some parts of the message. To realize this, theproposed approach encrypts di ff erent parts of the message withdi ff erent keys. Lets consider a scenario where there is one mainserver (Service Provider) S and two other service providers SP1and SP2. They commonly agree on a key called group key .A client C sends a request to the main server S. S needs toreply to the request with XML 2. In putting together the reply,S requires the services of SP1 and SP2. SP1 is required to up-date the value between the < name > tag and SP2 is required toupdate the values between the < value > and < nv > tags. SP1 andSP2 must not be able to access or update any other tags that donot belong to them. In this situation, there are three symmetrickeys in use. The first one is the key between S and SP1 (sayK1), the second one is the key between S and SP2 (say K2) andthe third one is the agreed upon group key between all S, SP1and SP2 (Say K3). The common tags of the XML will be en-crypted using the group key K3. Tags that are only supposedto be updated by S and SP1 must be encrypted using K1 andtags that are only supposed to be updated by S and SP2 must beencrypted using K2.The first word of the encrypted message tells SP1 and SP2about one or more tag numbers separated by a comma thatthey are supposed to process. If secret key of SP1-S is [12,6, 1, 1, 1, 14, 4, 1, 3, 2] , secret key of SP2-S is [6, 12, 1, 0,1, 14, 3, 1, 3, 2] and group key is [7, 10, 0, 0, 1, 14, 3, 0, 3,2] . SP1 is supposed to process the second tag i.e name andits child. SP2 is supposed to process the third and fourth tagsi.e value and nv and their children. TAT based Message fromS to SP1 is: “2, 01 009 0002 003 0004 05 1221221041220 07 313 0 08 356290 0 0” . ST based Message fromS to SP1 is: “2, 0232325325180 00137180180232257000136137126157314257 00137180180232226000136137126157314226 0116153109146 1221221041220 0291356265326320 313 0 0410291 356290 0 0” . TAT basedMessage from S to SP2 is: “3,4, 01 009 0002 003 0004 05 122122104122 0 07 313 0 08 356290 0 0” . ST based Messagefrom S to SP2 is: “3,4, 0232325325180 00137180180232257000136137126157314257 00137180180232226000136137126157314226 0116153109146 122122104122 00291356265326320 313 0 0410291 356265 0 0” .This web service composition scenario is just an example.Various other compositions are also possible. Message authentication is a compulsory step in any conver-sation where there is a possibility of updates by others in themiddle because encrypted message can also be changed. Formessage authentication, we use existing algorithms like MD5,SHA1 etc. To exemplify this, we know from the earlier examplethat the tag that belongs to S and SP1 is < name > . As both S andSP1 want a confirmation that tag < name > which is the secondtag is not changed by an intermediary. Therefore, to achievemessage authentication after encrypting the tag < name > , thesender (S) prefixes K1 to the encrypted tag and creates a hash(say MD5) of it . The overall hash is attached at the end of thecorresponding tag.The sequence of steps followed by the sender (S) and receiver(SP1) is:1. Sender encrypts the message using TATBE as above.2. The
TAT based encryption of the < name > tag is “05122122104122 0” . This is appended with the private keyK1 by the sender as “[12,6,1,1,1,14,4,1,3,2]05 122122104122 0” .3. The sender calculates the MD5 of “[12,6,1,1,1,14,4,1,3,2]05 122122104122 0” as “adc1ae ff e1fe867740f976fd55c0c481” (say D1 ).4. The TAT based encryption of the < root > tag is “01 0090002 003 0004 05 122122104122 0 07 313 0 08 3562900 0” . This is appended with the group key K3 by thesender as “[7,10,0,0,1,14,3,0,3,2]01 009 0002 003 000405 122122104122 0 07 313 0 08 356290 0 0” .5. The sender (S) calculates the MD5 of “[7,10,0,0,1,14,3,0,3,2]01 009 0002 003 0004 05122122104122 0 07 313 0 08 356290 0 0” as “72afa9838090da9c5d82d2060c42f48c” (say D2 ).6. Before sending the reply the sender appends these digestsjust after closing the corresponding tag for which digestshave been calculated. D1 is appended after closing the sec-ond tag and D2 is appended after closing of the “ < root > ” tag.7. The sender sends the message: “2, 01 009 0002 003 000405 122122104122 0 D1 07 313 0 08 356290 0 0 D2” .There is no need to authenticate the third and fourth tagsbecause these do not belong to SP1.8. The first word “(2,)” conveys to the receiver that it has towork on the second tag. It is known to all that the firsttag “ < root > ” is encrypted using a group key, as this tagcontains all other tags.9. The variable part at the end of a tag that contains alpha-betic characters is the message digest of the corresponding13ag. For example, D1 is present just after closing the sec-ond tag, which is why the receiver considers it as a digestof the second tag and its children. Similarly, D2 is the di-gest of the first tag ( “ < root > ” ) and its children. Althoughthe whole “ < root > ” tag and its children are not encryptedusing the client’s key, the overall digest D2 is created byappending the K3.10. The receiver takes out the second word of the encryptedmessage and D1, and further calculates its digest in thesame way as the sender did in step-3 using K1. If the di-gest calculated by the receiver is the same as D1 then themessage is authentic. If they are not the same, the messagewill be rejected.11. The receiver calculates the digest of the whole messagethat the sender did it in step-5 using K3. If the digest cal-culated by the Receiver is the same as D2 then the messageis authentic. If they are not same, the message will be re-jected.A Similar process is followed to authenticate the Symbol Ta-ble Based Encryption. In case of communication between S andSP2 the sender will use K2 instead of K1. The message from Sto SP2 is: “2, 01 009 0002 003 0004 05 1221221041220 07 313 0 5f4 ff dd89acc919420ac885e6017bcfc 08356290 0 44e9e15af5f4289bab86c90e0d9398d1 072afa9838090da9c5d82d2060c42f48c” . JSON has a di ff erent structure from XML but both are inter-changeable with each other. We can easily convert XML 1 toJSON 1 as shown.We treat JSON names, values of a JSON name that start witha ‘-’ as non-variable words and double quoted JSON names as variable words. An array in JSON is considered a repetition ofa tag and the values in between them are consecutive elementsof an array. Closing the curly bracket denotes the end of theinnermost open tag.As XML and JSON are equivalent, their encryption as stringof numbers must also be the same.
4. Advantage of the proposed approach
Here we present the salient feature of the proposed techniquehighlighting its strength as compared to existing techniques.
As mentioned earlier, canonicalization converts logicallyequivalent XML documents to ones with identical physicalstructures. We require XML canonicalization if we encrypt anXML or part of the XML byte-by-byte. Formal security tech-niques provided by w3c and OASIS for SOAP based web ser-vices [3] need XML canonicalization. But since our encryptiontechnique is a text based substitution (Character to number), wedo not need XML canonicalization.
As the encryption of XML and JSON that represent the samedata results in identical messages in the proposed approach.The message may also be decrypted to any of the two forms.The approach therefore seamlessly works with both XML andJSON contents.
We do not send any extra HTTP headers as in the case ofSerme, G. et. al [11]. In our case the agreement on a key be-tween a service provider and its client results in a compromiseof statelessness of RESTful web services to a very small extent.
In the dynamic web services composition where a serviceprovider may enter or leave the group randomly, the resourceitself becomes a sensitive document. Putting the resource rep-resentation in the public domain is not good for such a sce-nario. As already discussed in our approach, the client requestsa resource whose representation is not known to it with a GETmethod and the encrypted resource is transferred using Sym-bol Table Based Encryption (STBE). If the client uses an emptyPOST or PUT the request the server explicitly sends the en-crypted resource representation to the client using
STBE . The proposed approach facilitates di ff erent parts of the samemessage to be encrypted with di ff erent keys. The various inter-mediaries are notified about the tag number on which they haveto work. An intermediary therefore does not get any sense ofothers’ data. If an intermediary does try to change others’ data,the receiver will simply reject it because of message authenti-cation. The size of an HTTP message should be as small as possiblein RESTful communication. The encrypted message createdusing this approach is much smaller in size than that of other ex-isting algorithms. Further, if the number of non-variable char-acters is larger than the number of variable characters, the sizeof the encrypted message is even smaller than the size of theactual message itself. However if the number of variable char-acters dominates over the number of non-variable (which is rel-atively rare) characters the size of the encrypted message usingour approach may sometimes become larger than that of exist-ing approaches. In this case the size of the encrypted messagelargely depends on key[8] . Table 1 describes the size compari-son of encrypted messages using various encryption algorithmson various types of XML data. Here we do encryption on thewhole XML, not on a given part of the XML. The key used forSTBE and TATBE is [12,6,1,1,1,14,4,1,3,2] . Here we includevarious characters like <, >, /, “ , = etc used for the non-variable parts in the count of the number of characters used in the non-variable parts.14 able 1: Size comparison of various encryption techniques on various XML Column 1 Column 2 Column 3 Column 4 Column 5 Column 6 Column 7 Column 8 Column 9 Column 10
12 12 161 6 101 318 473 441 565 37618 45 637 24 404 1209 1665 1625 2185 148022 89 1235 48 808 2397 3245 3213 4345 293818 45 627 24 627 1432 1965 1921 2845 21408 27694 341167 27644 64961 433776 615258 578380 637558 3607701 1 39 1 1 41 64 40 59 93 3 12 1 12 26 89 57 57 511 1 7 1 17 25 32 40 59 57
Column1 represents the number of unique { non-variable } parts of the document. Column2 represents the number of { non-variable } parts used in the document. Column3 represents the number of characters in the { non-variable } parts. Column4 represents the number of { variable } parts. Column5 represents the number of characters in the { variable } parts. Column6 represents the total number of characters in the XML (Including new line characters and a few space characters).
Column7 represents the number of characters in AES (Rijndael 256) encryption.
Column8 represents the number of characters in 3DES encryption.
Column9 represents the number of characters in STBE encryption.
Column10 represents Number of characters in TATBE encryption.
This is especially true in the condition that a service providerwithin the group is the attacker. This, in fact, makes this ap-proach especially useful. The following points make this en-cryption hard to attack:1. The key is generated randomly and sent to theother party using TLS. It is therefore not possible for otherservice providers to sni ff the key.2. A brute force attack is not possible. This is so becausefirst, it is very hard to go through all possible values forall ten elements, and then to create various tables for allpossibilities, and further to decrypt a part of the XML thatdoes not belong to the attacker with all possible keys. Evenif the attacker manages the above, it will not be sure whichone is the correct decryption.3. Message authentication prevents an attacker from chang-ing the unauthorized part of the XML through hit and trial.4. The Known plain-text attack [12] is the most dangerousfor this approach. This attack is possible if the attackerhas a valid plain-text / cipher-text pair. Using this, the at-tacker can try to guess the further encrypted message oreven the key. If somehow the attacker is able to map be-tween the various characters and the number or the tag-name and the number, then all of the encryption will becompromised. The question here is how will the attackerget a valid cipher-text / plain-text pair in a web service com-position scenario.5. The chosen plain-text attack [13] is a attack that presumesthat the attacker can get a cipher-text for any random plain-text and can try to guess the further conversation or the keyitself. In case of web service composition the attacker isa service provider and would have a di ff erent shared key,and therefore it can not possibly get an encrypted messagewith other’s key. 6. Various security aspects on RESTful web services are de-scribed by OWASP [14]. Here we are dealing with onlythe message level security. In our approach XML andJSON input validation and message integrity are providedthrough message authentication of the XML or JSON doc-ument.
5. Conclusion
In this paper, we proposed a novel approach for messagelevel security in RESTful web services. This approach is akind of substitution cipher which replaces di ff erent charactersby a unique integer. Various tag-names, arguments and valuesof arguments were also replaced by corresponding unique inte-gers. Substitution from character to number removes the needfor XML canonicalization. This approach removes the needfor content negotiation for the same resource among serviceproviders and clients, and also reduces the size of the overallencrypted message. We applied this approach on several XMLand JSON data and found that for most of the cases our ap-proach resultd in smaller sized encrypted messages than thoseof existing approaches. We also demonstrated the e ffi ciency ofthe proposed message in web services composition scenariosthrough encrypting di ff erent tags with di ff erent keys, and alsomaintained message authentication. The discussed algorithmswere implemented in JAVA. Acknowledgment
The authors would like to thank the “Department of Elec-tronics and IT (DeitY), Government of India” for funding thisproject.15 eferences [1] R. T. Fielding, “architectural styles and the design of network-based soft-ware architectures,” ,Ph.D. dissertation, University of California, Irvine,2000.[2] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Pro-tocol Version 1.2”, RFC 5246, DOI 10.17487 / RFC5246, August 2008, < http: // / info / rfc5246 > .[3] Nils Agne Nordbotten, “XML and Web Services Security Stan-dards” ,IEEE Communication Surveys & Tutorials, VOL. 11, NO. 3,Third Quarter 2009.[4] Mark Bartel, John Boyer, Barb Fox, Brian LaMacchia, Ed Si-mon, “XML Signature Syntax and Processing Version 2.0” ,http: // / TR / xmldsig-core2 / , W3C Working Group Note23 July 2015.[5] Takeshi Imamura, Blair Dillaway, Ed Simon, Kelvin Yiu, Mag-nus Nystrm, “XML Encryption Syntax and Processing Version 1.1” ,http: // / TR / xmlenc-core1 / , W3C Recommendation 11 April2013.[6] Chown, P., “Advanced Encryption Standard (AES) Ciphersuites forTransport Layer Security (TLS)”, RFC 3268, DOI 10.17487 / RFC3268,June 2002, < http: // / info / rfc3268 > .[7] Kelly, S., “Security Implications of Using the Data Encryption Stan-dard (DES)”, RFC 4772, DOI 10.17487 / RFC4772, December 2006, < http: // / info / rfc4772 > .[8] Eastlake 3rd, D. and T. Hansen, “US Secure Hash Algorithms (SHAand HMAC-SHA)”, RFC 4634, DOI 10.17487 / RFC4634, July 2006, < http: // / info / rfc4634 > .[9] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller,“Elliptic Curve Cryptography (ECC) Cipher Suites for Transport LayerSecurity (TLS)”, RFC 4492, DOI 10.17487 / RFC4492, May 2006, < http: // / info / rfc4492 > .[10] John Boyer, Glenn Marcy, Pratik Datta, Frederick Hirsch, “CanonicalXML Version 2.0”,W3C Working Group Note 11 April 2013.[11] Serme, G., de Oliveira, A.S., Massiera, J., Roudier, Y., “ Enabling Mes-sage Security for RESTful Services” ,2012 IEEE 19th International Con-ference on Web Services.[12] Alex Biryukov, “ Known Plaintext Attack” ,pp. 704-705, Springer US,Boston, MA, 2011.[13] Alex Biryukov, “ Chosen plaintext attack” ,pp. 205-206, Springer US,Boston, MA, 2011.[14] “REST Security Cheat Sheet”, OWASP Cheat Sheets, 10 April 2016, < https: // / index.php / REST Security Cheat Sheet > ..