Generic bootstrapping architecture protocol

Abstract

Method and system for communicating securely with a user equipment, UE, using generic bootstrapping architecture, GBA, the system comprising a bootstrapping server function, BSF. A proxy server configured to receive messages from a user equipment, UE, in a first format. Convert the received messages from the first format to a second format. Transmit the received UE messages to a bootstrapping server function, BSF, in the second format. Receive messages from the BSF, in a third format. Convert the messages received from the BSF from the third format to a fourth format. Transmit the received BSF messages to the UE in the fourth format.

Claims

1. A proxy server for generic bootstrapping architecture, (GBA) the proxy server configured to: receive messages from a user equipment, UE, in a first format; convert the messages received from the UE from the first format to a second format, including the proxy server operating to check whether each of the messages received from the UE includes content presenting a risk of system crashing or security vulnerabilities at a bootstrapping server function (BSF) and to reject or correct each of the messages received from the UE that is determined to be insecure; check the messages received from the UE for compliance with GBA requirements; transmit each of the messages received from the UE that is not rejected in the second format to the BSF; receive messages from the BSF in the third format; convert the messages received from the BSF from the third format to a fourth format; and transmit the messages received from the BSF in the fourth format to the UE.

2. The proxy server of claim 1, wherein the messages received from the UE by the proxy server and/or transmitted from the proxy server to the UE are over a Ub interface, and/or wherein the messages received from the BSF by the proxy server and/or transmitted from the proxy server to the BSF are over a Ub interface.

3. The proxy server according to claim 1 wherein the format conversion from the first format to the second format and from the third format to the fourth format further comprise a translation of protocol.

4. The proxy server according to claim 1 formed within a device management, DM, server.

5. A method for communicating between a user equipment, UE, and a bootstrapping server function, (BSF) using generic bootstrapping architecture (GBA), the method comprising: receiving one or more messages from the UE at a proxy server, in a first format; converting the one or more messages received from the UE from the first format to a second format, including checking whether each of the messages received from the UE includes content presenting a risk of system crashing or security vulnerabilities at the BSF and rejecting or correcting each of the messages received from the UE that is determined to be insecure; checking the messages received from the UE for compliance with GBA requirements; transmitting each of the one or more messages received from the UE that is not rejected in the second format from the proxy server to the BSF; receiving one or more messages from the BSF in a third format at the proxy server; converting the one or more messages received from the BSF from the third format to a fourth format; and transmitting the one or more messages received from the BSF in the fourth format from the proxy server to the UE.

6. The method of claim 5, wherein the one or more messages received from the UE by the proxy server and/or transmitted from the proxy server to the UE are over a Ub interface, and further wherein the one or more messages received from the BSF by the proxy server and/or transmitted from the proxy server to the BSF are over a Ub interface.

7. The method of claim 5, wherein the received and transmitted one or more UE and BSF messages include: a request for a shared secret received from the UE and transmitted to the BSF; and data to establish the shared secret received from the BSF and transmitted to the UE.

8. The method of claim 7, wherein the request for the shared secret transmitted to the BSF includes an identifier of the UE.

9. The method of claim 8, wherein the identifier of the UE is obtained from a device management, DM, server or a network application function, NAF.

10. The method of claim 9 further comprising the DM server obtaining the UE identifier from a Radius Accounting Start message.

11. The method of claim 7, wherein the data to establish the shared secret received from the BSF is transmitted to the UE from the proxy server using GBA push messaging.

12. The method of claim 11, wherein the push message is delivered over CoAP.

13. The method of claim 12, wherein the CoAP is bound to UDP or SMS.

14. The method of claim according to claim 11, wherein the one or more messages received from the UE by the proxy server and/or transmitted from the proxy server to the UE are GBA push messages, and further wherein the one or more messages received from the BSF by the proxy server and/or transmitted from the proxy server to the BSF are GBA push messages.

15. The method according to claim 7 further comprising authenticating, verifying and/or proving possession of the shared secret between the BSF and UE directly over CoAP or LWM2M protocols.

16. The method according to claim 7, wherein the proxy server is formed together with a network application function, NAF, as a device management, DM server.

17. The method of claim 16 further comprising using the shared secret or a further derived shared secret (Ks_NAF) to secure a communication between the UE and the NAF.

18. The method according to claim 7, wherein the shared secret is referenced by a bootstrapping transaction identifier, B-TID.

19. The method of claim 18, wherein the B-TID is passed directly to a network application function, NAF, from the proxy server.

20. The method of claim 19 further comprising passing the shared secret or a further derived shared secret (Ks_NAF) directly from the proxy server to the NAF.

21. A system for communicating securely with a user equipment (UE), using generic bootstrapping architecture (GBA) the system comprising: a bootstrapping server function (BSF); and a proxy server configured to: receive messages from the UE in a first format; convert the messages received from the UE from the first format to a second format, including the proxy server operating to check whether each of the messages received from the UE includes content presenting a risk of system crashing or security vulnerabilities at the BSF and to reject or correct each of the messages received from the UE that is determined to be insecure; check the messages received from the UE for compliance with GBA requirements; transmit each of the messages received from the UE that is not rejected in the second format to the BSF; receive messages from the BSF in a third format; convert the messages received from the BSF from the third format to a fourth format; and transmit the messages received from the BSF in the fourth format to the UE.

22. The system of claim 21, wherein the proxy server is formed together with a network application function, NAF, as a device management, DM server.

23. The system of claim 22, wherein the DM server further comprises a buffer arranged to store one or more identifiers of the UE and an associated address.

24. The system of claim 23, wherein the buffer is a circular buffer.

25. The system of claim 23, wherein the buffer is further arranged to provide the one or more identifiers of the UE for a particular address.

26. The system according to claim 21, further comprising a Ub interface between the UE and the proxy server and/or between the proxy server and the BSF.

Description

BRIEF DESCRIPTION OF THE FIGURES

(1) The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

(2) FIG. 1 shows a sequence diagram of interactions between components operating according to the generic bootstrapping architecture (GBA) protocol (prior art);

(3) FIGS. 2, 2A, 2B, 2C and 2D shows a sequence diagram of components operating according to an example amended protocol. FIG. 2 represents the way the four quadrants (FIG. 2A, FIG. 2B, FIG. 2C and FIG. 2D) should be assembled in order to display the overall sequence diagram;

(4) FIG. 3 shows parts of the sequence diagram of FIG. 2 shown in further detail;

(5) FIG. 4 shows further enhancements of the GBA protocol according to further examples;

(6) FIG. 5 shows a sequence diagram including an example GBA protocol at a higher level;

(7) FIG. 6 shows a schematic diagram of a system for implementing the GBA protocols of FIGS. 2 to 5; and

(8) FIG. 7 shows a further schematic diagram of the system for implementing the GBA protocols of FIGS. 2 to 5.

(9) It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

(10) The Ub interface of GBA allows messages or communications to be sent between one or more UEs 20 and a BSF 30 (see FIG. 1). This Ub interface is replaced by a proxy 110, intermediary, or proxy server. In one embodiment, this proxy 110 is placed on the same server platform that hosts the NAF 40. This may be a device management (DM) server 50 platform, for example. The proxy 110 solves the security problem of a direct connection between UE 20 and BSF 30. The proxy can filter and inspect the Ub protocol to ensure that messaging is well-formed and consistent with the GBA standard, before passing messages on to the BSF. It also can assist where UEs do not support an HTTP stack because the proxy can perform protocol translation if necessary. This revised flow (including the proxy 110) is shown in FIG. 2. In particular, the flows involving the proxy 110 are circled 100.

(11) A simplified diagram (omitting the initial exchanges on the Ua interface) is shown on FIG. 3. This figure includes exchanges that provide the UE 20 (from the BSF 30) with a shared secret to be used for future secure communications (according to the GBA standard defined as part of the 3GPP specification http://www3gpp.org/DynaReport/33220.htm).

(12) FIG. 3 shows an example set of interactions between the various components forming the system. Corresponding or similar interactions have the same reference numerals in all of the figures. These interactions include:

(13) 1. The UE 20 requesting a new secret (between an app and generic authentication architecture (GAA) server within the UE 20).

(14) 2. GAA server sends the request for the new secret (plus NAF identifier) to the proxy 110.

(15) 3. The proxy 110 sends the request to the BSF 30 within a core network. The request is accompanied by an IP multimedia private identity (IMPI) to identify the requesting UE 20.

(16) 4. The request is sent from the BSF 30 to the HLR/HSS.

(17) 5. An authentication vector (AV), including a cipher key (CK) and integrity key (IK), is retrieved by the BSF 30 from the HLR/HSS.

(18) 6. Part of the AV (including RAND and AUTN) is sent from the BSF 30 to the proxy 110 (including B-TID).

(19) 7. Part of the AV is sent from the proxy 110 to the UE 20.

(20) 8. The RAND and AUTN is validated and a RES, CK, IK are derived in the SIM card (UICC) of the UE 20.

(21) 9. Validity is confirmed within the UE 20.

(22) 10. A message confirming the new secret is sent from the UE 20 to the proxy 110 including a proof of possession of the response data (RES).

(23) 11. This message is passed from the proxy 110 to the BSF 30 to validate the response.

(24) 12. Upon validation, the BSF 30 sends the proxy 110 a confirmation message.

(25) 13. This is passed on to the UE 20.

(26) 14. The secret Ks_NAF is derived (from CK, IK, IMPI and NAF_id) and returned to the app.

(27) 15. The app requests that the same secret is created on the NAF 40.

(28) 16. The NAF 40 is registered on the BSF 30, which then authenticates the NAF and derives the Ks_NAF.

(29) 17. The derived secret Ks_NAF is returned to the NAF 40.

(30) 18. Ks_NAF is moved to a component of the server (DM), which implements the device management protocol.

(31) 19. Communications may now be secured using Ks_NAF between the DM and the UE 20 (app).

(32) Whilst the example shown in FIG. 3 provides one example method for providing secure communications between the UE 20 and the DM server 50 (using the proxy 110), other variations and optimisations may be made. These optimisations and simplifications are shown in FIG. 4. References are to the steps circled in FIG. 4. Any of the described optimisations may be used with any one or more (or all) other optimisations.

(33) Optimisations and Variations:

(34) A. Step 2 (150) may be omitted by using information already available within the DM server 50 platform to communicate a UE 20 identity directly to the proxy 110 and therefore, the protocol may move directly to step 3.

(35) As soon as a device is assigned an IP address by a gateway GPRS support node (GGSN), the GGSN may send a Radius Accounting Start message to the DM Server 50 Platform, advising of the mapping between the UE's IP address and its identifying details (in particular, IMSI, MSISDN and IMEISV). Details for how this would work are described in the Appendix at the end of this description.

(36) The DM server platform 50 will then check if it has a valid Ks_NAF for that device (UE 20) and if not, start to request one immediately using step 3.

(37) B. Replacing Step 7 (170) by a push message from the Ub proxy.

(38) In particular, this message may be delivered over CoAP (bound to UDP or SMS) towards the GAA (generic authentication architecture) server component of the UE 20, rather than over an HTTP response (bound to TCP). The GAA component may be designed so that instead of initiating message 2 (after receipt of the request 1) it may wait for the push message to arrive in step 7.

(39) Note also that the SMS could act as a triggering SMS, waking up the device from a dormant state.

(40) C. Replacing Steps 3, 6 and 7 (160, 170) by the corresponding steps used within GBA-Push.

(41) In particular, the proxy 110 may act as a push NAF and call the Zpn interface rather than the Ub interface in steps 3 and 6. It may then send a GPI message in step 7.

(42) FIG. 5 shows a revised flow adopting all of optimisations A, B and C. The proxy 110 is collapsed into the NAF 40 and may form part of the DM server 50.

(43) Further optimisations may include:

(44) D. Running steps 10 and 13 over CoAP (120, 180), without acknowledgement messages, or over LWM2M (which comes with explicit acknowledgements for each message).

(45) In particular, the Authorization Digest elements may be mapped into the CoAP or LWM2M payload (since there are no equivalent headers within CoAP). Step 11 involves translating these fields into an HTTP header. The IMPI or TMPI should ideally be omitted from steps 10 and 13 for privacy reasons (the device identity is already known to the Ub proxy 110 and repeating it serves no purpose). However, the HTTP header may need to be constructed as if this field was present (since otherwise the BSF 30 may fail the authentication in step 11).

(46) E. Omitting step 15 from the UE (130, 190) and instead passing the B-TID directly from the Ub proxy to the NAF.

(47) In particular, the proxy 110 may already have visibility of the B-TID from Step 12, so can simply provide this to the NAF 40 straight away to allow look-up of the Ks_NAF (Steps 16 and 17). If the NAF 40 and proxy 110 are collapsed into the same entity, then this may be even easier.

(48) F. Omitting Steps 16 and 17 (140, 200) because GBA Push is used in Step 3, 6 and 7.

(49) In particular, the proxy 110 will already know the Ks_NAF in this case and so can pass this straight to the NAF 40 (or, if the proxy 110 and NAF 40 are collapsed into the same entity, then straight to the DM Server 50, as in Step 18).

(50) These features and further optimisations reduce the number of messages passed in the GBA protocol, hence improving speed and resilience and reducing energy consumption on constrained devices. They protect the BSF 40 and provide privacy protection to the UE 20 but without the complexity of TMPIs (of particular importance where the UE 20 is associated with a human individual). They give essentially the same advantages as GBA-Push while removing a number of significant disadvantages.

(51) FIG. 6 shows a schematic diagram of a system 300 for implementing any of the methods and protocols described with reference to FIGS. 2 to 5. In particular, one or more UEs 20 are in communication with the proxy or proxy server 110. The proxy 110 is in communication with the BSF 30.

(52) FIG. 7 shows a further schematic diagram of the system 300 for implementing any of the described methods and protocols. In this example, the proxy 110 is shown as a separate device to the NAF but may also be collapsed into it or formed from the same hardware. The proxy 110 translates the format of any messages between the BSF 30 and UE 20. Therefore, the UE 20 can send and receive messages in a different (or usually more basic) form than can be understood by the BSF 30. For example, the BSF 30 uses or requires http but such functionality is not available to the UE 20. Therefore, the proxy 110 translates to and from http. Similarly, the BSF 30 does not need to be updated, changed or configured to interpret or produce messages or communications in this format. The proxy also improves security as UE communications can be terminated at the proxy 110 rather than at the BSF 30.

(53) As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims.

(54) For example, standardisation of some of the key concepts (e.g. hybridising regular GBA with GBA Push) may be possible. One or more proxies or proxy servers 110 may be used for load balancing or other purposes.

(55) Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

(56) APPENDIX

(57) Introduction

(58) This is a document describing mechanisms that can be used to communicate information about global data server platform (GDSP) SIM equipped devices to a Device Management platform in a device independent fashion.

(59) Background

(60) When a device equipped with a GDSP SIM establishes an APN connection to a server endpoint, the server endpoint has very little information about the connecting client device. In order to service incoming connections the DM server platform needs to identify the specific device that is connecting to the DM platform. This can be achieved in a number of ways.

(61) Using Minimum Information

(62) A connection from an unknown appliance will have a minimal set of information:

(63) 1) Source and Destination IP addressThe source address will be defined at customer/SIM level and may use a dynamic or static allocation, with public or private addressing.

(64) 2) Port

(65) 3) ProtocolUDP/TCP

(66) GGSN Enhanced

(67) This solution uses the GGSN to supply additional information to the APN's server end point (in this case the DM platform).

(68) When the GGSN creates a PDP context from a client device to a server endpoint, it first authenticates the connecting client with the GDSP Radius servers to authenticate the client and to acquire an ip address for the connecting device.

(69) The ip address is assigned to the PDP device context for the connecting client and communications can commence between client and server in the normal way.

(70) The GGSN enhancement would be to forward a Radius Accounting start request record to the DM server platform before the client establishes the connection to the DM Server. This start record can be populated with MSISDN of connecting device+other data fields. When the client device connection to the DM server is established the DM server will have already been supplied with the Radius Accounting Start Record for the connecting device and using the contents of the Start Record will be able to establish the type and identity of the connecting client device. Using this information the DM server can infer the applications protocol to use for the device (LWM2M, TR69 etc.) and other device specific details (security credentials, bandwidth caps etc.)

(71) The GGSN will authenticate connecting devices using the Radius AAA servers (in the normal way) and once the authentication has been completed, the GGSN will acquire the IMEISV, IMSI and MSISDN for the connecting device from the GDSP HLR. This information will be placed in a Radius Start Accounting Request packet. This AAA Start Accounting Request placket will be sent to the DM platform over a control plane link. At this point the DM platform will be aware that a device is about to connect over the Gi interface, with an IP address, and most importantly the DM Platform will already know the IMEISV, MSISDN+IMSI for the device using that IP address. The DM platform will push this information into a small circular buffer (ie 1000 entries). Milliseconds later a client connection will come into the DM platform with an IP address (it could be using any Layer 3 protocol UDP, TCP, RTCP etc.). The DM platform will do a lookup on the circular buffer and locate the IMEISV, MSISDN+IMSI for this device connecting on this IP address. (There is no need to remove the device information from circular buffer as it will be naturally rotated out by subsequent connections.)