GB2411086A - Secure communication between terminals over a local channel using encryption keys exchanged over a different network - Google Patents

Secure communication between terminals over a local channel using encryption keys exchanged over a different network Download PDF

Info

Publication number
GB2411086A
GB2411086A GB0403171A GB0403171A GB2411086A GB 2411086 A GB2411086 A GB 2411086A GB 0403171 A GB0403171 A GB 0403171A GB 0403171 A GB0403171 A GB 0403171A GB 2411086 A GB2411086 A GB 2411086A
Authority
GB
United Kingdom
Prior art keywords
terminal
key
network
terminals
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
GB0403171A
Other versions
GB2411086B (en
GB0403171D0 (en
Inventor
Bulent Ozgur Gurleyen
Peter Thomas Howard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone Group PLC
Original Assignee
Vodafone Group PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vodafone Group PLC filed Critical Vodafone Group PLC
Priority to GB0403171A priority Critical patent/GB2411086B/en
Publication of GB0403171D0 publication Critical patent/GB0403171D0/en
Publication of GB2411086A publication Critical patent/GB2411086A/en
Application granted granted Critical
Publication of GB2411086B publication Critical patent/GB2411086B/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

User A wishes to use his mobile terminal A 100 to establish a secure local communication link 102 with user B's mobile terminal B 104. The link 102 may be a Bluetooth or WLAN connection, for example. In the embodiment described the secure communication channel 102 is formed by encrypting communications from terminal A 100 to terminal B 104 using terminal B's public key, and by encrypting communications from terminal B 104 to terminal A 100 using terminal A's public key. As well as having the facility to establish the local communication therebetween, terminals A 100 and B 104 are registered with respective mobile or cellular telecommunications networks A 106 and B 108. The networks A 106 and B 108 are provided with respective key exchange servers A 110 and B 112. Key exchange server A 110 and key exchange server B 112 are for facilitating the secure exchange of public keys between mobile terminals registered with the respective networks. Therefore the secure local communication link 102 is established using encryption keys exchanged over a different (e.g. GSM or UMTS) network, 106, 108.

Description

241 1 086
SECURE COMMUNICATIONS BETWEEN TERMINALS
The present invention relates to a method of creating a secure local communication channel between respective terminals, each of which is registered with a communication network a method of transmitting a key associated with a first device to a second device to allow formation of an encrypted communication channel between the devices, and a communication system including a mobile telecommunications network and a mobile terminal In the area of Public Key Cryptography a problem exists in the exchange of authentic public keys between two users who wish to create a secure channel between them. Without the use of public key certificates or an authenticated channel, such as manual user interaction (i.e. each user advising the other user of their public key and the other user manually entering the public key into their terminal) or a direct cable connection between the user terminals, an attacker can launch a man- in-the-middle (MTM) attack to intercept and change the public keys transferred to replace them with keys known to the attacker in order to eavesdrop on the communication to be established between two parties.
Such prior art arrangements for avoiding a man-in-the-middle attack will now be described in more detail, by way of background information.
Public Key Certificates: A public key can be digitally signed by a Certification Authority (CA) that would guarantee the authenticity of the public key to other parties provided that the party that will do the verification has the authentic I- public key of the CA (i.e. the CA-root key). In other words the problem of authenticity is reduced to a single public key (the CA-root key), rather than any public key generated by the user. However, this approach requires users to get their public keys that they may have created (as a private-public pair) themselves without the need for a third party certification. Certification is usually a costly process and requires in the best case some additional on-line certification capabilities (protocols) in the mobile terminal. Additionally two major problems exists with this approach: (a] 15 Each public key that is signed by a different CA requires the root-key of that particular CA to be stored in the user's device (e.g. a mobile phone), and there could be many CAs that a device would not be able to store. The most likely reasons for this would be limited memory or lack of authentic channels to acquire the root-public keys. There is no single global CA that everyone can use to verify public keys. A solution of cross certification is used to address this problem, but this also suffers from the same problem of acquiring and storing multiple root keys of CAs.
Certificates also require revocation which is done when the private key associated with the public key is compromised and needs to be changed.
CA's keep a revocation list for expired/revoked public keys that needs to be checked before accepting a public key certificate. However, it is often difficult and/or expensive to query CA revocation lists every time a certificate is verified. For this reason, typically the pre-set expiry date on the original certificate is used for revocation. In addition, when a user decides to update/change his/her private/public key pair, he/she needs to consult the CA first to revoke the original public key certificate and then get the new public key certified.
For the reasons explained above using Public Key Certificates suffers from complexity and availability issues.
Manual Interaction: It is possible to create an authentic channel between two entities using manual interaction if they are in close proximity. A user can read out the public key data (or a hash of the public key) to the other user who can then enter this into hislher device manually. There are several protocols described in the prior art literature to achieve this. However, it is not always possible or convenient for the users to type in potentially long numbers representing the key or hash into their terminals. The approach is prone to human error and requires very close proximity ofthe two users.
Cable connection: A cable can still be considered as authentic channel as two ends of the cable can be visually authenticated by the users provided that the cable is short enough for the users to see the whole cable without the any 1 - breaks in the medium. The main problem with the cables is the fact that it is quite difficult to provide an interface that would enable a cable to be able to connect any two possible devices. This method also requires proximity similar to manual interaction.
According to a first aspect of the present invention, there is provided a method of creating a secure local communication channel between respective terminals, each of which is registered with a communication network the method including exchanging encryption key data between the terminals via the or each communication network, and establishing a secure local communication channel between the terminals by encrypting data transmitted between the terminals during the local communication session using the encryption key data.
According to a second aspect of the present invention, there is provided a method of transmitting a key associated with a first device to a second device to allow formation of an encrypted communication channel between the devices, wherein the devices are registered with a communication network the method including transmitting the key to the second device via the or each communication network such that the key received by the second terminal can be used to send encrypted data to the first terminal over a communication channel not including the or each network.
According to a third aspect of the present invention, there is provided a communication system including a mobile telecommunications network a mobile terminal and a key exchange server for transmitting a key to the mobile terminal via said mobile telecommunications network the mobile terminal being adapted to receive the key from the mobile telecommunications network and to establish an encrypted communication link with another terminal using said key. -
For a better understanding of the present invention, an embodiment will now be described by way of example, with reference to the accompanying drawings, in which: Figure 1 shows schematically two mobile terminals associated with respective mobile telecommunications networks and the establishment of a secure local communication link between the mobile terminals in accordance with the invention; and Figures 2A to 2E show a flow chart describing the steps performed to establish a secure local communication link in accordance with the invention.
In the embodiment to be described a secure communication link or session is established between two mobile telephone terminals which are registered with an appropriate network - such as a GSM, UMTS (3G) network or the like. The mobile terminals are capable of communicating with each other via the mobile telephone network with which they are registered (and they may be registered with different networks, provided that there is a link between the networks).
The mobile terminals may also communicate with each other via some other medium (a "local connection") - for example a Bluetooth, infra-red, nearfield or the like link.
Although the term "local connection" is used herein, it should be appreciated that the invention is not limited to the two devices being spaced apart by less than a predetermined distance. Typically, the local connection will be a direct connection between the devices - i.e. transmitted data will not pass through an intermediary - although this is not essential.
It should also be appreciated that the invention is not limited to communications between mobile telephone terminals. The invention is applicable to communication between any type of terminals (or combinations of types of terminals) where two communications media are available for exchanging data between the terminals.
i- - An embodiment will be described that enables users who have a mobile phone registered with either the same network operator or different operators to establish a secure local communication channel between them with the help of their related network operator. An authenticated channel is established between the two mobile terminal devices and attached to the mobile terminal through their operator networks without the need for a public key certificate (and a Certification Authority). The only information required to establish such a channel is the mobile users' MSISDN (Mobile Station Integrated Services Digital Network) numbers. The or each operator network then assists to transfer the users' public keys securely to both parties. The embodiment described is for securing local communication between respective terminals - such as in Personal Area Networks created by Bluetooth or WEAN.
The terminals exchange keys by means of their connection to their respective mobile telephone network. The keys are then used to encrypt the local communication link. By not exchanging keys over the local communication link, security is enhanced.
Referring to Figure 1, user A wishes to use his mobile terminal A 100 to establish a secure local communication link 102 with user B's mobile terminal B 104. The link 102 may be a Bluetooth or WLAN connection which allows direct exchange of data between the terminals, for example. In the embodiment described the secure communication channel 102 is formed by encrypting communications from terminal A 100 to terminal B 104 using terminal B's public key, and by encrypting communications from terminal B 104 to terminal A 100 using terminal A's public key. Such encrypted communications are decrypted by using the relevant private key stored in the receiving terminal.
As well as having the facility to establish the local communication link therebetween, terminals A 100 and B 104 are registered with respective mobile or cellular telecommunications networks _ 106 and _ 108. The networks _ 106 and B 108 may be, for example, GSM or UMTS (3G) networks. The networks A 106 and B 108 need not be the same type of network.
In accordance with an aspect of the invention the networks _ 106 and B 108 are provided with respective key exchange servers _ 110 and B 112. Key exchange server A 110 is provided within or is associated with network A 106.
Key exchange server B 112 is provided within or is associated with network B 108. Key exchange server A 110 and key exchange server B 112 are for facilitating the secure exchange of public keys between mobile terminals registered with the respective networks.
Key exchange server A 110 and key exchange server B 112 may have public I--; key certificates that are issued to the associated network operator itself (that is, not to individual subscribers or mobile terminals registered with the networks) by a third party certification authority. Such certificates are not essential to the invention but may enable the arrangement described to be more scaleable.
Although the embodiment described relates to an arrangement where the mobile terminals A 100 and B 104 wish to establish a secure local communication session are registered with respective networks A 106 and B 108, the invention is also applicable to the establishment of the secure local communication session between terminals that are both registered with the same network.
An authenticated connection 113 between the key exchange server _ 110 and the key exchanger server _ 112 ofthe respective networks should preferably be provided. Authenticated connections already exist between operators that have roaming agreements with each other. For network operators that do not have such links established, operator certificates can be used to create authenticated links on the fly (i.e. when required). If neither certificates are used nor an authenticated channel is possible then security is significantly reduced.
Therefore, the network operators should inform the users that no authenticated channel can be established between the network operator in order to establish the public key exchange. The user can then decide whether to proceed with the key exchange procedure on his/her own risk. Even in such a scenario, the embodiment will still provide higher level of security than exchanging public keys over an unsecured local link such as Bluetooth. This is due to the fact that an attacker would not necessarily have access to the inter-operator links that provide the key assistance at the same time as the attacker would have access to the local link.
Key-exchange servers A 110 and B 112 are able to communicate over an IP based network such as the Internet. The mobile terminals A 100 and B 104 also have Internet Protocol (IP) connectivity to a network such as the Internet.
For management of communication sessions between the terminals A 100 and B 104 and the networks, Session Initiation Protocol (SIP) defined by Internet Engineering Task Force (IETF) is used in the embodiment. SIP operates using the Internet Protocol (IP). Communications between the terminal A 100 and _ 104 and their networks A 106 and B 108 may be by SIP over GPRS.
An MSISDN can be converted to a public SIP ID in the form of MSISDN[operator] (e.g. MSISDNvodafone.com) where the [operator] is the network operator's Internet domain name, i.e. the Fully Qualified Domain Name (FQDN that the MSISDN is originally registered with. MSISDN corresponds to an E.164 format, as described in ITU-T (International Telecommunication Union) Recommendation E.164, published May 1997, which is fillly incorporated herein by reference. MSISDN uniquely identifies each mobile subscriber in their own network. A conversion mechanism of E. 164 (MSISDN) to SIP names have been proposed in the ETF ENUM group (see publication: P. Faltstrom, "E.164 number and DNS" ETF RFC 2916, September 2000, which is fully incorporated herein by reference).
Network 106 A is provided with a SIP server _ 114 and network B 108 is provided with a SIP server B 116. Mobile terminals _ 100 and _ 104 are registered with the SIP server associated with their network using the terminal's public SIP ID: MSISDN(operator ID. For example, mobile terminal A 100 may be automatically registered with SIP server A 114 when the mobile terminal A 100 is initially registered with network A 106. Mobile terminal _ 104 may be similarly registered with SIP server B 116.
Each key-exchange server _ 110 and B 112 has an IP address that uniquely identifies the server on the Internet. The IP address of the key exchange server _ 110 can be configured on mobile terminal _ 100. Alternatively the IP address can be automatically transmitted to the mobile terminal _ 100 by the network operator _ 106 when the mobile terminal A 100 is connected to the Internet using standard IP address parameter assignment techniques such as DHCP (Dynamic Host Configuration Protocol). The IP address of key exchange server B 112 may be similarly provided to mobile terminal B 104.
Combined with the FQDN of the operator, MSISDNoperator SIP address can uniquely identify a user and its network on the Internet.
The procedure to allow user A and user _ to establish a secure local communication between their terminals _ and _ will now be described with reference to the flow chart of Figure 2.
(Step 1) User _ types the MSISDN number (which is readily publicly available) of User _ inside her mobile terminal A 100.
(Step 2) An ENUM mechanism in terminal _ 100 translates the MSISDN of terminal B 104 into the SIP ID of terminal _ 104.
(Step 3) Terminal _ 100 generates a SIP-INVITE message for terminal B 104 using terminal B's SIP ID, and in the SDP (Service Description Protocol) message body includes the following fields populated accordingly: s = 0AKE-address i = Operator Assisted Key Exchange m = application [port number] TCP OAKE a = 0AKE-IP:[IP Address of Key Exchange Server I SDP is described in publication: M. Handley, V. Jacobson, "SDP: Session Description Protocol", IETF RFC 2327, April 1998, which is fully incorporated herein by reference.
Other fields can be added to extend the information given but at minimum the session should be described as a Operator Assisted Key Exchange (OAKE) and the IF address of_'s Key exchange Server_ 112 should be given in the SDP.
Port number is the assigned TCP port number for this application. The actual number to be assigned needs to be consistent within all implementations. It should also not conflict with existing assigned port numbers for well-known applications. 1'
(Step 4) Terminal _ 100 sends this SIP-INVITE message over the Internet to network B 108 using standard SIP mechanisms. If B's MSISDN has been ported to another network other than the one given by the ENIJM, then the previous network's SIP server is required to forward the request to the current network with which B is subscribed.
(Step 5) B's mobile terminal B 104 receives the SIP-INVITE from network B 108. Terminal B 104 understands by looking at the SDP parameters that it is a session request for operator key exchange. Terminal B recovers the IF Address of key exchange server _ 100 from the relevant SDP parameter and stores it in mobile terminal B's 104 memory. Terminal _ 104 generates a SIP-200-OK message to indicate that B accepts the session. In this message terminal B 104 he also includes key exchange server _'s IP address. Terminal _ 104 also generates B's public and private key pairs to be used in order to secure the local communication link. These keys may be created using the well-known RSA algorithm. The details of the key generation will be known to those skilled in the art and will not be described further here for the sake of brevity. 1C
The SDP message body includes the following fields: OAKE-address i = Operator Assisted Key Exchange m = application [port number] TCP OAKE a = 0AKE-IP:[IP Address of Key Exchange Server B1 (Step 6) Terminal A 100 receives the SIP-200-UK message and generates a SIP-ACK message in order to acknowledge B's acceptance of the session. At the same time terminal _ 100 generates its public and private key pairs.
(Step 7) Terminal A 100 sends a SIP-INVITE message to key exchange server _ 110 using the known IF address thereof. The SDP message body indicates that an operator assisted key exchange is required between key exchange server _ 110 and key exchange server B 112. The message also includes the IP address of key exchange server B 112 in the SDP parameters. A random number is also used for a transaction ID in order to uniquely identify this request between A and B. The message body also includes the MSISDN of B. The SDP message body includes the following fields: s = CAKE i = Operator Assisted Key Exchange m = application [port number] TCP OAKE a = 0AKE-IP:[IP Address of Key Exchange Server_] a = Transaction ID:[Transaction ID] a = Public key:[A's Public Key] Sender: [SIP ID Al a = Recipient: [SIP ID 81 (Step 8) Key exchange server _ 110 then locates B's key exchange server B 112 based on the IF address used in the SIP-INVITE (OAKE-IP field). Key exchange server_ 100 tries to create a secure channel with key Exchange server B 112 using the TLS (Transport Layer Security) protocol using their operator public key certificates (if available) step 9. If this operation fails, key exchange server A 110 checks whether an existing secure connection exists between itself and server B 112 step 10. This existing connection could be based on the IPsec protocol. If no secure connection exists then key exchange server A considers the link between two servers unsecured.
Otherwise the link is considered secure. Key exchange server _ 110 responds back to mobile terminal _ 100 with SIP-200 OK with the following SDP parameters populated- step 11.
s = CAKE i = Operator Assisted Key Exchange m = application [port number] TCP OAKE a = 0AKE-IP:[IP Address of Key Exchange Server 0 a = Transaction ID:[Transaction ID] a = Public key:[Public Key 6 a = Sender: [SIP ID I a = Recipient: [SIP ID B1 a = Security Level: [Secure/Unsecured] The Security Level parameter is populated according to secured or unsecured based on the availability of a secure channel as described before.
Mobile terminal _ 100 checks the security level described in the SDP parameters and displays a prompt on terminal _ 100 to user A if the level is unsecured - step 12. If prompted user _ can chose to continue with the procedure or to terminate - step 13. If _ decides to continue (or if a secure connection has been determined to exist in step 10) then terminal A 100 sends a SIP-ACK to the Key Exchange server _100 to establish the session - step 14.
Otherwise terminal A lOO sends a SIP-CANCEL to terminate the procedure step 15.
(Step 16) Upon receiving the SIP-ACK from terminal A LOO, the key exchange server _ 110 sends a SIP-INVITE to key exchange server B 1 12 with the same SDP parameters A used.
s = CAKE i = Operator Assisted Key Exchange m = application [port number] TCP OAKE a = 0AKE-IP:[IP Address of Key Exchange Server hi a = Transaction ID:[Transaction ID] a = Public key:[Public Key a = Sender: [SIP ID A a = Recipient: [SIP ID B1 a = Security Level:[SecurefUnsecured] (Step 17) Upon receiving the SIP-INVITE from server _ 110, server B 112 checks whether this message is received over a secure channel. Server B 112 then compares this information with the entry in the "Security Level" field. If they do not match it sends a SIP-CANCEL message and terminates the protocol (step 15). If the security levels match then server B 112 forwards this INVITE with the relevant changes in the SIP parameters to terminal B 104 - step 18.
Upon receiving the SIP-INVITE from key exchange server B 112 mobile terminal B 104 checks the security level field in the SDP - step 19. If the field is not secured it prompts user B for confirmation - step 20. If user B agrees to continue the protocol even if the link is not secured terminal B 104 stores the public key of user A and the Transaction ID associated with the key, and then a SIP-200 OK is sent back to the key exchange server B 112 - step 21. Also, if the security level is populated as secure then terminal B 104 stores the public key of_ and the Transaction ID associated with the key. Terminal B 104 then sends a SIP200 OK back to key exchange server B 112 - step 21.
Key exchange server B 112 than forwards the request after changing the relevant SIP parameters to those of key exchange server _ 110 - step 22.
Key exchange server _ 110 sends an SIP-ACK to key exchange server B 112 to confirm the session establishment - step 23.
Key exchange server _ 110 sends a SIP-BYE message to mobile terminal _ and to key exchange server _ 112 to close the previously opened SIP sessions and confirm that terminal _ 104 has successfully received the public key with the following SDP parameters - step 24: s = CAKE i = Operator Assisted Key Exchange m = application [port number] TCP OAKE a = 0AKE-IP:[IP Address of Key Exchange Server 8 a = Transaction ID:[Transaction ID] a = Public key:[Public Key a = Sender: [SIP ID 6 a = Recipient: [SIP ID 01 a = Security Level: [Secure/Unsecured] a = Completed:True Upon receiving BYE from key exchange server _ llO, terminal A 100 considers user _'s public key successfully sent to user B. User B enters _'s MSISDN in mobile terminal B 104 and same steps 1-25 are performed for user B instead of user _.
Terminals _ and B can then use the a combination of their Transaction IDs to create a unique transaction ID to associate the public keys exchanged using the operated assisted key exchange session: UniqueID=Hash(Transaction-ID(O I lTransaction-ID(O).
Terminals A and B can then use any standard key exchange mechanism such as Internet Key Exchange (IKE) or TLS with their exchanged public key to create a secure channel 102 between them. This procedure will be known to those skilled in the art and will not be described further, for the sake of brevity.
In the embodiment the MSISDN is used as a PIN (Personal Identification Number) to authenticate the public keys exchanged between A and B. The MSISDN is not a secret number - as a traditional PIN. MSISDN (i.e. telephone number) can be looked up in a telephone directory or can be written in business cards or other forms of publicly available media.
The embodiment removes the need for public key certification for devices that have already access to a mobile phone network. It also enables the users to receive authentic public keys without the need for any proximity assumption.
It is relatively simple and practical to implement compared to its alternatives.
This approach fulfils the security requirements of users who already trust their operator to deliver authenticated services such as sending SMS and connecting calls to the correct recipient. Data transferred over the wireless operator networks such as GSM/GPRS/UMTS are encrypted over the air interface therefore it is not feasible for an active attacker to launch a man-in-the-middle (MITM) attack to successfully change the contents of the public key transmitted over the mobile network. Effectively encryption on the air interfaces (one on each end of the link) creates an authenticated channel between two users who have access to a mobile network. It is possible that data transmitted inside (after the air interface) the mobile networks may not be encrypted. However, this does not present a high security risk as in order for the attack to launch a MITM, the attacker needs to have access capability to an operator network at the same time have the capability to change the public key exchanged on a separate channel such as Bluetooth link. It is very unlikely that an attacker will have the ability to do both at the same time. There could be attacks inside the operator network alone or attackers that modify the public keys exchanged on the unsecured channel but the combination of two would be unlikely. As operators are already trusted to carry sensitive information like voice traffic, financial transactions through their Wireless Application Gateway (WAP) servers, internal security in a mobile network is well established. The links between operators are also secured by using private (leased) data links or over the Internet using encryption.
In an alternative to the embodiment described, the public keys of users A and _ are stored by networks _ and B respectively. The networks then provide the public keys _ and _ to third parties in the manner and in accordance with the conditions described above.
Although the embodiment described user public-private key pairs to establish a secure local communication link a shared secret key could be used by the terminals _ and B. A new shared secret key is generated by one of the networks _ and B for each communication session and is transmitted to the terminals _ and B in the manner and in accordance with the conditions described above. For example, each network may have a master key and uses this to generate sub keys to create a shared secret key.
Of course, a secure local communication session can be established between more than two terminals in accordance with the invention.

Claims (36)

1. A method of creating a secure local communication channel between respective terminals, each of which is registered with a communication network the method including exchanging encryption key data between the terminals via the or each communication network, and establishing a secure local communication channel between the terminals by encrypting data transmitted between the terminals during the local communication session using the encryption key data.
2. The method of claim 1, wherein an encryption key is generated by one of said terminals and is transmitted to a another of said terminals via the or each communication network.
3. The method of claim 1 or 2, wherein each terminal is registered with the same network.
4. The method of claim 1 or 2, wherein each terminal is registered with a different network.
5. The method of any one of claims 1 to 4, wherein the local communication channel between the terminals comprises a Bluetooth or WEAN link.
6. The method of any one of claims 1 to 5, wherein the or each network comprises a mobile telecommunications network and the terminals comprise mobile telecommunication terminals.
7. The method of claim 6, wherein the or each networks include one of a GSM and UMTS (3G) network.
8. The method of any one of claims 1 to 7, wherein the terminals communicate with their communication network by means of Session Initiation Protocol (SIP).
9. The method of any one of claims 6 to 8, including identifying the terminal with which encryption key data is to be exchanged using that terminal's MSISDN.
10. The method of claim 9 when dependent on claim 8, including converting said MSISDN into a SIP identifier.
11. The method of any one of claims 3 to 10, including determining whether a secure communication link can be established between the respective communication networks, and selectively exchanging the encryption key data between the communication networks in dependence upon that determination.
12. The method of any one of claims 1 to 11, wherein the encryption key data comprises public keys of the respective terminals.
1013. A method of transmitting a key associated with a first device to a second device to allow formation of an encrypted communication channel between the devices, wherein the devices are registered with a communication network, the method including transmitting the key to the second device via the or each communication network such that the key received by the second terminal can be used to send encrypted data to the first terminal over a communication channel not including the or each network.
14. The method of claim 13, wherein said key is generated by said first device and is transmitted to said second device via the or each communication network.
15. The method of claim 13 or 14, wherein each device is registered
16. The method of claim 13 or 14, wherein each device is registered with a different network.
17. The method of any one of claims 13 to 16, wherein said communication channel comprises a Bluetooth or WLAN link.
18. The method of any one of claims 13 to 17, wherein the or each network comprises a mobile telecommunications network and the devices comprise mobile telecommunication terminals.
19. The method of claim 18, wherein the or each networks include one of a GSM and IJMTS (3G) network.
20. The method of any one of claims 13 to 19, wherein the devices communicate with their associated communication network by means of Session Initiation Protocol (SIP).
21. The method of any one of claims 18 to 21, including identifying the terminal with which encryption key data is to be exchanged using that terminal's MSISDN.
22. The method of claim 21 when dependent on claim 20, including converting said MSISDN into a SIP identifier.
23. The method of any one of claims 15 to 22, including determining whether a secure communication link can be established between the respective communication networks, and selectively transmitting the said key between the communication networks in dependence upon that determination.
24. The method of any one of claims 13 to 23, wherein said key comprises a public key of the first device.
25. A communication system including a mobile telecommunications network a mobile terminal and a key exchange server for transmitting a key to the mobile terminal via said mobile telecommunications network the mobile terminal being adapted to receive the key from the mobile telecommunications network and to establish an encrypted communication link with another terminal using said key.
26. The system of claim 13, wherein said key is generated by a further terminal and is transmitted to the first-mentioned terminal via the mobile telecommunications network.
27. The system of claim 26, including a further mobile telecommunications network and wherein each terminal is registered with a different network.
28. The system of any one of claims 25 to 27, wherein said communication link comprises a Bluetooth or WEAN link.
29. The system of any one of claims 25 to 28, wherein the or each networks include one of a GSM and UMTS (3G) network.
30. The system of any one of claims 25 to 29, wherein the mobile terminal communicates with its associated mobile telecommunications network by means of Session Initiation Protocol (Sap).
31. The system of claim 21 when dependent on claim 20, including means for converting an MSISDN of said terminal into a SIP identifier of said terminal.
32. The system of any one of claims 27 to 31, including means for determining whether a secure communication link can be established between the respective communication networks and for selectively
J
transmitting the said key between the communication networks in dependence upon that determination.
33. The system of any one of claims 25 to 31, wherein said key comprises a public key of the first device.
34. A method of creating a secure local communication channel between respective terminals, substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.
35. A method of transmitting a key associated with a first device to a second device to allow formation of an encrypted communication channel between the devices, substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.
36. A communication system substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.
GB0403171A 2004-02-12 2004-02-12 Secure communications between terminals Expired - Fee Related GB2411086B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0403171A GB2411086B (en) 2004-02-12 2004-02-12 Secure communications between terminals

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0403171A GB2411086B (en) 2004-02-12 2004-02-12 Secure communications between terminals

Publications (3)

Publication Number Publication Date
GB0403171D0 GB0403171D0 (en) 2004-03-17
GB2411086A true GB2411086A (en) 2005-08-17
GB2411086B GB2411086B (en) 2006-12-06

Family

ID=32011825

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0403171A Expired - Fee Related GB2411086B (en) 2004-02-12 2004-02-12 Secure communications between terminals

Country Status (1)

Country Link
GB (1) GB2411086B (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005046376A1 (en) * 2005-09-28 2007-04-12 Siemens Ag Method and apparatus for preventing the reception of unwanted messages in an IP communication network
WO2008075792A1 (en) * 2006-12-21 2008-06-26 Panasonic Corporation Authentication method, system, and apparatus thereof for inter-domain information communication
GB2451226A (en) * 2007-06-01 2009-01-28 Asim Bucuk A method and system for the creation, management and authentication of links between people, entities, objects and devices
EP2022282A2 (en) * 2006-04-28 2009-02-11 Motorola, Inc. Method and system for providing cellular assisted secure communications of a plurality of ad hoc devices
GB2475868A (en) * 2009-12-03 2011-06-08 Rohan Obied Wireless communication between people of unknown identity
WO2011132151A1 (en) 2010-04-23 2011-10-27 Telefonaktiebolaget L M Ericsson (Publ) ENABLING IPv6 MOBILITY WITH SENSING FEATURES FOR AD-HOC NETWORKS DERIVED FROM LONG TERM EVOLUTION NETWORKS
US20110294422A1 (en) * 2006-06-29 2011-12-01 Nikolaus Fuchs Method and apparatuses for transmitting information by means of far field and short range communication
EP3306891A1 (en) * 2016-10-06 2018-04-11 Bayerische Motoren Werke Aktiengesellschaft Method of communication and communication module for a vehicle
EP3487199A1 (en) * 2017-11-16 2019-05-22 Simmonds Precision Products, Inc. Multiple transceivers for wireless key update

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9100382B2 (en) 2012-03-20 2015-08-04 Qualcomm Incorporated Network security configuration using short-range wireless communication
US9749134B2 (en) 2013-06-20 2017-08-29 Qualcomm Incorporated Wireless configuration using passive near field communication

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1055307A1 (en) * 1998-02-11 2000-11-29 Telefonaktiebolaget LM Ericsson (publ) System, method and apparatus for secure transmission of confidential information
WO2002011469A2 (en) * 2000-08-01 2002-02-07 Nokia Corporation Techniques for performing umts-authentication using sip (session initiation protocol) messages
WO2002082742A1 (en) * 2001-04-04 2002-10-17 Connectblue Ab Method for transferring a device identifier block on a second communication link separated from the bluetooth link
GB2379361A (en) * 2001-09-01 2003-03-05 Motorola Inc Encrypted direct mode operation (DMO) in a radio communication system
EP1311136A1 (en) * 2001-11-12 2003-05-14 Lucent Technologies Inc. Authentication in telecommunications networks
US20030217165A1 (en) * 2002-05-17 2003-11-20 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
WO2004017617A1 (en) * 2002-08-14 2004-02-26 Thomson Licensing S.A. Session key management for public wireless lan supporitng multiple virtual operators
EP1406464A1 (en) * 2002-09-25 2004-04-07 Siemens Aktiengesellschaft Method and communication device for secure set-up of a communication connection

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1055307A1 (en) * 1998-02-11 2000-11-29 Telefonaktiebolaget LM Ericsson (publ) System, method and apparatus for secure transmission of confidential information
WO2002011469A2 (en) * 2000-08-01 2002-02-07 Nokia Corporation Techniques for performing umts-authentication using sip (session initiation protocol) messages
WO2002082742A1 (en) * 2001-04-04 2002-10-17 Connectblue Ab Method for transferring a device identifier block on a second communication link separated from the bluetooth link
GB2379361A (en) * 2001-09-01 2003-03-05 Motorola Inc Encrypted direct mode operation (DMO) in a radio communication system
EP1311136A1 (en) * 2001-11-12 2003-05-14 Lucent Technologies Inc. Authentication in telecommunications networks
US20030217165A1 (en) * 2002-05-17 2003-11-20 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
WO2004017617A1 (en) * 2002-08-14 2004-02-26 Thomson Licensing S.A. Session key management for public wireless lan supporitng multiple virtual operators
EP1406464A1 (en) * 2002-09-25 2004-04-07 Siemens Aktiengesellschaft Method and communication device for secure set-up of a communication connection

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005046376A1 (en) * 2005-09-28 2007-04-12 Siemens Ag Method and apparatus for preventing the reception of unwanted messages in an IP communication network
DE102005046376B4 (en) * 2005-09-28 2007-07-05 Siemens Ag Method and apparatus for preventing the reception of unwanted messages in an IP communication network
EP2022282A4 (en) * 2006-04-28 2012-04-04 Motorola Solutions Inc Method and system for providing cellular assisted secure communications of a plurality of ad hoc devices
EP2022282A2 (en) * 2006-04-28 2009-02-11 Motorola, Inc. Method and system for providing cellular assisted secure communications of a plurality of ad hoc devices
US20110294422A1 (en) * 2006-06-29 2011-12-01 Nikolaus Fuchs Method and apparatuses for transmitting information by means of far field and short range communication
US8327144B2 (en) 2006-12-21 2012-12-04 Panasonic Corporation Authentication method, system, and apparatus thereof for inter-domain information communication
WO2008075792A1 (en) * 2006-12-21 2008-06-26 Panasonic Corporation Authentication method, system, and apparatus thereof for inter-domain information communication
GB2451226A (en) * 2007-06-01 2009-01-28 Asim Bucuk A method and system for the creation, management and authentication of links between people, entities, objects and devices
GB2475868A (en) * 2009-12-03 2011-06-08 Rohan Obied Wireless communication between people of unknown identity
WO2011132151A1 (en) 2010-04-23 2011-10-27 Telefonaktiebolaget L M Ericsson (Publ) ENABLING IPv6 MOBILITY WITH SENSING FEATURES FOR AD-HOC NETWORKS DERIVED FROM LONG TERM EVOLUTION NETWORKS
US8385269B2 (en) 2010-04-23 2013-02-26 Telefonaktiebolaget L M Ericsson (Publ) Enabling IPv6 mobility with sensing features for AD-HOC networks derived from long term evolution networks
EP3306891A1 (en) * 2016-10-06 2018-04-11 Bayerische Motoren Werke Aktiengesellschaft Method of communication and communication module for a vehicle
DE102016118998A1 (en) * 2016-10-06 2018-04-12 Bayerische Motoren Werke Aktiengesellschaft Method for communicating and communication module for a motor vehicle
DE102016118998B4 (en) 2016-10-06 2023-09-28 Bayerische Motoren Werke Aktiengesellschaft Method for communicating and communication module for a motor vehicle
EP3487199A1 (en) * 2017-11-16 2019-05-22 Simmonds Precision Products, Inc. Multiple transceivers for wireless key update
US10819512B2 (en) 2017-11-16 2020-10-27 Simmonds Precision Products, Inc. Multiple transceivers for wireless key update

Also Published As

Publication number Publication date
GB2411086B (en) 2006-12-06
GB0403171D0 (en) 2004-03-17

Similar Documents

Publication Publication Date Title
CN100592731C (en) Lawful interception of end-to-end encrypted data traffic
JP5496907B2 (en) Key management for secure communication
EP1717986B1 (en) Key distribution method
US8832821B2 (en) Method and apparatuses for end-to-edge media protection in an IMS system
US8990569B2 (en) Secure communication session setup
EP2335391B1 (en) Key management in a communication network
EP1374533B1 (en) Facilitating legal interception of ip connections
US20070198837A1 (en) Establishment of a secure communication
EP1835688A1 (en) SIM based authentication
US20080137859A1 (en) Public key passing
RU2328082C2 (en) Protection method of interim data traffic mobile network and ims network
GB2411086A (en) Secure communication between terminals over a local channel using encryption keys exchanged over a different network
WO2008040213A1 (en) Message encryption and signature method, system and device in communication system
CN100544247C (en) The negotiating safety capability method
KR20070006913A (en) Fast and secure connectivity for a mobile node
WO2002043427A1 (en) Ipsec connections for mobile wireless terminals
JP2009260847A (en) Vpn connection method, and communication device
Belmekki et al. Enhances security for IMS client
Vesterinen User authentication in SIP
CN110933673B (en) Access authentication method of IMS network
Cheng et al. Id: A mandatory field in ike
Rantapuska SIP call security in an open IP network
la Tour et al. SECURE AUTHENTICATION FOR MOBILE COMMUNICATION OVER THE INTERNET
Kong Security system for passive IP devices on SIP-based networks

Legal Events

Date Code Title Description
PCNP Patent ceased through non-payment of renewal fee

Effective date: 20160212