NL1040311C2

NL1040311C2 - System and method for trusted communication.

Info

Publication number: NL1040311C2
Application number: NL1040311A
Authority: NL
Inventors: Hendrikus Anna Gerardus Wijshoff; Erwin Maria Bakker
Original assignee: Hendrikus Anna Gerardus Wijshoff; Erwin Maria Bakker
Priority date: 2013-07-24
Filing date: 2013-07-24
Publication date: 2015-01-27

Description

System and Method for Trusted Communication Description

The Field of the Invention

The invention relates to the exchange of trusted e-mails (TMT), trusted VoIP (TVT), Trusted SMS (TST), and other trusted information over (possible) insecure/un-trusted electronic communication networks.

Background of the Invention

Electronic mail (e-mail) has since its conception in the early 80's as the Simple Mail Transfer Protocol (SMTP) gained worldwide acceptance as a preferred way of mail exchange. The original SMTP protocol was ASCII-oriented and was mainly used by a small (academic oriented) user community. With the extension of SMTP by the Multipurpose Internet Mail Extensions (MIME), users worldwide were enabled to also exchange documents, multimedia applications and any kind of binary files. This lead to a tremendous worldwide acceptance of e-mail as a preferred way of exchanging documents, mail, etc. This success of e-mail also lead to more and more misuse of the SMTP/MIME protocol, i.e. SPAM, Phishing/Pharming, SCAM, malicious hacking, etc.

Although many attempts have been made and are still undertaken to prevent malicious use of the SMTP/MIME protocol, no clear final solution for this problem is foreseen. Most existing approaches rely on the Internet protocol itself for identifying malicious e-mail from well intentioned e-mails. For example white -and black listing rely on trusted IP-addresses, pharming relies on imperfections of the Name Server Resolution protocol and thereby attempts to prevent pharming also rely on the DNS protocol, SPAM filters make use of the MIME protocol etc.

Although these solutions directly target the malicious use of the SMTP/MIME protocol and the Internet protocol, they also allow workarounds within the same (software) space as where the malicious attempts originated from. So we are confronted with a never ending rat-race, where malicious attacks are being prevented by software updates of anti-virus software which in turn are being attacked by new releases of malicious attacks, etc.

General belief is that this rat-race will not end in the near future nor will it end ever. So if a final solution is being sought for, this would have to be found in a radical different way of implementing the e-mail protocol in the future. US 2005/210106 A1 and US 2007/208941 A1 both disclose methods or attempts to avoid spam. Such solutions usually require the sending party to take an active role in the spam prevention at the receiving side (for further elaboration see Section 16).

Other Trusted Message Transfers

Other message based technologies such as VoIP and SMS are also in need for a trusted communication method and system. VoIP faces similar problems as sketched above, where SPIT (Spam over IP Telephony) is currently a major issue. Nowadays many mobile devices such as mobile phones, smart phones, tablet PC's, Netbooks, portable computers are equipped with a plurality of network interfaces, which can be flexible operated depending on the circumstances and needs. Traditional circuit switched communication as well as packet switched communication and IP based communication are supported (eventually at the same time in parallel). Solutions to avoid un-solicited or unwanted VolP-calls are urgently sought for. On the other hand, methods and solutions for trusted solicited bulk messaging, or trusted information subscriptions are needed.

Brief Summary of the Invention

The Trusted Message Transfer (TMT) method uses several steps in four communication phases (see Figure 2): 1. In the method a communication (e-mail, etc.) is initiated by a (yet) un-trusted sender Bob, at Bob’s user terminal, towards a user terminal of Alice over a (possible) insecure/un-trusted first network. The first network may for example be the standard IP-based Internet. S1001 - S1004 comprise steps of the method for TMT over the first network. 2. Receiving of the communication by the user terminal of Alice. Hereby the user terminal of Alice generates a first identifier identifying on a second network the communication sent by Bob (on the first network). The received communication of Bob (Me0b) is now on hold at the user terminal of Alice (in a table RAiice) until the terminal of Alice receives a matching confirmation of a third party, called the Central Authority (CA) over the second network, after which the user Alice will be notified about the communication initiated by Bob. 3. The user terminal of Alice sends to the terminal of the CA (e.g., user terminal of the CA, server of the CA, system of the CA), the first identifier identifying the communication initiated by Bob over the second network. The user terminal of Alice may use a communication device for communicating over the second network. 4. The terminal of the CA receives the first identifier sent by the user terminal of Alice. The terminal of the CA will file this identifier in a table (Tca) together with an identifier identifying Alice. 5. The user terminal of Alice sends the first identifier identifying the communication initiated by Bob to the user terminal of Bob over the first network. 6. The user terminal of Bob receives over the first network the first identifier identifying the communication initiated by Bob and Bob's user terminal receives instructions to use the second network and instructions on how to send/relay the identifier over the second network (as described in Step 7).

These necessary actions can either be processed automatically by a proprietary communication device for the communication over the second network used by Bob’s terminal, or by manually processing by Bob using a general communication device for the second network at Bob’s user terminal. 7. The user terminal of Bob sends the first identifier to the terminal of the CA over the second network. Bob's user terminal may use a general - or a proprietary communication device for the communication over the second network. 8. The terminal of the CA receives from the user terminal of Bob over the second network the first identifier and determines if it matches the first identifier received from Alice. 9. If the match done in step 8 is positive, the terminal of the CA sends a notification for the first identifier identifying the communication initiated by Bob to the user terminal of Alice over the second network. 10. The user terminal of Alice receives the notification indicating a match for the first identifier identifying the communication initiated by Bob from the terminal of the CA over the second network. The user terminal of Alice processes the communication initiated by Bob (on hold as explained in step 2) and discloses it to the user Alice.

Brief Description of the Drawings

The description of the invention is illustrated using the figures. Hereby only typical embodiments of the invention are depicted. They should not be considered to be limiting the scope of the invention. The detailed description of the preferred embodiments will contain additional specificity details.

Figure 1 depicts an overview of the Trusted Message Transfer (TMT) Scheme. Bob sends a message to Alice over a 1st network; upon receipt Alice sends a notification to the terminal of the CA over a 2nd network and a request to Bob over the 1st network; Bob fulfills the request by sending a notification to the terminal of the CA over the 2nd network; the terminal of the CA checks and authorizes Bob’s message by sending Alice a notification over the 2nd network; upon receipt of the notification Alice gets and reads Bob’s message.

Figure 2 depicts a detailed overview of the TMT Scheme.

Figure 3 depicts the first phase of the TMT Scheme comprising the communication over 1st Network.

Figure 4 depicts the second phase of TMT comprising the communication of the e-mail program of Alice with Alice’s Communication Device for the 2nd Network.

Figure 5 depicts Phase 3a comprising the filing of the Mid from Alice at the terminal of the CA.

Figure 6 depicts Phase 3b comprising the notification of Bob and the execution of the required actions for gaining trust by Bob.

Figure 7 depict the fourth Phase comprising the steps where the terminal of the CA determined a match upon the receipt of M,d from Bob and informs Alice about the outcome. Alice uses the information from the terminal of the CA to release the trusted e-mail.

Figure 8 depicts the typical timelines of the steps in the TMT Scheme.

Figure 9 depicts the typical timelines of the steps in the Trusted VoIP System, whereby the proxy is a generic VolP-proxy.

Figure 10 depicts the timelines of the steps in the Trusted VoIP System using an adapted VolP-proxy.

Figure 11 depicts two possible designs of a dedicated TMT User Dongle.

Figure 12 depicts two possible designs of a dedicated TMT CA modem/access-point/router.

Detailed Description

The invention is defined in independent method claim 1, independent communication device claim 14, and in a computer readable medium according to independent claim 15.

Although in the description e-mail is used to illustrate the principle of the invention, including networks supporting transfer of e-mail messages and applications for handling (sending/receiving/relaying, etc.) e-mail messages, it is clear that any message based technique could be used without departing of the scope of the invention. For example, if VoIP messages would be used, this would imply VoIP user agent applications and VoIP supporting networks (e.g. comprising SIP Proxies, IP Multimedia Supporting (IMS) networks, etc).

Phase 1: Initiating communication over the first network (see Figure 3).

The first network may for example be the standard IP-based Internet. S1001 -S1004 comprise the steps of Phase 1 of the method for TMT over this network. In the method an initiating communication (for example an e-mail) is sent to Alice over the (possible) insecure/un-trusted network, by a (yet) un-trusted sender Bob. 51001 Bob sends a communication by sending Mt>0b (for example by sending an e-mail using an e-mail program Peob at the user terminal of Bob) over the first network to Alice. 51002 The communication Msob is relayed over the first network from Bob to Alice. Note that the first network can be an SMS network, a VoIP network, a standard IP-based Network, or any other network supporting message based communication. 51003 The user terminal of Alice receives the incoming communication MB0b (for example by using an e-mail program PAiice at the user terminal of Alice). (Note that, if Alice is offline, her e-mail service provider will store MBOb as any other e-mail. Once Alice is online Alice's e-mail program PAiice will start processing stored e-mails one by one.) 51004 The user terminal of Alice processes the communication MBOb by putting it in a buffer table RAiice at the user terminal of Alice, i.e. Alice will not yet be notified at this stage of the incoming communication initiated by Bob.

Phase 2: Processing of the initiating communication MBOb at the user terminal of Alice (see Figure 4). 51005 - S1006 comprise the steps of Phase 2 of the method for TMT at the user terminal of Alice. The received communication MBOb is stored in R^ce at the user terminal of Alice until a notification is received from the third party CA over the second network. The user terminal of Alice processes the received communication MBob in the following steps. Note that the user terminal of Alice may comprise of a general - or proprietary communication device (CDA|jce) for the second network. An example could be a pluggable GSM module for communicating over the GSM network. 51005 The user terminal of Alice processes the initiating communication MBOb by reading it from the buffer table RA|ice and determining a unique identifier Mid uniquely identifying the communication MBob on the second network. 51006 The user terminal of Alice uses the communication device for the second network (CDA|ice) for further sending Mid over the second network to the terminal of the CA.

Phase 3: Alice’s user terminal requests to file the Mid at the CA, and notifies Bob for the further required actions to enable trust.

Alice's user terminal will notify Bob by a communication (for example e-mail) for the further required actions for Bob’s initiating communication MBob to become trusted by Alice.

Phase 3a: Alice’s user terminal files the Mid at the CA (see Figure 5). S1007 - S1009 comprise the steps of Phase 3a of the method for TMT at the user terminal of Alice, over the second network and by the terminal of the CA. 51007 The user terminal of Alice uses the communication device for the second network CDAHce to send the unique Mjd derived from the initiating communication MBOb together with Alice’s identification information (for example SIM-identifier, IP-address, among others) to the terminal of the CA over the second network. This can be implicitly or explicitly communicated by CDAiice· 51008 The terminal of the CA receives Mi(j together with Alice’s identification information over the second network and checks if the Mid has the required form/format, 51009 If Mid indeed has the required form/format, the terminal of the CA stores it in the table TCa of pending message id’s, together with Alice’s identification information (IdAiice)·

Phase 3b: Bob’s required actions for gaining trust (see Figure 6). S2007 - S2014 comprise the steps of Phase 3b of the method for TMT taking place at the user terminal of Alice, over the first network, at the user terminal of Bob, over the second network, and finally by the terminal of the CA. S2007 The user terminal of Alice by means of the communication device for the second network CDAnce triggers a further communication by the user terminal of Alice to Bob over the first network comprising the Mid from the communication Mbob· 52008 The user terminal of Alice sends a communication, comprising Mid derived from the original message MBot>, to Bob (for example by e-mail) over the first network. 52009 The communication comprising Mid is relayed over the first network from Alice to Bob. 52010 The communication comprising Mjd is received at the user terminal of Bob (for example by an e-mail client PBOb at the user terminal of Bob). 52011 The user terminal of Bob uses a communication device for the second network CDBOb for processing the communication comprising Mid that was received from the user terminal of Alice. (Note that CDBOb can be a general communication device, possibly external to the user terminal, such as a mobile phone, or a proprietary communication device for the second network, etc.). 52012 The user terminal of Bob uses CDBOb to relay Mjd (received from Alice's user terminal) to the terminal of the CA over the second network. As such Bob’s user terminal does not require any resources related to messages sent before nor any information needed to calculate identifiers. Bob’s terminal does not take an active role in the authentication process other than relaying the Mid, nor does Bob’s user terminal require any computing resources for complicated authentication scheme’s. 52013 The terminal of the CA receives the communication comprising M,d over the second network from the user terminal of Bob and checks if the communication comprising Mid has the required form/format. 52014 If the communication comprising Mid has the required form/format, the terminal of the CA will check if the Mjd can be matched with an existing entry in the table Tca that is maintained at the terminal of the CA.

Phase 4: The CA determined a match upon the receipt of Mid from Bob and informs Alice about the outcome (see Figure 7).

Note: at this stage S1009 and S2013 have been passed. S1010 - S1015 comprise the steps of Phase 4 of the method for TMT taking place at the terminal of the CA, over the second network and at the user terminal of Alice. 51010 If the terminal of the CA determines that the communication comprising Mld received from Bob matches with an existing entry (Mid, Alice) in the table TCa. the terminal of the CA will start the action to inform Alice about this. 51011 The terminal of the CA sends a communication comprising the Mid to the user terminal of Alice over the second network. 51012 The user terminal of Alice (using the communication device CDAiice for the second network) receives the communication comprising the Mid over the second network from the terminal of the CA. 51013 The user terminal of Alice uses the communication device CDAijCe of Alice to notify Alice that the communication with Mid is trustworthy (for example by notifying the e-mail program PAiice)· 51014 The user terminal searches the message M in its message table Rah»» that uniquely relates to the M,d and flags it as trustworthy. 51015 All messages M that have become trustworthy are released by the user terminal of Alice from the message table Rah»» and Alice is notified of the incoming communication (for example by the e-mail program PAiice)·

Alternative Implementations

In each of the phases of the TMT method and each communication step inside each phase can also be handled by proxy.

Case 1: A specific implementation foresees in a communication by proxy server, where the incoming (S1002) and outgoing (S2009) communication by Alice over the first network is handled by proxy, meaning that the communication is not delivered to Alice but to a proxy server. An example of this could be an e-mail server like gmail, etc. In this case the proxy server will engage in all further steps as S1003 and further on behalf of Alice, meaning that all actions and communications by the user terminal of Alice are directly performed by the proxy server. Only after step S1015 has been finalized by the proxy server Alice is being notified of the incoming communication, for example the original e-mail sent by Bob.

Case 2: A specific implementation foresees in a communication by proxy server, where the incoming and outgoing communication by Alice over the first network (as described in the steps S1003 and up) is handled by proxy. Hereby the proxy server shall relay all communication that involves the first network directly to the user terminal of Alice, with no additional actions of the proxy server itself.

Case 3: A specific implementation foresees in a communication by proxy server, where the incoming (S2009) and outgoing (S1002) communication by Bob over the first network is handled by proxy, meaning that the communication comprising Mid is not delivered to Bob but to a proxy server. An example of this could be an e-mail server like gmail, etc. In this case the proxy server will engage in all further steps as S1001 and further on behalf of Bob, meaning that all actions and communications by the user terminal of Alice are directly performed by the proxy server.

Case 4: A specific implementation foresees in a communication by proxy server, where the incoming and outgoing communication by Bob over the first network (as described in the steps S1001 and up) is handled by proxy. Hereby the proxy server shall relay all communication that involves the first network directly to the user terminal of Bob, with no additional actions of the proxy server itself.

Case 5: A specific implementation foresees in a communication over the second network by proxy server. Hereby all the communication between the user terminals of Alice and Bob and the terminal of the CA is relayed by the proxy server, with no additional actions of the proxy server itself.

The above cases can coexist in any combination in a specific implementation.

Description of Preferred Embodiments:

The TMT method can be implemented in several ways: 1. Choice of communication devices at the user terminals.

The user terminals of Bob and Alice can comprise any devices or software components which allow communication with the first network or second network. Current examples are USB sticks with embedded mobile phone cards, mobile/smart phones, GPRS/G3-modem, or (embedded) PC cards. The devices at the user terminal of Bob do not have to be the same as the devices at the user terminal of Alice. Also the communication device CDB0b at the user terminal of Bob can be either adapted to the TMT method or can be a generic device, possibly external to the user terminal of Bob, which communicates with the second network (for example a mobile telephone). A communication device which is adapted to TMT allows automatic generation of requests to file message IDs and allows also automatic generation of trust requests.

The particular choice of communication devices allows several scenarios. • In Scenario 1 Alice has an adapted/proprietary TMT device, further referred to as "TMT device”, whereas Bob does not have a TMT device. In this case Bob will have to manually process a trust request for the message ID using a generic communication device (e.g. a mobile telephone). • In Scenario 2 the user terminals of Alice and Bob have both a TMT device in which case the authorization and TMT will be executed automatically. In step S2008 the user terminal of Alice sends a communication comprising Mid derived from the original initiating communication MBOb· This communication comprises a signature for Mid, which can be automatically verified by the TMT device at the user terminal of Bob. This will prevent the TMT device at the user terminal of Bob of handling the TMT message from Alice as a regular untrusted message. • In Scenario 3 in which the user terminal of Alice does not have a TMT device, the communication (e-mail) delivery is handled in the same manner as regular communication (e-mail), and no specific actions are required by Bob.

The use of adapted/proprietary TMT specific communication devices, will improve the level of trustworthiness of TMT. So in case that both the user terminal of Bob as well as the user terminal of Alice has a TMT device the level of trustworthiness is the highest.

Also the TMT devices can have an additional functionality build in, such that for example explicit permission is asked to Bob or Alice to go forward with sending each request to file and/or trust request. As such TMT provides different levels of trustworthiness.

Note that, whenever storing is done, for example at the user terminal (S1004) of Alice putting the initiating communication Me0b in a buffer table R/viice , or (S1009) when the terminal of the CA stores Mid and Alice’s identification information in the table Tca. this can be done locally in memory/storage, in a local or remote (possibly shared/redundant/secure) database, etc. 2. TMT implemented on top of other methods that use authentication and secure messaging.

The communication over the second network that takes place in Phase 3a for filing the message at the central authority can be implemented using an authentication and encryption protocol (for example such as implemented in SSL, or using a Public Key Cryptosystem in combination with a Digital Signature System, etc.) that ensures the authentication of both the central authority and the communication device itself. After this a secret key can be exchanged that is used for further encrypted communication using a secret key cryptosystem (for example IDEA, DES3, etc.) between the central authority and the communication device CDAijCe of Alice.

The implementation of Phase 3b can be handled in a similar way, where the trust request, that is the message comprising Mici, originally triggered by communication device CDAiice of Alice, is encrypted using a public key of the CA (or being cryptographically authenticated and encrypted using DSA, RSA, etc.). Subsequently the communication device CDBob of Bob processes the communication over the second network to the terminal of the CA.

In Scenario 1 as described in Item 1 (see above), Bob has to handle the communication to the terminal of the CA manually. Thereby relaying over the second network the received encrypted and/or signed message comprising Mid sent by the user terminal of Alice, to the terminal of the CA.

In Scenario 2 as described in Item 1 (see above) in which Alice as well as Bob have an adapted/proprietary TMT communication device CDA|ice and CDb0ö. respectively, the message comprising Mjd, triggered by communication device CDAHce of Alice, to Bob can be authenticated and encrypted as well. And the communication device CDsob of Bob handles the possibly encrypted and authenticated communication to the terminal of the CA automatically (using an authentication and encryption protocol as described above).

The encryption and authentication as described above would also allow an embedding of the first network on top of the second network, or vice versa. In this case TMT would be implemented on top or below the communication protocol of the first network. 3. TMT in conjunction with other filtering techniques. TMT can be used without any limitations on top of any SPAM filtering, virus scanner or other message filters. TMT can be implemented such that it only acts on messages that are passed the SPAM filter, virus scanner or other message filters at the user terminals. In this case the trustworthiness of TMT is further improved by potentially filtering out of malicious communication attempts (e.g. e-mails, VoIP call attempts). Of course this requires that at the user terminal of Bob the SPAM filter, virus scanner or other message filters that are active should be set such that they pass the message comprising Mid. 4. The implementation of the generation of the message identifier (Mid).

The message identifier generated at the user terminal of Alice can be independent of the content of the message or by the application of a function F, cryptographic or not, on the content of the message. In the latter case another level of trustworthiness is provided which can be used for instance in the handling of bulk mail.

The function F can be implemented in various ways, ranging from a simple number generator, cryptographic or not, to a cryptographic hash function based on the message content. In the first case the necessary actions by the user terminal of Bob can be made straightforward in case the user terminal of Bob does not comprise a TMT adapted communication device. Using a more sophisticated implementation of F possibly requires a longer identifier, making a manual processing at the user terminal of Bob more cumbersome.

Alternatively, the skilled person could present the function F as being a function of a combination of message content, message header information and embedded key information, for example MAC address of the communication device, followed by the application (similar to Item 2, see above) of a cryptographic encryption and signature scheme using a public key from the CA and/or secret key shared between the CA and Alice, resulting in a higher level of trustworthiness.

The functionality as described above can be added to the Mid communication over the first network to Bob or over the second network to the CA. 5. Extended authentication over the second network.

In addition to the communication over the second network of the first user to the CA and/or the second user to the CA (step S1007 and step S2012), next to the Mjd an (possibly encoded) identification, e.g. MAC address, of the communication device of the first user CDsob and/or communication device of the second user CDAiice, can be included into the communication. This addition enables a further identification of the first and/or second user. Also the CA, when communicating to the second user (in step S1011), can include next to the Mid a (possibly encoded) identification into the communication to the second user. 6. TMT and bulk mail.

Bulk mail can be seen as initiation of multiple instances of (the same) communication. Any user (e.g. Bob, e.g. Alice) can become a registered TMT user known by the Central Authority, for example by a registration through a webinterface, who is allowed to send bulk-mail. In this case there are several scenarios for sending bulk mail.

Scenario 1: the registered user files a request for bulk e-mail. The terminal of the CA responds with a list of message keys/tickets. The registered user thereupon sends out the bulk e-mail by tagging each message with a different key/ticket. The TMT device uses a function F, which extracts the message key/ticket and encodes it in the request-to-file message to the terminal of the CA. The terminal of the CA can then perform a direct match with the message keys/ticket list. If the terminal of the CA receives multiple requests for the same message key/tickets it will accept only the first one and will ignore all the subsequent ones. Such a (first) direct match will be directly acknowledged to the receiver.

Scenario 2: the registered user files a request for bulk e-mail. The terminal of the CA responds with one message key/tickets and a count of maximal use. The registered user thereupon sends out the bulk e-mail by tagging each message with this key/ticket. The TMT device uses a function F, which extracts the message key/ticket and encodes it in the request-to-file message to the terminal of the CA. The terminal of the CA can then perform a direct match with the message key/ticket, thereby decrementing the counter by 1. If the counter is 0, the terminal of the CA will ignore all subsequent requests for matching.

Scenario 3: in addition to scenarios 1 and 2 the registered user could also deposit the content of the bulk mail message with the CA in which case the generated Mjd by Alice will also take the content of the message into account. In this case an additional measure is put forward to ensure correct delivery of bulk mails.

Scenario 4: in addition to both scenarios 1, 2 and 3 users can also register at the CA, which bulk mail type they would be interested in. In this case bulk mail of registered users is categorized on their content and the CA can cancel any authorization, which does not correspond to the registered preferences of for example Alice.

Scenario 5: in addition to the scenarios 1,2,3 and 4, the CA can also on request of the registered user authorize a trusted fourth, external, party on the first network to send the bulk emails on behalf of the registered user. In this case the key/ticket exchange and/or mail content is being communicated between the CA and the fourth party, and the email sent by the fourth party will also include a specific key/ticket of the fourth party. In this case, the function F is extended to also include the key/ticket of the fourth party. If the CA receives a match request including the key/ticket from a trusted fourth party, the match can be directly performed.

Scenario 6: the CA could designate specific trusted fourth parties on the first network either by exclusivity/category/urgency etc. In this case the registered user can ask for a specific fourth party to handle the bulk transfer.

Scenario 7: in addition to scenario 6, users can also register at the CA from which trusted fourth party they would be interested in receiving email. In this case the CA can match (directly) the message with the user preference. 7. Explicit Acknowledgement of Matching to the First User.

After step S1010 either on request of the first user or by default an explicit acknowledgement of the communication is sent to the first user, if the match is successful. In this case the first user obtains next to the confirmation of the communication by the second user in step S2009 also an acknowledgement by the terminal of the CA of the communication delivery. 8. Group usage of TMT. TMT can also be used to facilitate any kind of trusted communication between members of a group of identified individuals. In this case the TMT adapted communication devices of all group members are registered at the CA. Further the TMT method operates in a regular fashion with the exception that the CA will only match Mid's of Bob and Alice if both communication device ID's (the id of CDAiice and the id of CDeob) are registered prior to communication and belong to the same group.

Other kind of group usage of TMT comprises trusted communication between a designated group of identified and trusted members and any other user. In this case there are two scenarios possible:

Scenario 1; the trusted members have full authority, which means that the CA will automatically match any request from Alice which contains the CD identification of the trusted members.

Scenario 2: the other users are provided with designated communication devices with registered ID, so that both messages sent from the trusted member to the other user as well as messages sent from the other user to the trusted member are only matched if the CD identifications match.

This kind of setup would be very suitable for trusted communication between for example governmental organizations and citizens, banks and clients, etc.

In the above also the CA can be a group of identified and trusted members. 9. The implementation of the Central Authority.

When necessary the CA can be implemented in a distributed fashion to ensure locality of traffic on the second network. By doing so costs could potentially be minimized. Also redundancy and fault tolerance can be used to ensure high availability of the CA.

In addition the different sites of the CA can forward/redirect matching requests to other sites depending on the locality of the first party and the second party.

Furthermore, TMT could be implemented while the first party or the second party, also take the role of the CA. The further implementation does not change, but the necessary or needed steps by the terminal of the CA take place at the user terminal of the first or second party.

The second network used for the implementation of TMT can be extended or replaced by one or more other networks (for example the combination of internet, GPRS, SWIFT, GSM, G3, and G4), thus strengthening the trust of the method. 10. VoIP SPIT (Spam over IP Telephony).

VoIP faces a problem similar to e-mail spam and scam for which TMT can be used to implement prevention of un-solicited or unwanted calls. Nowadays many mobile devices such as mobile phones, smart phones, tablet PC's, Netbooks, portable computers are equipped with a plurality of network interfaces, which can be flexible operated depending on the circumstances and needs. Traditional circuit switched communication as well as packet switched communication and IP based communication are supported (eventually at the same time in parallel). In order to avoid un-solicited or unwanted VoIP calls the VoIP client (e.g. SIP user agent) receiving an incoming call could apply the same mechanism as the TMT method. Of course in VoIP the signaling is more time sensitive than with e-mail and the possible additional signaling with the CA has to be done with limited delay in order to prevent the call from timing out. It is however, feasible to perform the overhead signaling over the secure and fast 3G/4G network within the timeframe of 1 or 2 notifications (e.g. "180RINGING" or "100TRYING") back to the calling entity without or before disturbance of the called party.

More precisely, the VoIP SPIT embodiment is based on the TMT method in which the VoIP proxy server X takes the combined role of the proxy server as described in case 1 and 2 in the section of alternative implementations. Figure 8 depicts the send- and receive-schemata of the standard TMT method.

In case of VoIP the communication over the first network of message Μβ0& to the user terminal of Alice is broken down to: • INVITE message of Bob’s VoIP Adaptor (Bob VA) to the proxy server. • Upon receiving of the INVITE from Bob VA, the proxy server will respond with sending the message 100 TRYING to Bob VA. • At the same time or after receiving the INVITE message from Bob VA, the proxy server sends the INVITE message to Alice VA.

The communication over the second network of Mid of the user terminal of Alice to the terminal of the CA is replaced by sending a NOTIFY(ID) communication of Alice VA to the terminal of the CA.

The communication over the first network of Mjd of the user terminal of Alice to Bob is replaced by sending a NOTIFY(ID) communication of Alice VA to the proxy server. The proxy server relays the NOTIFY(ID) to Bob VA.

The communication over the second network of Mid by the communication device of Bob to the terminal of the CA is replaced by sending first a NOTIFY(ID) communication of Bob VA to the proxy server after which the proxy server relays this NOTIFY(ID) communication over the second network directly to the terminal of the CA.

The original communication steps of sending an OK, M,d to the communication device of Alice and the subsequent notification of the user terminal to Alice directly is being replaced by sending a NOTIFY(OK) message by the terminal of the CA to Alice VA followed by a 180RINGING message from Alice VA to the proxy server, which thereupon is relayed from by the proxy server to Bob VA (See Figure 9).

Alternatively to using a SIP NOTIFY message, a signaling message SIP MESSAGE can be used.

An alternative implementation of this embodiment makes use of the SIP proxy protocol to shortcut some of the steps as described above.

In this case the communication over the first network of message Meob to the user terminal of Alice is replaced by sending an INVITE(Alice) from Bob VA to the proxy server.

The communication over the second network of Mid of the user terminal of Alice to the terminal of the CA is replaced by sending a SIP NOTIFY(ID) communication of the proxy server to the terminal of the CA.

The communication over the first network of Mjd of the user terminal of Alice to Bob is replaced by sending a 100TRYING(ID) communication from the proxy server to Bob VA.

The communication over the second network of M,d by the communication device of Bob to the terminal of the CA is replaced by sending a SIP NOTIFY(ID) communication of Bob VA to the terminal of the CA.

The original communication steps of sending an OK, Mid of the terminal of the CA to the communication device of Alice and the subsequent notification of the user terminal to Alice directly is being replaced by sending a SIP NOTIFY(OK, ID) message by the terminal of the CA to the proxy server followed by an INVITE(Alice) message from the proxy server to Alice VA, which is then acknowledge by an 18QRINGING message from Alice VA to the proxy server, which thereupon is relayed by the proxy server to Bob VA (See Figure 10).

In order to process the message comprising the VoIP message identifier Mid, in Scenario 1 under Item 1, Bob’s communication device CDBOb can be used manually to communicate the Mid to the terminal of the CA. In order to allow a more swift (manual) processing special TMT applications can be made publicly available (for the respective platforms on which the VoIP client runs, like

Windows, Unix, Apple OS, Android, etc.) that capture the Mid and execute the necessary actions after a single user interaction at the user terminal (e.g. clicking a notification dialog button).

In Scenario 2 under Item 1, Bob’s communication device CDBOb will be able to automatically process the message comprising the VoIP message identifier Mjd, enabling a very timely and transparent processing of the message comprising Mj<j. Clearly, this will be the preferred situation for VoIP.

Alternatively, the skilled person could present an implementation of the TMT scheme, wherein the communication on the first and/or the second network comprises at least one of the communication types: data; voice; media; video; images; sound; text; chat; SMS; GPS; text messaging; twitter; icons; VoIP; web based data.

While SIP and SIP messages have been used to illustrate the use of TMT in the context of VoIP, it is obvious for the skilled person that other voice communication protocols can be adapted in a similar manner within the scope of this example. 11. Viral Character of TMT.

All the steps performed by the user terminal of Bob could be implemented such that each step would require an explicit action/intervention by Bob at the user terminal of Bob. This has several implications.

For one it enables the usage of TMT without any previous knowledge or encounters on the TMT system. So the first user (Bob) can initiate communication over the first network as usual, without even knowing about TMT, and when he encounters a user (Alice) who has adopted TMT, he will receive from Alice a message containing an identifier and instructions how to take explicit action on the second network to ensure that Alice will accept this communication.

Next to this message also Bob can be informed by the automated TMT system from Alice how to prevent having to take explicit action also adopting TMT. Bob has the choice to either adopt TMT enabling him to integrate seeming less into the TMT way of communication or do business at usual at a certain cost.

On the other hand, as a second implication, this could be used as an extra check of an intervening user (Bob) at the user terminal of Bob, prohibiting or discouraging automatic communication (possibly by spammers or other malicious users) at the premises of Bob. As a side effect Bob is made aware of the fact that his user terminal has been compromised, and at the same time sees evidence on how other users have protected themselves by adopting TMT. 12. Dedicated Communication Device of First and Second User

The steps at the user terminal of the first and second user can be implemented in a special dedicated device that implements all or part of the steps at the user terminal of the first or second user as described in the detailed description section. More specifically, this device could be a hardware tamper-resistant dongle that implements with special firmware the steps concerning the communication between the user terminal of Alice and the terminal of the CA, and between the user terminal of Bob and the terminal of the CA over the second network (See Figure 11). 13. Dedicated Communication Device for the Central Authority

The steps at the terminal of the CA can be implemented in a special dedicated device that implements all or part of the steps at the terminal of the CA as described in the detailed description section. More specifically, this device could be a hardware tamper-resistant modem, access-point or intelligent-router with special firmware which filters TMT messages from other traffic and either directly or by redirection performs the matching of message id’s (See Figure 12). 14. The Integrated Communication Device

The communication devices as described under Embodiments 12 and 13 can also be integrated with all or part of the functionality of the corresponding user terminals. In this case the integrated communication device of the first and second user can for example also send messages directly over the first network. In another example the integrated communication device could also comprise the functionality to generate Mjd- 15. TMT Logging and Monitoring A fifth party could be given the possibility in the TMT scheme, as described in the previous sections, to identify/trace/log/monitor any part of the communication of the TMT method. This could be used to identify/trace/log/monitor misuse in any of the comprised method steps.

The fifth party could be a separate party, possibly a trusted party, but could also be implemented by any of the other parties in the previously described TMT method and embodiments.

The communication can be identified by the fact that every communication by any two parties, which engage and employ the TMT method will eventually result into a matching request at the CA. By the CA logging these requests, the CA will have full access to every combination of first party and second party communication attempts, allowing the CA to trace back any communication in the first network. In the case of misuse, for instance in which a third party attempts to send an unauthorized SPAM to many users, the CA will receive many matching requests from a multitude of (identified) users, in which case the CA, can sent out a SPAM alert to all the users affected by the SPAM attack and can start a procedure to identify the malicious SPAM attempt by requesting from the users who have received emails by this malicious user, to send details of their emails to the CA. The CA can then either directly or by reporting to another authority, e.g. law enforcement entity, start an investigation of the true identity of this malicious user.

Depending on the wide spread use of the TMT method the CA would obtain full knowledge of all the communication activities on the first network. The CA could even send controlling messages over the first network, either directly or by proxy, to monitor the acceptance of the CD by a designated group of users. The controlling messages can be generic messages on the first network or could include specific encrypted information. As a direct consequence every user which has a CD will generate over the first network back to the CA a message including Mid and/or other information generated in a similar way as described in embodiment 4, and will generate over the second network an authorization request to the CA also including a Mid. The CA can now based on the communication over the first network or over the second network or in combination identify which users are using the CD.

Because every user, which is not using the CD to handle the communication over the first network, will not generate a matching request to the CA, these users can be identified based on their identification on the first network. 16. TMT Benefits and Comparisons to Prior Art

As a result the benefits of the TMT scheme can be identified as follows.

In prior art, the sending party (first user) can enforce secure communication to be established. This allows various types of malicious attacks, that in TMT are not possible anymore, because in TMT it is the receiving party (second user), who decides for each communication instance whether secure communication is initiated by producing an identifier for TMT, or whether to receive the communication by the first user using the (standard) communication protocol over the first network, or whether to ignore the communication over the first network completely. So any malicious attack which tries to breach the TMT protocol can be nullified by non-malicious receiving parties revocating the TMT protocol. As a consequence any communication attempt to compromise the TMT protocol, after TMT is revocated by the receiving parties will fail.

In prior art, one of the shortcomings is that a first user wanting to engage in a secure communication with the second user has to have prior knowledge of the protocol that implements the secure communication. This poses a major problem for acceptance of the methods proposed in US 2005/210106 A1 and US 2007/208941 A1, as both the first and second user have to adopt the method as described in this prior art. In TMT this problem is explicitly solved, as a first user is able to send a communication to the second user without any prior knowledge on the further protocol for TMT. Upon receipt of this communication an identifier is produced by the receiving party (second user). This is an essential contribution to the acceptance of TMT and will enable viral spread of the method (see also Section 11).

In prior art, it is often the case that the initial control of an identifier, identifying the secure communication is in the hands of the first user. This creates the possibility of tampering with the identifier by a malicious first user. In TMT this problem is countered by having the control of the identifier in the hands of the second user only, i.e., the party that benefits from the TMT protocol.

In prior art solutions, the sending and authentication of the identifier identifying the communication is sent over a first network only. Any malignant users on the first network may have seen this identifier which allows various attacks on these types of protocols. In TMT this is solved as the identifier produced by the second user is sent over a separated trusted second network. Hence the identifier has been sent over a separate trusted second network before any malignant users on the first network may have seen this identifier. This excludes many of the possible attacks to which prior art is vulnerable.

Furthermore, as the authentication of the identifier is exercised on the second trusted network by a CA that is reachable on the second trusted network only, the identifier has no meaning for non-communicating parties on the first network, thereby limiting the possibilities to attack the TMT protocol, especially compared to the prior art.

In addition, a malicious attack over the first network can only be successful if both the first network and the second network are being compromised in a synchronous manner, thereby limiting the possibility to perform a malicious attack even further, especially compared to the prior art.

Claims

A method for ensuring secure communication between a first user and a second user comprising the following steps: - initiating a communication (S1001) from the first user to the second user over a first network; - receiving the communication (S1003) initiated by the first user by a user terminal of the second user; - generating a first identifier (S2007) by the user terminal of the second user, who identifies the communication initiated by the first user; - sending the first user's user identifier (S1007) from the second user over a second network to a third party; - sending the first identifier (S2008) by the user terminal of the second user over the first network to the user terminal of the first user; - sending the received first identifier (S2011) by the user terminal of the first user over the second network to the third party; - receiving the first identifier (S2013) sent by the user terminal of the first user, by the third party and matching (S2014) by the third party of the first identifier received from the user terminal of the first user user, with the identifier, received from the user terminal of the second user; - sending the confirmation of the match (S1011) by the third party to the user terminal of the second user over the second network; - receiving the confirmation of the match (S1012) by the user terminal of the second user and notifying the second user about the communication initiated by the first user.

The method as claimed in claim 1, wherein each of the roles of the first user, second user, or third party can be performed by each of the parties.

The method as claimed in one or more of claims 1-2, wherein the communication is at least one of: a single communication agency; or a plurality of communication authorities, wherein the plurality of communication authorities may consist of: a maximum amount of communication agreed between a first party and the third party; includes a maximum amount of communication agreed between a second party and the third party.

The method as claimed in one or more of claims 1-3, wherein the communication comprises: the first user being organized as a group and / or the second user being organized as a group and / or the third party being organized as a group.

The method as claimed in one or more of claims 1-4, wherein all or part of the communication over the first and / or second network is handled by a proxy server.

The method as claimed in one or more of claims 1-5, wherein the third party, in cooperation with another party or not, can identify / trace / log / monitor the communication between the first and second user and / or identify / trace abuse in one or more of the comprehensive method steps.

The method as claimed in one or more of claims 1-6, wherein the third party, whether or not in cooperation with a further party, can exclude certain users or groups of users from effectively using communication over the first network .

The method as claimed in one or more of claims 1-7, wherein the communication is limited by: the number of communication authorities; the total size of the communication authorities; the minimum or maximum size of the communication authorities; the timeliness of the communication authorities.

The method as claimed in one or more of claims 1-8, wherein the communication on the first and / or the second network at least one of the communication types: data; speech; media; video; statue; sound; text; chat; TEXT MESSAGE; GPS; " text messaging "; twitter; icons; VoIP; web-based data.

The method as claimed in one or more of claims 1-9, wherein the first and second user both belong to a designated group of communicators, thereby providing for secure communication between users from within the designated group.

The method as claimed in one or more of claims 1-10, wherein one or more of the method steps performed by a user terminal at least one of: software component; physical device; mobile phone; usb device; notebook; computer; proprietary device.

The method as claimed in one or more of claims 1 to 11, wherein the first communication network and the second communication network are one and the same communication network.

The method as claimed in one or more of claims 1-12, wherein all method steps for user terminal of the first user require intervention by the first user.

A communication device, comprising means adapted to perform all or part of the method steps at the user terminal of the first user, second user or third party as set forth in one or more of claims 1-13.

A computer readable medium comprising instructions that when executed perform the method steps for a communication device as defined in claim 14.