Method for transferring messages comprising extensible markup language information

Methods for transferring messages (30) comprising extensible markup language information from sources (104) via intermediates (105) to destinations (106) are provided with hop-by-hop encryption/decryption processes instead of end-to-end encryption/decryption processes to reduce a complexity and to make non-encrypted messages (30) available inside the intermediates (105). The encryption/decryption processes are different per hop. An encryption/decryption of the message (30) comprises an encryption/decryption of one or more fields of the message (30) and may comprise an addition/detection of a signature. The message (30) may comprise a start envelope field (32), a header field (33-35), a body field (36-38) and a stop envelope field (39). The message (30) may comprise a simple object access protocol message or SOAP message.

The invention relates to a method for transferring a message comprising extensible markup language information from a source via an intermediate to a destination.

Extensible markup language information (XML information) is information based on an extensible markup language and/or is information comprising an extensible markup language code. General examples of such a source are source devices such as personal computers and servers and mobile phones. General examples of such an intermediate are intermediate devices such as servers, multiplexers, switches, routers, forwarders and bridges. Other general examples of such an intermediate are intermediate systems comprising such servers, multiplexers, switches, forwarders and bridges, and intermediate networks comprising such servers, multiplexers, switches, forwarders and bridges. General examples of such a destination are destination devices such as personal computers and servers and mobile phones.

A prior art method is of common general knowledge. According to this prior art method, a message comprising extensible markup language information is transferred from a source via an intermediate to a destination. In case the message needs to be encrypted, it is encrypted inside the source. It is then passed via the intermediate to the destination, and it is decrypted inside the destination. So, no encryption/decryption takes place inside the intermediate. In other words, in the known method the encryption/decryption is end-to-end.

The known method is disadvantageous, inter alia, owing to the fact that usually each pair of a source and a destination has its own encryption/decryption process. As a result, a source must retrieve encryption/decryption information for each possible destination and/or must store this encryption/decryption information for each possible destination. This makes the prior art method relatively complex.

It is an object of the invention, inter alia, to provide a method as defined above that is relatively simple.

The method according to the invention is characterized in that the method comprisesa first step of, at the source, encrypting the message according to a first encryption/decryption process for gaining a firstly encrypted message and transmitting the firstly encrypted message to the intermediate,a second step of, at the intermediate, receiving the firstly encrypted message and decrypting the firstly encrypted message according to the first encryption/decryption process for regaining the message,a third step of, at the intermediate, encrypting the message according to a second encryption/decryption process for gaining a secondly encrypted message and transmitting the secondly encrypted message to the destination, anda fourth step of, at the destination, receiving the secondly encrypted message and decrypting the secondly encrypted message according to the second encryption/decryption process for regaining the message.

By introducing a hop-by-hop encryption/decryption instead of the known end-to-end encryption/decryption, between the source and the intermediate a first encryption/decryption process is used and between the intermediate and the destination a second encryption/decryption process is used. As a result, it is no longer necessary to retrieve encryption/decryption information for many possible destinations and/or to store this encryption/decryption information for many possible destinations. Only encryption/decryption information for a few intermediates is to be retrieved and/or only the encryption/decryption information for a few intermediates is to be stored. The method according to the invention is therefore relatively simple.

The method according to the invention is further advantageous, inter alia, in that inside the intermediate the non-encrypted message is available for routing and monitoring and other purposes and in that hop-by-hop encryption/decryption allows messages to be multicasted and/or broadcasted, which is difficult for end-to-end encryption/decryption.

Other advantages of the hop-by-hop encryption/decryption are that it is relatively simple to encrypt also source information, intermediate information and destination information (such as identifications and addresses etc.) during a transfer, which is difficult for end-to-end encryption/decryption, and that a transmitting party only needs to resolve a (single) intermediate instead of each destination. This will make e.g. a Domain Name Server resolution much simpler.

More particular examples of such a source and such a destination are optimized XML-documents transfer protocol enabled platforms (OXTP enabled platforms) that can transmit and receive optimized XML-documents via a transfer protocol. OXTP enabled platforms can be “dedicated” platforms such as smart devices like traffic lights, refrigerators, radiators, doors/gates, light switches, etc. and can be “general purpose” platforms such as smart devices like personal computers, servers, personal digital assistants, etc. and can be any mix of the above like mobile phones, set top boxes, etc. In other words, OXTP enabled platforms can be devices or systems that run one or more OXTP enabled programs (services, applications) with which other programs can communicate. More particular examples of such an intermediate are OXTP enabled platforms that can transfer optimized XML-documents. The method may then comprise and/or form part of a federated security optimized XML-document transfer protocol. An optimized XML-document may comprise, in addition to the usual ASCII characters, a binary blog etc.

US 2005/0266826 discloses a method for establishing a security association between a wireless access point and a wireless node. US 2005/0157660 discloses a model for enforcing different phases of the end-to-end negotiation protocol. US 2005/0144457 discloses a message security processing system for web services. US 2004/0168064 discloses a system for digital signature and encryption to XML. US 2004/0078577 discloses a method and apparatus for providing XML document encryption. US 2003/0200349 discloses XML scripting of SOAP commands. US 2002/0054170 discloses end-to-end transaction processing and statusing system and method. None of these documents discloses the hop-by-hop encryption/decryption according to the invention for messages comprising extensible markup language information.

An embodiment of the method according to the invention is characterized in that the first and second encryption/decryption processes are different encryption/decryption processes.

The use of a different encryption/decryption process for a different hop will protect different hops in different ways. For example in case of using public keys and private keys, per hop a transmitting party needs to know or to find out a public key of a receiving party. So, per hop the receiving party defines the public key to be used.

An embodiment of the method according to the invention is characterized in that the encrypting comprises an addition of a signature and in that the decrypting comprises a detection of the signature.

The added signature identifies the sender and improves the overall security and is a great additional advantage. The detection of the signature for example comprises a verification of the signature. The additional use of a different signature/verification process for a different hop will protect different hops additionally in different ways. As is for hop-by-hop encryption/decryption, hop-by-hop signature/verification provides the benefit that the destination does not have to store and/or use all keys of all sources just like the source does not have to store and/or use the keys of all destinations. As a result, a trusted chain is created where e.g. a telecom operator can provide the intermediate (in-the-middle) trust (encryption and signing) between all parties simpler.

An embodiment of the method according to the invention is characterized in that the message comprises a start envelope field, a header field, a body field and a stop envelope field, an encryption of the message comprising an encryption of one or more fields of the message and a decryption of the message comprising a decryption of these one or more fields of the message.

The source can define which field is to be encrypted and/or which fields are to be encrypted. In a minimum situation only one field may be encrypted. In a maximum situation, all fields apart from a message indicator preceding the start envelope field may be encrypted. In the prior art, it was cumbersome to encrypt the header field owing to the fact that the intermediate must be able to route the message. According to the invention, the non-encrypted message is available in the intermediate, and as a result between the source and the intermediate the header field can now be encrypted as well, which further improves the overall security and is a great additional advantage.

Other kinds of fields are not to be excluded. So, in general, the message comprises one or more fields, and an encryption of the message comprises an encryption of at least one of these one or more fields of the message and a decryption of the message comprises a decryption of at least one of these one or more fields of the message.

An embodiment of the method according to the invention is characterized in that the message comprises a simple object access protocol message.

Especially but not exclusively for simple object access protocol messages the hop-by-hop encryption/decryption is expected to become a technical and commercial success.

The invention also relates to an intermediate for performing the second step and the third step of the method according to the invention.

The intermediate according to the invention is characterized in that the intermediate comprisesa receiver for said receiving of the firstly encrypted message,a decryption unit for said decrypting of the firstly encrypted message according to the first encryption/decryption process for regaining the message,an encryption unit for said encrypting of the message according to the second encryption/decryption process for gaining the secondly encrypted message, anda transmitter for said transmitting of the secondly encrypted message to the destination.

An embodiment of the intermediate according to the invention is characterized in that the first and second encryption/decryption processes are different encryption/decryption processes.

An embodiment of the intermediate according to the invention is characterized in that the encrypting comprises an addition of a signature and in that the decrypting comprises a detection of the signature.

An embodiment of the intermediate according to the invention is characterized in that the message comprises a start envelope field, a header field, a body field and a stop envelope field, an encryption of the message comprising an encryption of one or more fields of the message and a decryption of the message comprising a decryption of these one or more fields of the message.

An embodiment of the intermediate according to the invention is characterized in that the message comprises a simple object access protocol message.

An embodiment of the intermediate according to the invention is characterized in that the decryption unit is arranged to decrypt encrypted messages originating from at least one neighboring intermediate, source and/or destination and is not arranged to decrypt encrypted messages originating from at least one non-neighboring intermediate, source and/or destination and in that the encryption unit is arranged to encrypt messages destined for at least one neighboring intermediate, source and/or destination and is not arranged to encrypt messages destined for at least one non-neighboring intermediate, source and/or destination.

In a general situation, such as a non-emergency situation or a non-privileged situation, the decryption unit cannot decrypt encrypted messages originating from (at least some) non-neighboring intermediates, sources and destinations, and the encryption unit will not encrypt messages destined for (at least some) non-neighboring intermediates, sources and destinations. In a particular situation, such as an emergency situation or a privileged situation, it is not to be excluded that an end-to-end encryption/decryption is to be used, but only for a limited number of destinations.

The invention also relates to a source for performing the first step of the method according to the invention.

The source according to the invention is characterized in that the source comprisesan encryption unit for said encrypting of the message according to a first encryption/decryption process for gaining a firstly encrypted message, anda transmitter for said transmitting of the firstly encrypted message to the intermediate.

An embodiment of the source according to the invention is characterized in that the encryption unit is arranged to encrypt messages destined for at least one neighboring intermediate and is not arranged to encrypt messages destined for at least one non-neighboring intermediate.

The invention also relates to a destination for performing the fourth step of the method according to the invention.

The destination according to the invention is characterized in that the destination comprisesa receiver for said receiving of the secondly encrypted message, anda decryption unit for said decrypting of the secondly encrypted message according to the second encryption/decryption process for regaining the message.

An embodiment of the destination according to the invention is characterized in that the decryption unit is arranged to decrypt messages destined for at least one neighboring intermediate and is not arranged to decrypt messages destined for at least one non-neighboring intermediate.

Embodiments of the source according to the invention and of the destination according to the invention correspond with the embodiments of the intermediate according to the invention. The source and the destination can be produced and/or sold separately from the intermediate.

The invention is based upon an insight, inter alia, that for a large number of possible destinations an end-to-end encryption is relatively complex from a point of view of a transmitting party, and is based upon a basic idea, inter alia, that for a large number of possible destinations in combination with a small number of possible intermediates a hop-by-hop encryption is relatively simple from a point of view of the transmitting party.

The invention solves the problem, inter alia, to provide a method that is relatively simple. The method according to the invention is further advantageous, inter alia, in that inside the intermediate the non-encrypted message is available for routing and monitoring and other purposes and in that hop-by-hop encryption/decryption allows messages to be multicasted and/or broadcasted, which is difficult for end-to-end encryption/decryption.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments(s) described hereinafter.

The network shown in theFIG. 1comprises nodes1-9, the nodes being sources, intermediates and/or destinations according to the invention. The node1is coupled to the nodes2and4, the node2is further coupled to the nodes3and5, the node3is further coupled to the node6, the node4is further coupled to the nodes5and7, the node5is further coupled to the nodes6and8, the node6is further coupled to the node9, the node7is further coupled to the node8which is further coupled to the node9.

According to an example, the node4is a source104, the node5is an intermediate105and the node6is a destination106, and a message30shown in theFIG. 3is sent from the node4via the node5to the node6. Examples of the source104and the destination106are personal computers and servers and mobile phones. Examples of the intermediate105are servers, multiplexers, routers, switches, forwarders and bridges, systems comprising such servers, multiplexers, routers switches, forwarders and bridges, and networks comprising such servers, multiplexers, routers switches, forwarders and bridges. So, each node1-9may be a device, a system or a network.

More in particular, each node may be an optimized XML-documents transfer protocol enabled platform (OXTP enabled platforms) that can transmit and/or transfer and/or receive optimized XML-documents via a transfer protocol. OXTP enabled platforms can be “dedicated” platforms such as smart devices like traffic lights, refrigerators, radiators, doors/gates, light switches, etc. and can be “general purpose” platforms such as smart devices like personal computers, servers, personal digital assistants, etc. and can be any mix of the above like mobile phones, set top boxes, etc. In other words, OXTP enabled platforms can be devices or systems that run one or more OXTP enabled programs (services, applications) with which other programs can communicate.

Each coupling between two nodes may be a wired coupling, a wireless coupling or a partly wired and partly wireless coupling, without departing from the scope of this invention.

In a prior art situation, the message30comprising extensible markup language information is encrypted inside the source104. It is then passed via the intermediate105to the destination106, and it is decrypted inside the destination106. So, no encryption/decryption takes place inside the intermediate105. In other words, in the known method the encryption/decryption is end-to-end. Usually each pair of a source104and a destination106has its own encryption/decryption process. As a result, a source104must retrieve encryption/decryption information for each possible destination106and/or must store this encryption/decryption information for each possible destination106. This makes the prior art situation relatively complex.

According to the invention, a hop-by-hop encryption/decryption is used instead of the known end-to-end encryption/decryption. Between the source104and the intermediate105a first encryption/decryption process is used and between the intermediate105and the destination106a second encryption/decryption process is used. As a result, it is no longer necessary to retrieve encryption/decryption information for many possible destinations and/or to store this encryption/decryption information for many possible destinations. Only encryption/decryption information for a few intermediates is to be retrieved and/or only the encryption/decryption information for a few intermediates is to be stored. This is simpler and further advantageous owing to the fact that inside the intermediate the non-encrypted message is available for routing and monitoring and other purposes and that hop-by-hop encryption/decryption allows messages to be multicasted and/or broadcasted, which is difficult for end-to-end encryption/decryption.

In theFIG. 2, steps10-21of a method according to the invention are shown. The method may for example comprise and/or form part of a federated security optimized XML-document transfer protocol. The steps10-21have the following function:Step10: In case (optionally) the message30arrives from outside the source104(for example in a different format), the message30is received and/or detected and/or converted into for example a simple object access protocol message or SOAP message at the source104, goto step11.Step11: The message30is encrypted according to a first encryption/decryption process for gaining a firstly encrypted message30at the source104, goto step12.Step12: The firstly encrypted message30is transmitted from the source104to the intermediate105, goto step13.Step13: The firstly encrypted message30is received from the source104at the intermediate105, goto step14.Step14: The firstly encrypted message30is decrypted according to the first encryption/decryption process for regaining the message30at the intermediate105, goto step15.Step15: In case (optionally) the intermediate105comprises a network or a system, the message30is for example processed for network-internal or network-external or system-internal or system-external purposes at one part of the intermediate105and is for example transmitted to another part of the intermediate105, goto step16.Step16: In case (optionally) the intermediate105comprises a network or a system, the message30is for example received from the one part of the intermediate105and is for example processed for network-internal or network-external or system-internal or system-external purposes at the other part of the intermediate105, goto step17.Step17: The message30is encrypted according to a second encryption/decryption process for gaining a secondly encrypted message30at the intermediate105, goto step18.Step18: The secondly encrypted message30is transmitted to the destination106, goto step19.Step19: The secondly encrypted message30is received from the intermediate105at the destination106, goto step20.Step20: The secondly encrypted message30is decrypted according to the second encryption/decryption process for regaining the message30, goto step21.Step21: In case (optionally) the message30is destined to leave the destination106(for example in a different format), the message30is detected and/or converted into for example a non-SOAP message at the destination106and/or transferred.

The first and second encryption/decryption processes are preferably different encryption/decryption processes, to protect different hops in different ways. For example in case of using public keys and private keys, per hop a transmitting party needs to know or to find out a public key of a receiving party. So, per hop the receiving party defines the public key to be used.

In theFIG. 3, an example of a message30is shown comprising extensible markup language information in the form of an extensible markup language envelope. An extensible markup language envelope is an envelope that is based on an extensible markup language and/or is an envelope comprising an extensible markup language code. This message30for example comprises a message indicator31, a start envelope field32, a start header field33, a header field34, a stop header field35, a start body field36, a body field37, a stop body field38, and a stop envelope field39. The encryption of the message30comprises an encryption of one or more fields of the message30and a decryption of the message30comprising a decryption of these one or more fields of the message30. Usually, the message indicator31is not to be encrypted such that a receiving party is able to understand what kind of message has arrived. The source104can define which field is to be encrypted and/or which fields are to be encrypted. In a minimum situation only one field may be encrypted. In a maximum situation, all fields apart from the message indicator31preceding the start envelope field32may be encrypted. In the prior art, it was not possible to encrypt the header field owing to the fact that the intermediate105must be able to route the message. According to the invention, the non-encrypted message is available in the intermediate105, and as a result between the source104and the intermediate105the header field can now be encrypted as well, which further improves the overall security and is a great additional advantage. The message30may comprise other and/or further fields without departing from the scope of this invention. Its envelope fields32and39are based on an extensible markup language. The message may alternatively be a message of a federated security optimized XML-document transfer protocol (FS-OXTP).

The encrypting is not to be looked at to narrowly and may further comprise an addition of a signature and the decrypting is not to be looked at to narrowly and may further comprise a detection of the signature. The added signature identifies the sender and improves the overall security and is a great additional advantage. The detection of the signature for example comprises a verification of the signature.

The message30for example comprises a simple object access protocol message or SOAP message, without excluding other kinds of messages comprising extensible markup language information. The hop-by-hop encryption/decryption is expected to become a technical and commercial success for SOAP messages.

In case of a message per hop getting a signature, being encrypted, being decrypted and being detected for its signature, in this particular order, the following steps may be performed to realize a resolution process that is much alike a Domain Name Server look-up but now specific to the FS-OXTP:the source resolves a first intermediate,the source signs and then encrypts, the XML-document is then put on a transport protocol of choice e.g. MIME, HTTP, TCP, UDP thereby making use of existing resolution protocols e.g. DNS and will arrive in the first intermediate,the first intermediate decrypts and then verifies a signature of the source,the first intermediate resolves a next intermediate (or a destination),the first intermediate signs and then encrypts, the XML-document is then put on a transport protocol of choice e.g. MIME, HTTP, TCP, UDP thereby making use of existing resolution protocols e.g. DNS and will arrive in the next intermediate (or destination), these intermediate steps are repeated for each next intermediate until the XML-document has reached the destination, andthe destination decrypts and then verifies a signature of the last intermediate.

The source may opt to either not, partly or fully specify the intermediate(s) in the FS-OXTP (as can also be done in OXTP, or in SOAP by means of WS-Addressing). In the first case, the destination will be resolved to the first (or next) intermediate. In the latter cases, the first (or next) intermediate will be resolved either to itself or to another first (or next) intermediate.

The resolution process can be anything from “flat static” tables to “hybrid/hierarchical dynamic” tables, without excluding algorithms, rules, (international) naming conventions and mixtures of these possibilities.

In theFIG. 4, a node4representing a source104according to the invention is shown, and in theFIG. 5, a node5representing an intermediate105according to the invention is shown, and in theFIG. 6, a node6representing a destination106according to the invention is shown.

The node5representing an intermediate105comprises an interface53with an external side and an internal side. The external side is coupled to a coupling that is further coupled to the node4. The internal side comprises a receiving side coupled via a receiver54aand a decryption unit54bto a switch50for receiving a message from the node4and for supplying this message to the switch50. The internal side further comprises a transmitting side coupled via a transmitter52aand an encryption unit52bto the switch50for receiving a message from the switch50and for transmitting this message to the node4. The switch50, encryption unit52b, transmitter52a, interface53, receiver54aand decryption unit54bare further coupled to a controller51.

The node5further comprises an interface57with an external side and an internal side. The external side is coupled to a coupling that is further coupled to the node6. The internal side comprises a receiving side coupled via a receiver58aand a decryption unit58bto the switch50for receiving a message from the node6and for supplying this message to the switch50. The internal side further comprises a transmitting side coupled via a transmitter56aand an encryption unit56bto the switch50for receiving a message from the switch50and for transmitting this message to the node6. The switch50, encryption unit56b, transmitter56a, interface57, receiver58aand decryption unit58bare further coupled to a controller55.

The node4representing a source104comprises an interface47with an external side and an internal side. The external side is coupled to a coupling that is further coupled to the node5. The internal side comprises a receiving side coupled via a receiver48aand a decryption unit48bto the switch40for receiving a message from the node5and for supplying this message to the switch40. The internal side further comprises a transmitting side coupled via a transmitter46aand an encryption unit46bto the switch40for receiving a message from the switch40and for transmitting this message to the node5. The switch40, encryption unit46b, transmitter46a, interface47, receiver48aand decryption unit48bare further coupled to a controller45.

The node6representing a destination106comprises an interface63with an external side and an internal side. The external side is coupled to a coupling that is further coupled to the node5. The internal side comprises a receiving side coupled via a receiver64aand a decryption unit64bto a switch60for receiving a message from the node5and for supplying this message to the switch60. The internal side further comprises a transmitting side coupled via a transmitter62aand an encryption unit62bto the switch60for receiving a message from the switch60and for transmitting this message to the node5. The switch60, encryption unit62b, transmitter62a, interface63, receiver64aand decryption unit64bare further coupled to a controller61.

Preferably, in a general situation, such as a non-emergency situation or a non-privileged situation, the decryption units cannot decrypt encrypted messages originating from (at least some) non-neighboring intermediates, sources and destinations, and the encryption units will not encrypt messages destined for (at least some) non-neighboring intermediates, sources and destinations. In a particular situation, such as an emergency situation or a privileged situation, it is not to be excluded that an end-to-end encryption/decryption is to be used, but only for a limited number of destinations. So, each node may comprise a memory for storing the public keys of the neighboring nodes and for storing a limited number of public keys of a limited number of destinations. By detecting a specific address of a specific destination and/or by detecting the message indicator being an emergency message indicator or a privileged message indicator, a node may decide to, for a particular kind of message, deactivate the hop-by-hop encryption/decryption and activate the end-to-end encryption.

The nodes4-6shown in theFIG. 4-6may have many different embodiments. Instead of a switch40,50,60, one or more servers, multiplexers, forwarders and/or bridges may be present. Even a sub-network of a telecom operator or another party may be present in the nodes4-6. Further, any block shown in eachFIG. 4-6may be divided into two or more sub-blocks and any two or more blocks shown in eachFIG. 4-6may be combined into one larger block, without departing from the scope of this invention. Each node4-6may be further coupled to further couplings not shown, in which case either further interfaces and further receivers/transmitters and further encryption/decryption units may be present or the existing interfaces and the existing receivers/transmitters and the existing encryption/decryption units may be used. In the latter case, the encryption/decryption units need to be adaptable in case different encryption/decryption processes are to be used for different hops all coupled to a same interface. Alternatively, the encryption/decryption units may be integrated into the controllers or the switches to be able to use different encryption/decryption processes without needing to introduce different units for these different processes.

Especially for the nodes4and6, the following must be noted. These nodes4and6may for example be personal computers or servers or mobile phones, in which case the switches40and60will be interfaces comprising some kind of a switching function. However, it is not to be excluded that these nodes4and6may alternatively be systems or networks, in other words the respective nodes4and6may represent a respective source and destination for one kind of message, but may represent for example intermediates for another kind of message. In that case the (content of the) nodes4and6may look similar to the (content of the) node5etc.

The above-mentioned embodiments illustrate the invention and do not limit the invention. A person skilled in the art will be able to design alternative embodiments without departing from the scope of the claims. In the claims, one or more reference signs placed between brackets are not be construed as limiting the claim. Use of “to comprise” and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article “a” or “an” preceding an element or a step does not exclude the presence of a plurality of such elements or steps.