U.S. patent application number 15/021876 was filed with the patent office on 2016-08-04 for communicating with a machine to machine device.
The applicant listed for this patent is VODAFONE IP LICENSING LIMITED. Invention is credited to Nick BONE.
Application Number | 20160226828 15/021876 |
Document ID | / |
Family ID | 51214488 |
Filed Date | 2016-08-04 |
United States Patent
Application |
20160226828 |
Kind Code |
A1 |
BONE; Nick |
August 4, 2016 |
COMMUNICATING WITH A MACHINE TO MACHINE DEVICE
Abstract
The present disclosure provides a wireless communication module
for use in a machine to machine, M2M, the M2M device also
comprising an integrated circuit card. In an alternative aspect,
present disclosure also provides an integrated circuit card for use
in a machine to machine device. The wireless communication module
of the first aspect and the integrated circuit card of the
alternative aspect are each configured for using at least part of a
first data object to obtain a second data object from the
integrated circuit card. The second data object is derived from the
existing shared secret, is suitable for deriving security
information and is suitable for use in establishing secure
communication between the M2M device and a network application
function, NAF.
Inventors: |
BONE; Nick; (Newbury,
Berkshire, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
VODAFONE IP LICENSING LIMITED |
Newbury, Berkshire |
|
GB |
|
|
Family ID: |
51214488 |
Appl. No.: |
15/021876 |
Filed: |
September 12, 2014 |
PCT Filed: |
September 12, 2014 |
PCT NO: |
PCT/GB2014/052772 |
371 Date: |
March 14, 2016 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04B 1/3816 20130101;
H04W 4/50 20180201; H04L 63/0869 20130101; G06F 21/606 20130101;
Y02D 30/70 20200801; H04L 63/061 20130101; H04W 4/12 20130101; H04W
12/04 20130101; H04L 63/04 20130101; H04W 12/04031 20190101; H04L
63/0823 20130101; H04L 63/166 20130101; H04W 80/06 20130101; H04L
63/029 20130101; H04L 63/08 20130101; H04L 67/42 20130101; H04W
28/08 20130101; H04L 63/062 20130101; H04L 67/125 20130101; H04W
12/02 20130101; H04W 52/0229 20130101; H04W 4/70 20180201; G06F
13/4027 20130101; H04W 12/0027 20190101; H04W 88/02 20130101; H04L
9/0861 20130101; H04L 63/20 20130101; H04W 4/14 20130101; H04W
88/06 20130101; Y02D 10/00 20180101; G06F 21/71 20130101; H04L
63/0838 20130101; H04L 63/0876 20130101; H04L 63/10 20130101; G06F
9/4401 20130101; G06F 13/28 20130101; G06F 13/1689 20130101; H04L
2463/061 20130101; H04L 63/0428 20130101; H04L 63/0442 20130101;
H04L 67/1095 20130101; H04W 8/04 20130101; H04W 12/06 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; G06F 21/60 20060101 G06F021/60; H04W 4/00 20060101
H04W004/00 |
Foreign Application Data
Date |
Code |
Application Number |
Sep 13, 2013 |
GB |
1316370.4 |
Oct 16, 2013 |
GB |
1318339.7 |
May 30, 2014 |
GB |
1409643.2 |
Claims
1. A wireless communication module for use in a machine to machine,
M2M, device comprising an integrated circuit card comprising an
existing shared secret that is shared between a network data store
and the M2M device, wherein the wireless communication module is
suitable for coupling to the integrated circuit card and wherein
the wireless communication module comprises: a security module
implemented in the wireless communication module, the security
module being configured to: receive a first data object; and use at
least part of the first data object to obtain a second data object
from the integrated circuit card; wherein the second data object is
derived from the existing shared secret; and wherein the second
data object is suitable for deriving security information; and
wherein the security information is suitable for use in
establishing secure communication between the M2M device and a
network application function, NAF.
2. The wireless communication module of claim 1, wherein the
security module is configured to receive from an application on the
M2M device an identifier of the NAF.
3. The wireless communication module of claim 2, wherein the
security module is configured to receive from the application on
the M2M device the identifier of the NAF as a parameter to a
command.
4. The wireless communication module of claim 3, wherein the
command is an AT command.
5. The wireless communication module of any of claims 2 to 4,
wherein the security module is configured to use at least the
identifier of the NAF and at least part of the second data object
to derive the security information and return the security
information to the application.
6. The wireless communication module of any preceding claim,
wherein the security module is configured to receive the first data
object via an interface with a bootstrapping server function,
BSF.
7. The wireless communication module of any one of claims 2 to 5,
wherein the security module is configured to receive the first data
object from the application on the M2M device.
8. The wireless communication module of any one of claims 1 to 5,
wherein the security module is configured to receive the first data
object from a further application on the M2M device.
9. The wireless communication module of either claim 7 or claim 8,
wherein the first data object is at least part of a push
information object.
10. The wireless communication module of any preceding claim,
wherein the wireless communication module comprises a modem or a
baseband processor.
11. A machine to machine, M2M, device for secure communication with
a network application function, NAF, the M2M device comprising: an
integrated circuit card comprising an existing shared secret that
is shared between a network data store and the M2M device; and the
wireless communication module of any preceding claim, wherein the
wireless communication module is coupled to the integrated circuit
card.
12. The M2M device of claim 11, further comprising an application
coupled to the security module, wherein the application is
configured to provide an identifier of the NAF to the security
module.
13. The M2M device of claim 12, wherein the security module is
further configured to use at least the identifier of the NAF and at
least part of the second data object to derive the security
information and return the security information to the
application.
14. The M2M device of either claim 12 or claim 13, wherein the
application is further configured to provide the first data object
to the security module.
15. The M2M device of either claim 12 or claim 13, further
comprising a further application coupled to the security module,
wherein the further application is configured to provide the first
data object to the security module.
16. The M2M device of either claim 14 or claim 15, wherein the
first data object is at least part of a push information
object.
17. An integrated circuit card for use in a machine to machine,
M2M, device, wherein the integrated circuit card comprises: an
integrated circuit card application; an existing shared secret that
is shared between a network data store and the M2M device, wherein
the existing shared secret is accessible by the integrated circuit
card application; and a security module coupled to the integrated
circuit card application, the security module being configured to:
use at least part of a first data object to obtain a second data
object from the integrated circuit card application; wherein the
second data object is derived from the existing shared secret; and
wherein the second data object is suitable for deriving security
information; and wherein the security information is suitable for
use in establishing secure communication between the M2M device and
a network application function, NAF.
18. The integrated circuit card of claim 17, wherein the security
module is configured to: obtain an identifier of the NAF; and use
at least the identifier of the NAF and the second data object to
derive the security information.
19. The integrated circuit card of claim 18, wherein the security
module is configured to obtain the identifier of the NAF from a
first location on the integrated circuit card.
20. The integrated circuit card of claim 19, wherein the security
module is configured to: monitor the first location on the
integrated circuit card; and obtain the identifier of the NAF when
a change to the first location is identified.
21. The integrated circuit card of any one of claims 17 to 20,
wherein the security module is configured to obtain the first data
object from the first location on the integrated circuit card.
22. The integrated circuit card of claim 21, wherein the security
module is configured to: monitor the first location on the
integrated circuit card; and obtain the first data object when a
change to the first location is identified.
23. The integrated circuit card of any one of claims 17 to 20,
wherein the security module is configured to obtain the first data
object from a second location on the integrated circuit card.
24. The integrated circuit card of claim 23, wherein the security
module is configured to: monitor the second location on the
integrated circuit card; and obtain the first data object when a
change to the second location is identified.
25. The integrated circuit card of any one of claims 17 to 24,
wherein the security module is configured to: write the security
information to a third location on the integrated circuit card.
26. The integrated circuit card of claim 25, wherein the security
module is configured to: use at least part of the first data object
to obtain a verification data object from the integrated circuit
card application; and write the verification data object to the
third location on the integrated circuit card.
27. The integrated circuit card of any one of claims 17 to 25,
wherein the security module is further configured to: use at least
part of the first data object to obtain a verification data object
from the integrated circuit card application; and write the
verification data object to a fourth location on the integrated
circuit card.
28. The integrated circuit card of any one of claims 19 to 27,
wherein: the first location is part of a phone book or part of a
store of SMS messages or part of a file buffer; the second location
is part of the phone book or part of the store of SMS messages or
part of a file buffer; the third location is part of the phone book
or part of the store of SMS messages or part of a file buffer; and
the fourth location is part of the phone book or part of the store
of SMS messages or part of a file buffer.
29. A machine to machine, M2M, device for secure communication with
a network application function, NAF, the M2M device comprising: the
integrated circuit card of any one of claims 17 to 28.
30. The M2M device of claim 29 further comprising: an application
that is coupled to the integrated circuit card and is configured
to: write an identifier of the NAF to a first location on the
integrated circuit card.
31. The M2M device of claim 30, wherein the application is
configured to write the identifier of the NAF to the first location
on the integrated circuit card using a command.
32. The M2M device of claim 31, wherein the command is an AT
command.
33. The M2M device of any of claims 30 to 32, wherein the
application is configured to obtain the security information from a
third location on the integrated circuit card.
34. The M2M device of claim 33, wherein the application is
configured to obtain the security information from the third
location using a command.
35. The M2M device of either claim 33 or claim 34, wherein the
application is configured to: monitor the third location on the
integrated circuit card; and obtain the security information when a
change to the third location is identified.
36. The M2M device any one claims 30 to 35, wherein the application
is further configured to write the first data object to the first
location on the integrated circuit card.
37. The M2M device of any of claims 30 to 36, wherein the
application is further configured to obtain a verification data
object from the third location on the integrated circuit card, or
from a fourth location on the integrated circuit card.
38. The M2M device of any one of claims 30 to 35, further
comprising a further application configured to write the first data
object to a second location on the integrated circuit card.
39. The M2M device of claim 38, wherein the further application is
further configured to obtain a verification data object from the
third location on the integrated circuit card, or from a fourth
location on the integrated circuit card.
40. The M2M device of any one of claims 11 to 16 or 30 to 39,
wherein the application and/or the further application is a device
management client.
41. The M2M device of any one of claims 11 to 16 or 30 to 39,
further comprising a device management client, wherein the device
management client comprises the application and/or the further
application.
42. The M2M device of any one of claims 11 to 16 or 30 to 39,
further comprising a device management client, wherein the
application and/or the further application is configured to operate
as a proxy to the device management client.
43. The M2M device of any one of claims 11 to 16 or 30 to 42,
wherein the application and/or the further application is
configured to operate as a proxy to the security module.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to an integrated circuit card
and wireless communications module that are each suitable for use
in a machine to machine device.
BACKGROUND OF THE INVENTION
[0002] Machine to Machine (M2M) devices are often numerous,
hard-to-reach, and have constrained capabilities (owing to low
cost, small size, low processing power or limited battery life).
All of this makes their management, often remote, very complicated.
Moreover, M2M devices often need to be managed in a secure manner.
For example, they may contain information that is commercially
sensitive and/or confidential for the one or more entities that
manage and/or own said devices. There is a need to remotely manage
them in a secure way, while respecting these constraints.
[0003] The M2M device needs to be able to contact a device
management (DM) server in a secure manner. Whilst at the time of
manufacture the device may be pre-provisioned with the necessary
addresses and URLs to locate this DM server, this requires device
suppliers to have knowledge about the device's end users.
Furthermore, should the addresses or locations of the DM server
change then the M2M devices will require updating to prevent
communications from becoming lost or misdirected.
[0004] Therefore, there is required a system and method that allows
the M2M devices to communicate more reliably and more securely.
[0005] In the 3GPP generic bootstrapping architecture (GBA), the
M2M device may obtain data from a bootstrapping server function
(BSF) so that a shared secret can be established between the M2M
device and a network application function (NAF) with which the M2M
device is in communication. The shared secret may then be used by
the M2M device and the NAF to establish secure communication.
[0006] However, in order to establish the shared secret, sensitive
functions on the Universal Integrated Circuit Card (UICC) must be
accessed (for example, the USIM or SIM application must be
accessed). It can be very difficult to access sensitive functions
on the UICC as it is important that security of the UICC is
maintained in order to prevent fraudulent parties from
impersonating the M2M device. Therefore, there is a need to
identify a configuration of components on the M2M device that
enables the necessary access to the UICC functions whilst still
maintaining the security of the UICC.
Details of 3GPP Standards and Technologies Used to Implement
Aspects of the Method and System
[0007] One of these architectures of 3GPP is a Generic
Authentication Architecture (GAA), which is a complex of standards
which is described, for example, in 3GPP TS 33.919 (entitled "3G
Security; Generic Authentication Architecture (GAA); System
description", currently it may be retrieved at
http://www.3gpp.org/ftp/Specs/html-info/33919.htm).
[0008] Generic Bootstrapping Architecture (GBA) is a 3GPP standard
defined in 3GPP TS 33.220 (entitled "Generic Authentication
Architecture (GAA); Generic Bootstrapping Architecture (GBA)", it
could be currently retrieved at
http://www.3gpp.org/ftp/specs/html-info/33220.htm). GBA is part of
the complex of standards called GAA (see above).
[0009] GBA is a standard which enables a shared secret to be
derived (bootstrapped) from the existing security association
between a mobile network and a SIM card. This involves a network
element called a Bootstrapping Server Function (BSF). In other
words, GBA leverages the security of a SIM card (UICC) to
authenticate mobile equipment, and then derive key material for
general-purpose applications.
[0010] GBA may be advantageously used to provide high-security to
the communication between a client and the server, thus allowing
remotely managing, controlling and, in general, communicating with
a device in a high security manner. In particular, GBA (or a
GBA-like architecture) is used for enabling a secure communication
with the device (which, according to an aspect of the present
disclosure, may be an M2M device), said communication being between
a server and a client, the client being associated with the device,
and wherein this communication is done for managing the device
and/or services provided by (or via) the device, thus enabling a
secure management of that device and/or the services provided by
(or via) the device. In this way, the device and/or the services
provided by (or via) the device can be safely, securely and
efficiently managed in a remote manner via a remote server.
[0011] GBA has been developed mainly for securing mobile broadcast
(e.g. pay TV and equivalents). Indeed, standards for Multimedia
Broadcast Multicast Service (MBMS) rely on GBA. Similarly, Open
Mobile Alliance (OMA) Mobile Broadcast Services Enabler Suite
(BOAST) smartcard profile relies on GBA. To date, most of the
limited number of deployments of GBA in the world has been for
mobile broadcast. GBA has also been standardised as an optional
feature in conjunction with presence services, and within
miscellaneous "federated identity" services (e.g. Liberty Alliance,
OpenID). In general, it is understood that GBA has been designed
for use with mobile devices, such as mobile phones, laptop,
computers, and many of the designed features have been provisioned
with this in mind.
[0012] A variant of GBA, called "GBA Push", has been proposed for
securing a message between a client and a DM server in the context
of OMA Device Management Security. The OMA Device Management is
specifically designed for management of mobile devices such as
mobile phones, tablet, computers, etc.
[0013] A different recent standard document (TS 102 690) merely
mentions, in the context of M2M communications, the use of a
standard GBA to secure communications between a device/gateway
service layer and a network service layer.
[0014] There are some alternatives for identifying/authenticating a
mobile user/device to a service. All of these alternatives are
simpler than using GBA. For example, mobile operators and service
providers can use WAP header enrichment.
[0015] Alternatively, the service provider can request the user to
enter their phone number, send an SMS one-time password to that
phone number, and ask the user to read the SMS and enter the
password. These alternatives all work well with mobile devices and
operators already, so service providers use them, although they are
not as secure as GBA.
[0016] Additionally, many service providers prefer to offer
services to a huge range of mobile devices, many of which do not
contain a SIM card (e.g. PCs, laptops, Wi-fi-only tablets etc.).
Since GBA relies on a SIM card/UICC in order to work, there has
been no interest in using it.
[0017] Strong security is not possible with current alternatives
such as a user-entered PIN or a bootstrapping message delivered by
an SMS. These alternatives would either not be feasible or they
would not provide the required level of security. First, there
might not be a user around to enter a PIN (as most M2M devices
operate independently from human intervention). Second, the service
provider may be likely to want strong security (e.g. because M2M
devices may include critical infrastructure), whereas PIN-based
bootstrapping has weaker security. Third, if a PIN or SMS-based
bootstrapping goes wrong (server connects to wrong client, client
connects to wrong server, or there is a Man-In-The-Middle), then
the user is likely to notice, complain and get it fixed, whereas an
M2M device is unlikely to notice and complain, so may be
permanently compromised. Neither is particularly practical by way
of existing methods. For example, the OMA Device Management uses
GBA Push for securing a message between a client and a DM server,
and there is no explanation of how a similar architecture could be
used or even modified for managing the device. Moreover, as
mentioned above, the OMA Device Management is not compatible for
use with an M2M device, as discussed above. This is particularly
true for low cost, simple M2M devices, such as simple sensors,
switches, low cost trackers etc. Further, the standard document
mentioned above uses a standard GBA to secure communications
between a device/gateway service layer and a network service layer.
Thus, the communication is not used for device/service
management-related communications, and it is not clear, based on
the observations made above, how a similar architecture could be
used or even modified for managing the device from the server.
Moreover, for the reasons mentioned above, the OMA Device
Management and the standard document are incompatible, and a
combination of the GBA Push for OMA Device Management with the
standard document is not feasible, as it would result in the wrong
device management protocol (i.e. one that is not suitable for M2M
devices, particularly simple M2M devices), and some very laborious
effort to make the two compatible and delete the elements which are
redundant.
[0018] The OMA has defined a lightweight protocol for managing (as
well as interacting with) M2M devices and managing services
provided by M2M devices (e.g. remote control of attached sensors or
machines). This protocol is called LWM2M, which is described in
detail at
http://technical.openmobilealliance.org/Technical/release_program/lightwe-
ightM2M_v1_0.a spx
[0019] This protocol runs over the CoAP protocol (analogous to
http)--more specifically CoAP over DTLS (coaps) which is analogous
to http over TLS (https). However, coaps requires a secure
association to be provisioned between a device and a network server
(DM Server) while providing no strong means to provision such an
association from scratch.
[0020] A security aspect of OMA LWM2M is defined in Lightweight
Machine to Machine Technical Specification Candidate Version 1.0-10
Dec. 2013 (OMA-TS-LightweightM2M-V1_0-20131210-C).
[0021] In addition, there exists two protocols, the first one
called DTLS defined in RFC 6347 (entitled "Datagram Transport Layer
Security Version 1.2"; it could be currently retrieved at
http://tools.ietf.org/html/rfc6347); the second one called CoAP
defined in draft-ietf-core-coap-18 (entitled "Constrained
Application Protocol (CoAP)"; it could be currently retrieved at
http://datatracker.ietf.org/doc/draft-ietf-core-coap/). Both
protocols are currently used in LWM2M. CoAP is still only an IETF
draft (not a full RFC), and DTLS version 1.2 is also comparatively
new (January 2012): versions of TLS have often existed as RFCs for
several years before receiving widespread adoption.
[0022] The User Datagram Protocol (UDP) channel security for [COAP]
is defined by the Datagram Transport Layer Security (DTLS)
[RFC6347], which is the equivalent of TLS v1.2 [RFC5246] for HTTP
and utilizes a subset of the Cipher Suites defined in TLS. (Refers
to TLS Cipher Suite registry
http://www.iana.org/assignments/tls-parameters/tls-parameters.xml)
The DTLS binding for CoAP is defined in Section 9 of [CoAP]. DTLS
is a long-lived session based security solution for UDP. It
provides a secure handshake with session key generation, mutual
authentication, data integrity and confidentiality.
[0023] The keying material used to secure the exchange of
information within a DTLS session may be obtained using one of the
bootstrap modes defined in Section 5.1.2 Bootstrap Modes of OMA
LWM2M. The formats of the keying material carried in the LWM2M
Security Object Instances are defined in Appendix E.1.1.
[0024] There also exists an authentication protocol HTTP Digest
authentication, which is defined in RFC 3310 (entitled "Hypertext
Transfer protocol (HTTP) Digest Authentication using Authentication
and Key Agreement (AKA)", it can currently be retrieved at
http://www.ietf.org/rfc/rfc3310.txt).
[0025] The GAA cluster of specifications TS 33.222 (entitled
"Generic Authentication Architecture (GAA); Access to network
application functions using Hypertext Transfer Protocol over
Transport Layer Security (HTTPS)") defines a general approach for
pre-shared key TLS (TLS-PSK, RFC 4279). This can currently be
retrieved at http://www.3gpp.org/ftp/Specs/html-info/33222.htm).
For example, see especially Section 5.4.
[0026] In particular, with reference to GBA, 3GPP Specification TS
33.220 defines the components and interfaces that are shown in FIG.
1. These are further described as:
[0027] NAF 122, the "Network Application Function" is a server-side
component of an application that will be secured using GBA.
[0028] BSF, "Bootstrapping Server Function", 130 is a server-side
component, which obtains authentication vectors from the HLR/HSS
140, and sends a challenge to the mobile device, "UE", 110 during
the GBA protocol. On successful authentication, it derives the
shared secret.
[0029] HLR/HSS 140, the "Home Location Register" or "Home
Subscriber System", is the existing 3GPP system which stores
subscription details and credentials (the K and IMSI) for each SIM
card (UICC) issued by a mobile operator. It may be "GBA-aware" (so
that it stores details for a GBA user subscription) or may be a
legacy component.
[0030] UE, the "User Equipment", 110 is a mobile device containing
a SIM card (UICC). The UE 110 supports a client application which
communicates with the NAF 122, as well as a service which
interfaces to the UICC, communicates with the BSF 130, and derives
the shared secret before passing it to the client application. This
service is (somewhat confusingly) called a "GAA Server" in TR
33.905 (entitled "Recommendations for Trusted Open Platforms", it
can currently be retrieved at
http://www.3gpp.org/ftp/specs/htmlinfo/33905.htm).
[0031] Ua 150 is the interface between the Mobile Device (UE) 110
and the Network Application Function (NAF) 120.
[0032] Ub 160 is the interface between the Mobile Device (UE) 110
and the Bootstrapping Server Function (BSF) 130. This is specified
in detail in TS 24.109 (entitled "Bootstrapping interface (Ub) 160
and network application function interface (Ua) 150; Protocol
details", it can currently be retrieved at
http://www.3gpp.org/ftp/Specs/html-info/24109.htm).
[0033] Zh/Zh' 180 is the interface between the BSF 130 and the HSS
or HLR 140. The Zh 180 interface is used with an HSS 140 that is
"GBA Aware". The Zh' 180 interface is used with a legacy HLR or HSS
140. The Zh and Zh' 180 interfaces are specified in detail in TS
29.109 (entitled "Generic Authentication Architecture (GAA); Zh and
Zn Interfaces based on Diameter protocol; Stage 3", it can
currently be retrieved at
http://www.3gpp.org/ftp/Specs/html-info/29109.htm) and TS 29.229
(entitled "Cx and Dx interfaces based on the Diameter protocol;
protocol details", it can currently be retrieved at
http://www.3gpp.org/ftp/Specs/html-info/29229.htm).
[0034] Zn 170 is the interface between the NAF 122 and the BSF 130:
this can use either a Web Services protocol (SOAP over http) or the
Diameter protocol (RFC 3588). This is specified in detail in TS
29.109 (see above).
[0035] There are a few other components and interfaces defined
within the GAA standards, but these are not described in detail
here.
[0036] There are several different versions of GBA defined in the
standards. The flavours of GBA may include GBA-ME, GBA-U, GBA-SIM
etc. The version called "GBA-ME" may require no special
customizations of the UICC, except that the UICC does contain a 3G
SIM (a USIM). However, other versions may be used. There may be a
need to use the 2G variant of GBA (using a SIM rather than a
USIM).
SUMMARY OF THE INVENTION
[0037] The present disclosure provides a wireless communication
module for use in a machine to machine, M2M, device (for example, a
UE) comprising an integrated circuit card (for example, a UICC,
smartcard etc.) comprising an existing shared secret that is shared
between a network data store and the M2M device, wherein the
wireless communication module is suitable for coupling to the
integrated circuit card and wherein the wireless communication
module comprises: a security module implemented in the wireless
communication module, the security module being configured to:
receive a first data object; and use at least part of the first
data object to obtain a second data object from the integrated
circuit card; wherein the second data object is derived from the
existing shared secret; and wherein the second data object is
suitable for deriving security information; and wherein the
security information is suitable for use in establishing secure
communication between the M2M device and a network application
function, NAF.
[0038] The first data object may comprise, for example, data that
would enable the M2M device (for example, a user equipment, UE) to
derive a shared secret (the security information) that is shared
with the NAF. This data may comprise a RAND (and optionally also an
AUTN), which the M2M device can use to obtain the second data
object in order to derive the security information, which may be a
new shared secret, such as a Ks_NAF.
[0039] The first data object may additionally also comprise, for
example, data that would enable the M2M device to authenticate a
bootstrapping server BSF. For example, it may comprise an AUTN.
[0040] The first data object is not limited to comprising only such
material and may comprise one or more additional items, for example
Ks-input, which is identified in Annex I of TS 33.220 for 2G GBA
(with SIM).
[0041] The second data object is derived from an existing shared
secret, wherein the existing shared secret may be shared between a
network data store and the M2M device. For example, the existing
shared secret may be a K that is securely stored on a UICC of the
M2M device and on a network data store in an HLR/HSS, and the
second data object may comprise a CK and IK, or a Ks, that are
derived from the K. Alternatively, the existing shared secret may
be a Ki and the second data object may comprise Kc.
[0042] The second data object may additionally also comprise, for
example, a verification data object that may enable a bootstrapping
server (BSF) to authenticate the M2M device. For example, it may
comprise a RES or SRES.
[0043] The second data object is not limited to comprising only
such material and may comprise one or more additional items.
[0044] The security module may be any part of the wireless
communication module that can interface with the integrated circuit
card and perform the functionality described above. For example,
the security module may be a GAA server, or it may be only the part
of the GAA server that securely interfaces with the integrated
circuit card. It may also terminate one or more communications
interfaces, for example Ub, and/or it may be configured to receive
data from one or more applications implemented on the M2M
device.
[0045] By implementing the security module on the wireless
communication module, secure, sensitive parts of the integrated
circuit card may be accessed without exposing those parts to other
parts of the M2M device, for example the application logic.
Therefore, the security of the integrated circuit card can be
maintained and the security information that is suitable for use in
establishing secure communication between the M2M device and the
NAF may still be derived (for example, by carrying out a generic
bootstrapping architecture, GBA, process in order to obtain a new
shared secret). Consequently, fraudulent parties may be prevented
from impersonating the M2M device, which can protect the cellular
network from fraudulent activities.
[0046] The wireless communication module may be configured to
receive from an application on the M2M device an identifier of the
NAF (for example, NAF_Id). The application may be, for example, a
DM client on the M2M device, or any other
application/module/software on the M2M device.
[0047] The identifier of the NAF may be received from the
application on the M2M device as a parameter to a command. The
command may be any suitable form of command for passing data to the
security module, for example it may be an AT command. Using an AT
command may be particularly advantageous since the wireless
communications module may already have functionality to support AT
commands and therefore require minimal modification in order to
implement the security module on the wireless communication
module.
[0048] The security module may be configured to use at least the
identifier of the NAF and at least part of the second data object
(for example, CK and IK, or Ks, or Kc) to derive the security
information (for example, Ks_NAF) and return the security
information to the application. Optionally, the security module may
further use at least part of the first data object (for example,
RAND) to derive the security information.
[0049] Optionally, the security information may be returned to the
application as an output to the AT command that passed the
identifier of the NAF to the security module.
[0050] The security module may be configured to receive the first
data object via an interface (for example, Ub) with a bootstrapping
server function, BSF. The interface may be a direct interface
between the security module and the BSF, or it may be tunneled via
a different interface to the M2M device, or there may be one or
more intermediate elements between the security module and the BSF.
The wireless communication module may therefore be configured to
terminate at least one interface, for example Ub, which may utilise
any suitable protocol, for example http. In this instance, the
security module may be configured to use at least part of the
second data object (for example RES or SRES) to protect
communication with the BSF via the interface.
[0051] The security module may alternatively be configured to
receive the first data object from the application on the M2M
device. For example, the application may terminate the Ub
interface, or an interface over which Ub is tunneled, or a GBA push
interface Upa, or an interface over which Upa is tunneled. The
application may therefore be configured to terminate the at least
one interface, ensuring that such interface functionality, such as
IP and http communications functionally, may be kept away from the
security module and wireless communication module. Thus, insecure
interface termination elements may be kept away from the integrated
circuit card, thereby even further improving security and further
simplifying the configuration of the wireless communication
module.
[0052] The wireless communication module may be configured to
receive the first data object from a further application on the M2M
device. The further application may be any
application/module/software on the M2M device. For example `the
application` may be a device management (DM) client and the
`further application` may be an interface application implemented
on the application processor of the M2M device.
[0053] The first data object may be at least part of a push
information object (for example, a GPI). Thus, the wireless
communication module may be used to implement a GBA-push
process.
[0054] The wireless communication module may comprise a modem or a
baseband processor.
[0055] The present disclosure also provides a machine to machine,
M2M, device (for example, a UE) for secure communication with a
network application function, NAF, the M2M device comprising: an
integrated circuit card (for example, a UICC) comprising an
existing shared secret that is shared between a network data store
and the M2M device; and the wireless communication module described
above, wherein the wireless communication module is coupled to the
integrated circuit card.
[0056] Thus, the security module on the wireless communication
module may interface with the secure parts of the integrated
circuit card, thereby enabling the integrated circuit card to be
used in the derivation of security information whilst still
maintaining the security of the integrated circuit card.
[0057] The M2M device may further comprise an application coupled
to the security module, wherein the application is configured to
provide an identifier of the NAF (for example, NAF_Id) to the
security module. The application may be, for example, a device
management (DM) client, or any other application/software/module on
the M2M device. The identifier of the NAF may be provided by the
application to the security module by any suitable means, for
example using a command such as an AT command.
[0058] The security module may be further configured to use at
least the identifier of the NAF and at least part of the second
data object (for example, the CK and IK, or the Ks, or the Kc) to
derive the security information and return the security information
to the application. The security module may additionally use at
least part of the first data object, for example the RAND, to
derive the security information.
[0059] The application may be further configured to provide the
first data object to the security module. For example, the
application may use any suitable command, such as an AT command, in
order to provide the first data object.
[0060] Alternatively, the M2M device may comprise a further
application coupled to the security module, wherein the further
application is configured to provide the first data object to the
security module. The further application may be any
application/module/software on the M2M device. For example `the
application` may be a device management (DM) client and the
`further application` may be an interface application implemented
on the application processor of the M2M device.
[0061] The security module may also be configured to obtain a
verification data object (for example, RES or SRES) and the
application and/or further application (or any other application on
the M2M device) may be configured to receive the verification data
object, wherein the verification data object may be used for
verification of the M2M device (for example, by being used to
protect communication between the application or further
application and a BSF). Alternatively, the security module may use
the verification data object via an interface that it terminates,
for example to protect communication with a BSF.
[0062] The first data object may be at least part of a push
information object, for example a GPI response. Thus, the M2M
device may be used as part of a GBA-push process.
[0063] The present disclosure also provides an integrated circuit
card (for example, a UICC, smart card, chip card, subscriber
identity module, SIM, IP multimedia services identity module, ISIM,
etc.) for use in a machine to machine, M2M, device (for example, a
UE), wherein the integrated circuit card comprises: an integrated
circuit card application; an existing shared secret that is shared
between a network data store and the M2M device, wherein the
existing shared secret is accessible by the integrated circuit card
application; and a security module coupled to the integrated
circuit card application, the security module being configured to:
use at least part of a first data object to obtain a second data
object from the integrated circuit card application; wherein the
second data object is derived from the existing shared secret; and
wherein the second data object is suitable for deriving security
information; and wherein the security information is suitable for
use in establishing secure communication between the M2M device and
a network application function, NAF.
[0064] The integrated circuit card application may be any
functionality on the integrated circuit card that has access to the
existing shared secret and which may be used to obtain the second
data object. The integrated circuit card application may be, for
example, a USIM application that is configured to run an
Authentication and Key Agreement (AKA) algorithm, as explained in
3GPP TS33.102, or a SIM application.
[0065] The first data object may comprise, for example, data that
would enable the M2M device (for example, a user equipment, UE) to
derive a shared secret (the security information) that can be used
to establish secure communication with the NAF. This data may
comprise a RAND (and optionally also an AUTN), which the M2M device
can use to obtain the second data object in order to derive the
security information, which may be a new shared secret, such as a
Ks_NAF.
[0066] The first data object may additionally also comprise, for
example, data that would enable the M2M device to authenticate a
bootstrapping server BSF. For example, it may comprise an AUTN.
[0067] The first data object is not limited to comprising only such
material and may comprise one or more additional items.
[0068] The second data object is derived from an existing shared
secret, wherein the existing shared secret may be shared between a
network data store and the M2M device. For example, the existing
shared secret may be a K that is securely stored on a UICC of the
M2M device and on a network data store in an HLR/HSS, and the
second data object may comprise a CK and IK, or a Ks, that are
derived from the K. Alternatively, the existing shared secret may
be a Ki and the second data object may comprise Kc.
[0069] The second data object may additionally also comprise, for
example, a verification data object that may enable a bootstrapping
server (BSF) to authenticate the M2M device. For example, it may
comprise a RES or SRES.
[0070] The second data object is not limited to comprising only
such material and may comprise one or more additional items.
[0071] The security module may be any part of the integrated
circuit card that can interface with the integrated circuit card
application and perform the functionality described above. For
example, the security module may be an applet on the integrated
circuit card, the applet functioning as a GAA server, or the part
of the GAA server that interfaces with the secure parts of the
integrated circuit card. It may additionally terminate one or more
communications interfaces, for example Ub, Ua, Upa, and/or it may
be configured to receive data from one or more applications
implemented on the M2M device.
[0072] By implementing the security module on the integrated
circuit card, secure, sensitive parts of the integrated circuit
card may be accessed without exposing those parts of the integrated
circuit card to other parts of the M2M device, for example the
application logic. Therefore, the security of the integrated
circuit card can be maintained and the security information that is
suitable for use in establishing secure communication between the
M2M device and the NAF still be derived (for example, by carrying
out a generic bootstrapping architecture, GBA, process in order to
obtain a new shared secret). Consequently, fraudulent parties may
be prevented from impersonating the M2M device, which can protect
the cellular network from fraudulent activities.
[0073] The security module may be configured to: obtain an
identifier of the NAF (for example, a NAF_Id); and use at least the
identifier of the NAF and the second data object (for example, the
CK and IK) to derive the security information (for example, a
Ks_NAF).
[0074] Optionally, the security module may additionally use at
least part of the first data object (for example, the RAND) to
derive the security information.
[0075] The security module may be configured to obtain the
identifier of the NAF by obtaining it from a first location on the
integrated circuit card. For example, the identifier of the NAF may
have been written to a location, such as an input/output buffer or
file etc, on the integrated circuit card and the security module
may read the identifier from that location.
[0076] The security module may be configured to: monitor the first
location on the integrated circuit card; and obtain the identifier
of the NAF when a change to the first location is identified.
[0077] Alternatively, rather than `obtaining` the identifier of the
NAF, the security module may simply receive the identifier of the
NAF. For example, an application on the M2M device may pass the
identifier of the NAF to the security module using, for example,
GBA-U commands (but directed towards the security module, rather
than towards the integrated circuit application which generates the
second data object) or any other suitable
commands/protocols/procedure etc. This may be done without any
action previously having been performed by the security module
(i.e. the security module need not previously have requested the
identifier of the NAF).
[0078] The security module may be configured to obtain the first
data object from the first location on the integrated circuit card.
For example, the first data object may have been written to the
same location on the integrated circuit card as the identifier of
the NAF (either at the same time or at a different time to when the
identifier of the NAF is written to the location) and the security
module may read the first data object from that location.
[0079] The security module may be configured to: monitor the first
location on the integrated circuit card; and obtain the first data
object when a change to the first location is identified.
[0080] Alternatively, rather than `obtaining` the first data
object, the security module may simply receive the first data
object. For example, an application on the M2M device may pass the
first data object to the security module using, for example, GBA-U
commands or any other suitable commands/protocols/procedure etc.
Both the identifier of the NAF and the first data object may be
`received` by the security module in this way, or just one of the
identifier of the NAF and the first data object may be received in
this way with the other being `obtained` in the way described
above, or they may both be `obtained` in the way described above.
This may be done without any action previously having been
performed by the security module (i.e. the security module need not
previously have requested either the identifier of the NAF or the
first data object).
[0081] The security module may be configured to obtain the first
data object from a second location on the integrated circuit card.
For example, the identifier of the NAF may be obtained from a first
location on the integrated circuit card, where it has been written,
and the first data object may be obtained from a different, second
location on the integrated circuit card, where it has been
written.
[0082] The security module may be configured to: monitor the second
location on the integrated circuit card; and obtain the first data
object when a change to the second location is identified.
[0083] The security module may be configured to write the security
information to a third location on the integrated circuit card. In
this way, it may be possible for an application on the M2M device
subsequently to read the security information from the third
location, such that the application may use the security
information to establish secure communication with the NAF.
[0084] The security module may be further configured to: use at
least part of the first data object (for example, RAND and/or AUTN)
to obtain a verification data object (for example, RES or SRES)
from the integrated circuit card application; and write the
verification data object to the third location on the integrated
circuit card. The verification data object may be written to the
third location either at the same time or at a different time to
when the security information is written to the third location.
[0085] Alternatively, the security module may be further configured
to: use at least part of the first data object (for example, the
RAND and/or AUTN) to obtain a verification data object (for
example, RES or SRES) from the integrated circuit card application;
and write the verification data object to a fourth location on the
integrated circuit card. For example, the security information may
be written to a third location on the integrated circuit card and
the verification data object may be written to a different, fourth
location on the integrated circuit card.
[0086] In this way, it may be possible for the verification data
object to be used to verify the M2M device e.g. verify the identity
of the device or an application on the device. For example, a
bootstrapping server (BSF) may read the verification data object
from the third or fourth location and use it to verify the M2M
device, or an application (for example an interface application, or
a DM client or any other application) on the M2M device may read
the verification data object from the third or fourth location,
such that it can be used to protect communication with a device
that can perform verification (for example, a BSF or any other
suitable server/component/function).
[0087] Alternatively, rather than writing the security information
and/or verification data object to a location(s) on the integrated
circuit card, the security module may output the security
information and/or verification data to an application on the M2M
device (or to a device, for example a BSF). For example, GBA-U
commands or any other suitable command/protocol/procedure may be
used to output one or both of the security information and
verification data object from the security module.
[0088] The first location may be part of a phone book or part of a
store of SMS messages or part of a file buffer; the second location
is part of the phone book or part of the store of SMS messages or
part of a file buffer; the third location is part of the phone book
or part of the store of SMS messages or part of a file buffer; and
the fourth location is part of the phone book or part of the store
of SMS messages or part of a file buffer.
[0089] Whilst the possibility of four different locations on the
integrated circuit card has been described, it will be appreciated
that only a single location may be used. For example, the first
data object and/or the identifier of the NAF may be written to a
first location and the security information and/or verification
data object may also be written to the first location. Two or more
locations may alternatively be used in a similar way, wherein one
location may be read by the security module to receive input data
and the same location may be used by the security module to write
output data. Furthermore, three or five or more different locations
on the integrated circuit card may be used to carry out the
process(es) of the present disclosure (for example, where multiple
different locations may be available for the first data object
etc).
[0090] The present disclosure also provides a machine to machine,
M2M, device (for example, a UE) for secure communication with a
network application function, NAF, the M2M device comprising the
above disclosed integrated circuit card.
[0091] As explained earlier, the security module may be configured
to terminate one or more interfaces (for example Ub, Upa, Ua etc.)
and/or to interface with one or more applications on the M2M
device.
[0092] The M2M device may further comprise: an application (for
example, a device management client, or any other application) that
is coupled to the integrated circuit card and is configured to:
write an identifier of the NAF to a first location on the
integrated circuit card.
[0093] The application may be configured to write the identifier of
the NAF to the first location on the integrated circuit card using
a command. The command may be any suitable form of command for
passing data to the security module, for example it may be an AT
command.
[0094] Using an AT command may be particularly advantageous since
the M2M device may already have functionality to support AT
commands to communicate with the integrated circuit card (for
example to write data to the phone book or SMS store etc.) and
therefore require minimal modification in order to implement the
security module on the wireless communication module. Existing AT
commands may be repurposed to write the NAF to the first location,
or custom AT commands may be used.
[0095] Alternatively, as explained earlier, the application may be
configured to pass the identifier of the NAF to the security module
by means of any other suitable commands/protocols/procedures, for
example GBA-U commands.
[0096] The application may be configured to obtain the security
information from a third location on the integrated circuit
card.
[0097] The application may be further configured to obtain the
security information from the third location using a command. The
command may be any suitable form of command for passing data to the
security module, for example it may be an AT command.
[0098] The application may be configured to: monitor the third
location on the integrated circuit card; and obtain the security
information when a change to the third location is identified.
[0099] The application may be further configured to write the first
data object to the first location on the integrated circuit card
(i.e. to the same location as the identifier of the NAF). Any
suitable commands/protocols/procedures may be used, for example AT
commands or GBA-U commands etc.
[0100] The application may be further configured to obtain a
verification data object (for example RES or SRES) from the third
location on the integrated circuit card (i.e. the same location as
the security information), or from a fourth location on the
integrated circuit card. Again, any suitable
commands/protocols/procedures may be used, for example AT commands
or GBA-U commands etc.
[0101] The M2M device may further comprise a further application
configured to write the first data object to a second location on
the integrated circuit card. For example, the further application
may be an interface application that is configured to terminate an
interface over which the first data object is transmitted.
[0102] The further application may be further configured to obtain
a verification data object (for example RES or SRES) from the third
location on the integrated circuit card, or from a fourth location
on the integrated circuit card.
[0103] The application disclosed above may be a device management
client, or a plug-in to a device management client, or a proxy to a
device management client. Additionally, or alternatively, the
further application may be a device management client, or a plug-in
to a device management client, or a proxy to a device management
client.
[0104] For example, any of the M2M devices disclosed above may
further comprise a device management client, wherein the device
management client comprises the application (for example, as a
plug-in component) and additionally, or alternatively, the further
application (for example, as a plug-in component). The device
management client may, for example, be implemented on the
application processor of the M2M device, or in any other suitable
location on the M2M device, for example on a wireless
communications module.
[0105] Alternatively, any of the M2M devices disclosed above may
further comprise a device management client, wherein the
application is configured to operate as a proxy to the device
management client. Additionally, or alternatively, the further
application may operate as a proxy to the device management
client.
[0106] The application and/or further application may, for example,
be implemented on the application processor of the M2M device, or
in any other suitable location on the M2M device, for example on a
wireless communications module
[0107] The application and/or further application may, in addition
or as an alternative to any of the above possibilities, be
configured to operate as a proxy to the security module. It may be
configured to terminate one or more interfaces (for example a Ub
interface, Upa interface, Ua interface etc.) and function as an
interface application, or it may be configured to sit between the
security module and an application/module that terminates one or
more interfaces.
[0108] For example, the application may be a DM client or a plug-in
to the DM client, and the further application may be separately
implemented on the application processor as a proxy to the DM
client and/or security module. Or, the application may be a proxy
to the DM client and the further application may be a proxy to the
security module. Or both the application and the further
application may be plug-ins implemented in a DM client. Or, the
further application may not be implemented at all, and the
application may be the DM client, or a plug-in to the DM client, or
a proxy to the DM client and/or a proxy to the security module.
[0109] The methods described above may be implemented as a computer
program comprising program instructions to operate a computer. The
computer program may be stored on a computer-readable medium.
[0110] The computer system may include a processor such as a
central processing unit (CPU). The processor may execute logic in
the form of a software program. The computer system may include a
memory including volatile and non-volatile storage medium. A
computer-readable medium may be included to store the logic or
program instructions. The different parts of the system may be
connected using a network (e.g. wireless networks and wired
networks). The computer system may include one or more interfaces.
The computer system may contain a suitable operation system such as
UNIX, Windows.RTM. or Linux, for example.
[0111] It should be noted that any feature described above may be
used with any particular aspect or embodiment of the invention.
BRIEF DESCRIPTION OF THE FIGURES
[0112] 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:
[0113] FIG. 1 shows a schematic diagram of components and
interfaces with which GBA may be used;
[0114] FIG. 2 shows a schematic diagram of an example of an
architecture that can be used in accordance with the present
invention, in particular when GBA is used;
[0115] FIG. 3 shows an exemplary flow diagram of communications
exchanged within the exemplary architecture of FIG. 2;
[0116] FIG. 4 shows a schematic diagram of an example of an
alternative architecture that can be used in accordance with the
present invention, in particular when generic bootstrapping
architecture (GBA) is used;
[0117] FIG. 5 shows a schematic diagram of an example of an
architecture with example communication exchange steps that can be
used, in particular, with GBA;
[0118] FIG. 6 shows an exemplary flow diagram of communications
exchanged within the exemplary architecture of FIG. 5;
[0119] FIG. 7 shows a schematic diagram of an example alternative
architecture utilising push messages;
[0120] FIG. 8 shows an exemplary flow diagram of communication
exchanged within the exemplary architecture of FIG. 7;
[0121] FIG. 9 shows a schematic diagram of an example architecture
that can be used in accordance with the present invention, wherein
a GAA server 114' is implemented within a wireless communications
module 118 on a UE 110;
[0122] FIG. 10 shows a schematic diagram of an example architecture
that can be used in accordance with the present invention, wherein
a security module 114b is implemented within a wireless
communications module 118 on a UE 110;
[0123] FIG. 11 shows a schematic diagram of a further example
architecture that can be used in accordance with the present
invention, wherein a security module 114b is implemented within a
wireless communications module 118 on a UE 110;
[0124] FIG. 12 shows a schematic diagram of an example architecture
that can be used in accordance with the present invention, wherein
a GAA server 114' is implemented within a UICC 112 on a UE 110;
[0125] FIG. 13 shows a schematic diagram of an example architecture
that can be used in accordance with the present invention, wherein
a security module 114b is implemented within a UICC 112 on a UE
110; and
[0126] FIG. 14 shows a further schematic diagram of an example
architecture that can be used in accordance with the present
invention, wherein a security module 114b is implemented within a
UICC 112 on a UE 110.
[0127] 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
[0128] A device may communicate securely with a server. The device
may be a Machine to Machine (M2M) device, or an equivalent device
(e.g. a device, a generic or specific communication device,
including one or more modules capable of providing M2M
capabilities).
[0129] Aspects of the Generic Authentication Architecture (GAA) and
Generic Bootstrapping Architecture (GBA) are identified in "Details
of 3GPP standards and technologies used to implement aspects of the
method and system" above. In particular, the specific architecture
on which the method and system may be based is GBA.
[0130] Generic Bootstrapping Architecture (GBA) uses existing
security associations between a network (e.g. a mobile network) and
a card (e.g. a SIM card or UICC) to derive a key that can be used
for the secure communication between the client and the server.
Accordingly, if the device is associated with such a card, as well
as with the client, the method can advantageously use the GBA to
derive the security elements (e.g. a shared secret) to enable the
client associated with the device to securely communicate with the
server. Accordingly, the device could be advantageously adapted so
that it is associated with the card and the client and uses GBA to
derive the security elements for secure communication with the
server. Moreover, as GBA is standards-based, the impact of the
required modifications may be relatively limited and the overall
solution would be very attractive (in particular, to M2M
users/owners as well as to network operators and/or service
providers).
[0131] M2M devices are different from the mobile devices that OMA
Device Management was originally designed for (such as mobile
phones, laptops, computers, as explained in "Details of 3GPP
standards and technologies used to implement aspects of the method
and system" above), and use of GBA (in any of its versions) with
M2M is not a straightforward implementation.
[0132] A variant of GBA, called "GBA Push" has been proposed for
securing a message between a client and a DM server in the context
of OMA Device Management Security, and is identified in "Details of
3GPP standards and technologies used to implement aspects of the
method and system" above. It is noted that, although GBA Push and
GBA are related, it is not trivial to use GBA in place of GBA Push
(and vice versa). This is because these two architectures have some
important differences. First, in GBA the device has to contact the
BSF in order to request a RAND and AUTN (and use this to derive a
Ks_local). To the contrary, in GBA Push, the client does not have
to talk to the BSF--it just receives a message prepared by the BSF.
Furthermore, in GBA, there is no need to modify the Ua interface.
In GBA Push, either the Ua interface has to be modified in some way
to carry the push message or a new interface must be added.
Accordingly, GBA Push cannot be used with an arbitrary application
protocol. For GBA Push, the application protocol has to be "GBA
aware" in some sense (e.g. so it can carry the GBA Push Info (GPI)
messages). In GBA, the Ks_local can be used to derive several
different Ks_NAFs (e.g. for different application servers). In GBA
Push, only one NAF can use/rely on the Ks_local. Accordingly, GBA
Push is slightly less efficient than GBA.
[0133] The GBA Push Info is described in 3GPP TS 33.223, Section
5.2.1. The encoding is defined in Section 5.3.5. See in particular
table 5.2.1.1 and FIG. 5.3.5.1 in 3GPP TS 33.223 V12.0.0 (2013-12)
that may be found:
http://www.3gpp.org/ftp/Specs/archive/33_series/33.223/33223-c00.zip
[0134] Moreover, as discussed above, M2M devices are very
constrained in their capabilities (e.g. computation, communication,
life, etc.) and these constraints make their management more
complex and harder to implement in a simple manner. GBA requires a
number of interfaces and components which are hard to implement
with M2M (for examples and description of these interfaces and
components, please refer to the sections below).
[0135] In order to more efficiently and securely manage the device
and/or services provided by (or via) the device, these interfaces
and components need to be modified or otherwise adapted so they can
properly and effectively work with M2M devices.
[0136] For example, carrying the Ub interface (and associated
protocol) over constrained M2M devices is very difficult. For
example, the standard Ub interface uses HTTP and HTTP digest. The
likely rationale for this is that, as mentioned above, GBA was
designed having mobile devices, such as mobile phones, in mind. So,
since all phones use HTTP, and therefore all have an HTTP stack,
then HTTP was the easiest protocol to be used for the Ub interface.
However, this is not true for M2M devices. For example, according
to the Lightweight M2M (LWM2M) protocol (see below for more
details), a protocol called CoAP is used in M2M devices, precisely
because it is a simpler/more efficient alternative to HTTP.
Alternatively, this Ub interface could be tunneled, for example via
another interface (e.g. the Ua), so that the system may be
simplified.
[0137] Additionally, building all the necessary components (e.g.
GAA server, interfaces) into a capacity-constrained M2M device
appears to be very difficult. For example, physical and virtual
space constraints, as well as computational constraints, create
considerable problems for building the necessary components.
Moreover, having one or more interfaces between M2M application(s)
and a card on the device, such as a UICC, is very difficult. This
is due, for example, to the fact that most M2M modems do not
support the required low level interface(s). In general, the
overall integration of the GBA required interfaces and components
with an M2M device appear very difficult. A possible, but not
optimal solution, could be to pre-provision the M2M devices (e.g.
having the M2M devices already designed and/or manufactured with
the required components and interfaces) and the associated elements
required for use of GBA (e.g. the card being capable of interfacing
with the M2M device) so that the GBA could be used. To date, no M2M
device is pre-provisioned with these characteristics.
[0138] In addition, as noted above, GBA is not widely used. There
are other reasons why GBA is not widely used. For example, use of
GBA requires support in the device, in the network (e.g. BSF--see
below) and by individual services (which may be deployed, for
example, by a mobile operator or by other parties). In the
preferred use-case (mobile broadcast) support is also required in
the SIM card (as it uses GBA-U). Accordingly, a lack of
coordination and willingness to act/cooperate between the various
parties involved in this deployment (e.g. device manufacturers,
mobile operators, service providers) has so far blocked
implementation of GBA.
[0139] For all the above reasons, GBA (or a GBA-like architecture,
for example a variant and/or a suitably modified version) may be
used for enabling a secure communication with a device (in
particular, an M2M device). The communication may be between a
server and a client, the client being associated with the device,
and wherein this communication may be done for managing the device
and/or services provided by (or via) the device. This enables a
secure management of that device and/or the services provided by
(or via) the device and creates a new and innovative combination
which produces a synergistic effect and provides many technical
advantages.
[0140] For instance, as already mentioned above, the GBA will
provide a higher and very strong level of security to the
device/service management-related communications with M2M devices,
which is a very critical and important point.
[0141] Another advantage, in addition or combined with the strong
security described above, is in terms of full automation. Moreover,
an M2M service provider does not have the cost/complexity of
setting up their own security solutions, as the solution can be
provided directly by the mobile operator implementing the solution
described in this application. In particular, a service provider
does not have to set up a PKI, issue certificates, pre-load keys to
devices and so on.
[0142] Accordingly, the method may further comprise that the
provision of the secure communication is based on a security
association between a network and a card, the card being associated
with the device. For example, the card may be embedded within the
device (e.g. soldered in the device) or provided to the device by
way of a suitable connection. In general, the card may be
associated in any suitable manner so that there is an association
between the card and the device. The network can be a mobile
network, or any equivalent network, while the card can be a SIM
card, a UICC, or any card associated with the network. The method
may further comprise deriving a shared secret based on the security
association. The method may further comprise providing the client
and the server with the shared secret so as to enable the secure
communication. The server may be a server adapted to manage the
device (e.g. remotely manage the device, send updates, transfer
information to and from the device, control device parameters,
etc.) and to manage services provided by the device (e.g. device is
used to switch on/off and/or dim streetlights). The shared secret
may be a key and/or a similar security arrangement.
[0143] The method may further comprise authentication between the
client and the server. The authentication may be based on the
shared secret. The authentication may be performed via an
authentication component. The authentication may be performed by
means of a first authentication between the client and an
authentication component and of a second authentication between the
server and the authentication component. The client and the server
may be independently authenticated by an authentication component.
As a result of the client and the server being authenticated by the
authentication component, both the client and the server may share
the shared secret. The authentication may be performed by means of
the shared secret. The shared secret may be shared between the
client and the server. Alternatively, the shared secret may be
shared between the client, the server and the authentication
component. The authentication may implicitly result from the
client, the server and the authentication component sharing the
shared secret. The method may further comprise deriving a second
shared secret based on the shared secret, the second shared secret
being shared between the client and the server. This second shared
secret may then be used for the authentication as discussed
above.
[0144] The obtainment of the shared secret at the client may be
based on an identifier associated with a server authentication
component. The shared secret may be obtained at the server from the
authentication component. The obtainment of the shared secret at
the server is obtained based on an identifier associated with the
shared secret. The identifier is generated by the authentication
component. The identifier may be provided to the server by the
client.
[0145] The OMA LWM2M protocol for managing (as well as interacting
with) M2M devices and managing services provided by M2M devices (as
described in "Details of 3GPP standards and technologies used to
implement aspects of the method and system") may be used. However,
other device management protocols may be used or the method and
system may be extended to other M2M services (for example, securing
the delivery of binary SMS).
[0146] GBA could be advantageously used in conjunction with LWM2M
in order, for example, to establish keys for LWM2M, whilst at the
same time LWM2M and the procedures specified therein could be used
to transport and/or carry any message and/or communication which
relates to GBA. For example, this can be done by using specific
tunnels (e.g. Ub) or GBA
[0147] Push Info (GPI) messages. The use of GBA together with LWM2M
creates a new and innovative combination which produces a
synergistic effect and provides many technical advantages. For
example, it allows addressing many more low-end devices, such as
M2M devices. This is due, for example, to the use of a device
management protocol which is properly optimized for M2M, rather
than one repurposed from the consumer space (e.g. OMA DM v1,
TR-069). This optimised protocol can be used to transport GBA
messages--avoiding the need for a separate HTTP stack--and to
manage GBA parameters (identifiers for device and application,
lifetimes, key derivation methods, etc.). Further, when accompanied
by appropriate network systems to provide automated routing and
discovery (e.g. of LWM2M server and BSF), GBA and LWM2M
advantageously combine to eliminate the cost of pre-loading
settings and credentials, so facilitating low cost devices. GBA
with LWM2M securely supports low-cost devices which are unattended
or have no UI, where there is no option for user interaction (such
as entry of PIN), and where there is no user who is able to notice
and recover from authentication failures (spoof server, spoof
client or Man In The Middle), Moreover, GBA works without requiring
any public key or certificate processing on the device. This is
particularly advantageous on simpler devices, as these devices may
have minimal public key support or implementation errors when
handling certificates.
[0148] Accordingly, the shared secret may be used as a key in the
LWM2M standard. Also, the LWM2M standard procedures may be used for
transmission and/or reception of any communication used within the
GBA.
[0149] The shared secret may be used as a key or shared secret
within the DTLS protocol (identified in "Details of 3GPP standards
and technologies used to implement aspects of the method and
system" above), either when the LWM2M is used in conjunction with a
DTLS protocol or when the DTLS is used alone or in conjunction with
one or more other protocols.
[0150] The secure communication may further be a data
communication. The data communication may be an SMS-based
communication. An SMS binding may be used. The data communication
may be a UDP-based communication.
[0151] The method may further comprise encrypting a communication
over the secure data communication. The encryption may be performed
using an Advanced Encryption Standard. The SMS-based communication
may be further secured by use of an Over-The-Air (OTA) protocol,
e.g. a Secured Packet Structure for UICC Applications. This
protocol is defined in ETSI standard 102.225. The OTA protocol may
be arranged to secure the communication with the identification
card associated with the device.
[0152] It has also been noted that the OTA protocol can be used
advantageously in conjunction with the LWM2M standard, in which the
LWM2M can be used to manage parameters, keys and similar elements
for the OTA protocol.
[0153] The use of OTA with LWM2M is not a straightforward
implementation. OTA is a solution designed for SIM card security,
as it has some real technical challenges if used for LWM2M. In
particular, while there is software written for SIM cards and SIM
OTA servers to support ETSI standard 102.225, a similar software
does not exist in the device management space for devices (and, in
particular, not for OMA DM clients and servers). Thus, M2M device
manufacturers do not have a code-base that they can easily adapt
for use with these devices.
[0154] Further, the ETSI standard 102.225 does not explain how to
set up the keys and parameters for use with the standard. It simply
assumes the keys and parameters are all pre-loaded and known to
both SIM card and OTA server. Although this assumption is
acceptable in the SIM space--because SIM cards can be securely
provisioned with the necessary keys at the manufacturing stage, and
SIM manufacturers have interfaces with operators for communicating
the necessary keys and parameters--the same cannot be said about
LWM2M, where that infrastructure does not exist.
[0155] Thus, the use of OTA together with LWM2M creates a new and
innovative combination which produces a synergistic effect and
provides many technical advantages. For example, the SMS bearer
needs to be secured, and so far no solution has been found. Use of
OTA enables the SMS bearer to be used in LWM2M. Without it, it
would not be possible to use SMS-based communications in LWM2M, and
that would limit the applicability of the overall LWM2M
standard.
[0156] Accordingly, the LWM2M standard procedures may be used to
manage parameters and/or keys used in the OTA protocol. The method
may further be used in conjunction with LWM2M, as described
above.
[0157] It has also been noted that the method described above,
implemented using the GBA (or a similar architecture), can be used
in conjunction with SMS so that the GBA can be employed to
establish keys for secure SMS-based communications (e.g. SMS),
while at the same time SMS-based communications can be used to
transport or carry messages associated with GBA--for example, carry
GBA Push Info (GPI) messages. The use of SMS-based communications
together with GBA creates a new and innovative combination which
produces a synergistic effect and provides many technical
advantages. For example, GBA can be used to establish the shared
keys that are needed to protect SMS, while using SMS as a transport
to deliver the necessary GBA messages. Further the SMS used to
deliver the GBA messages can themselves be integrity protected (and
partly encrypted) using the keys that will be established by GBA,
so at no point is there a reliance on not secure SMS. This
synergistic combination allow use of SMS as the sole bearer for M2M
traffic, something which would not otherwise be possible, except by
preloading the keys needed to secure SMS traffic, or switching to a
different protocol to negotiate these keys: both of these
alternatives would add complexity and cost. Thus, it would provide
a very high security solution for obtaining shared keys so that the
security of the keys is not compromised, and at the same time
an-SMS-based communication is enabled by virtue of the provisioning
of the keys.
[0158] Accordingly, when the method is implemented using GBA, the
GBA may be used to establish keys for secure transmission and/or
delivery of SMS. SMS-based communications may be used for
transmission and/or reception of any communication used within the
GBA, noting that these communications may themselves be protected
using the keys that will be derived in GBA.
[0159] In addition to the above, the server may further comprise a
server authentication component. Also, the client may further
comprise a client authentication component. The server
authentication component may perform authentication of the server
with the authentication component. The client authentication
component may perform authentication of the client with the
authentication component.
[0160] Further, the authentication component may be a Bootstrapping
Server Function (BSF), the server authentication component may be a
Network Application Function (NAF) and the client authentication
component may be a GAA Server.
[0161] The method may further comprise communicating between the
server and the client for determining security parameters to be
used for the secure communication, wherein the communicating is
performed by using a device management protocol (for example, the
GBA). The secure communication may be for use in the device
management protocol.
[0162] In a further embodiment, there is provided a method of
enabling secure communication for use in a device and/or
service/application management protocol, the secure communication
being between a server and a client, the client being associated
with a device, the secure communication requiring security
parameters to be agreed between the client and server, the method
comprising communicating between the server and client to agree the
security parameters, wherein the communicating is performed by
using the device management protocol. The device can be an M2M
device.
[0163] In a further embodiment, there is provided an apparatus,
system, module or network for enabling secure communication with a
device, said communication being between a server and a client, the
client being associated with the device. In addition, the
apparatus, system, module or network may further include means for
performing any one of the steps or features of the methods
described above. The device can be an M2M device.
[0164] In a further embodiment, there is provided an apparatus,
system, module or network for enabling secure communication for use
in a device and/or service/application management protocol, the
secure communication being between a server and a client, the
client being associated with a device, the secure communication
requiring security parameters to be agreed between the client and
server, the method comprising communicating between the server and
client to agree the security parameters, wherein the communicating
is performed by using the device management protocol. In addition,
the apparatus, system, module or network may further include means
for performing any one of the steps or features of the methods
described above. The device can be an M2M device.
[0165] In a further embodiment, there is provided a client
including any means, features or functionalities corresponding to
the means, features or functionalities relative to the client as
recited by any one of the methods described above.
[0166] In a further embodiment, there is provided a server
including any means, features or functionalities corresponding to
the means, features or functionalities relative to the server as
recited by any one of the methods described above.
[0167] In a further embodiment, there is provided a device
comprising a card and a client, wherein the device is arranged for
enablement of secure communication, the secure communication being
between a server and the client, wherein the provision of the
secure communication is based on a security association between a
network and the card. The client may comprise any means, features
or functionalities corresponding to the means, features or
functionalities relative to the client as recited by any one of the
methods described above. The device can be an M2M device.
[0168] In a further embodiment, there is provided a server arranged
for enablement of secure communication with a device, the secure
communication being between the server and a client associated with
the device, wherein the provision of the secure communication is
based on a security association between a network and a card, the
card being associated with the device. The server may comprise any
means, features or functionalities corresponding to the means,
features or functionalities relative to the server as recited by
any one of the methods described above. The device can be an M2M
device.
[0169] In a further embodiment, there is provided a system for
enabling secure communication with a device, said communication
being between a server and a client, the client being associated
with the device, wherein the provision of the secure communication
is based on a security association between a network and a card,
the card being associated with the device. The device can be an M2M
device.
[0170] In a further embodiment, there is provided a method of
enabling secure data communication with a device, the communication
being between a server and a client associated with the device,
wherein the security of the communication is enabled by a
bootstrapped secret. The device can be an M2M device. The security
protocol may be used to secure the data communication. The
bootstrapped secret may be used to obtain the security elements
used for the secure protocol. The bootstrapped secret may be a
pre-shared secret, said secret being directly provided to the
server and the client. The pre-shared secret may be permanently
provided to the server and the client (e.g. by pre-provisioning the
client and/or the server with said pre-shared secret, e.g. at
manufacturing stage or before the client and/or server are used in
a system). The pre-shared secret may be a strong, high entropy or a
temporary, low-entropy pre-shared secret. The bootstrapped secret
may be based on a public key or a certificate-based method. The
bootstrapped secret may be provided via a bootstrap server. The
security elements can be keys and/or similar arrangements well
known in the art.
[0171] The communication may be an SMS-based communication. The
security protocol is defined by ETSI TS 102.225. The method may use
SMS binding. The device may be further associated with a card, and
the security of the data communication may be controlled by means
of the card. Any incoming SMS-based communication may be decrypted
and/or checked by means of the card, and/or any outgoing SMS-based
communication may be encrypted and/or checked by means of the
card.
[0172] The communication may be a UDP-based communication. The
security protocol may be a DTLS protocol.
[0173] The secure data communication may be provided over a
communication interface. The communication interface may be used
for managing the device of for managing the bootstrapping
operations.
[0174] The data communication may be performed according to the
LWM2M protocol.
[0175] In a further embodiment, there is provided an apparatus,
system, module or network for enabling secure data communication
with a device, the communication being between a server and a
client associated with the device, wherein the security of the
communication is enabled by a bootstrapped secret. The device can
be an M2M device.
[0176] In a further embodiment, there is provided a method of
retrieving security elements required for enabling secure data
communication with a device, the communication being between a
server and a client associated with the device, wherein the
security elements are retrieved using a bootstrapping protocol. The
device can be an M2M device. The bootstrapping protocol may
retrieve the security elements in a secure session. The session may
be secured based on a security protocol. The security protocol may
be a DTLS protocol. The bootstrapping protocol may be based on GBA.
The data communication may be an SMS-based communication. The
bootstrapping protocol may be a LWM2M bootstrap protocol. The
security elements can be keys and/or similar arrangements well
known in the art.
[0177] In a further embodiment, there is provided an apparatus,
system, module or network for enabling secure data communication
with a device, the communication being between a server and a
client associated with the device, wherein the security elements
are retrieved using a bootstrapping protocol. The device can be an
M2M device.
[0178] The secure communication may be for the purpose of managing
the device and/or the client and/or services (e.g. provided by the
device) by the server. Both the device and the server may be
machines (i.e. not requiring any human intervention to work). When
the device is a machine, the server may be used to manage it.
Again, the management may be done without any human intervention
(e.g. automatically).
[0179] As discussed above, the solution could be used in
conjunction with the LWM2M protocol, but the solution could be
extended to other Device Management protocols, or to other M2M
services (e.g. securing delivery of binary SMS). In particular, and
as discussed above, the use of the solution in conjunction with an
M2M-specific protocol, such as LWM2M, allows the solution to be
very efficient when used with M2M devices, and in particular, when
used to manage the device and/or services provided by (or via) the
device. In other words, all the advantages mentioned above are
further enhanced and optimised when the solution is used in
conjunction with an M2M-specific protocol.
[0180] In addition, there is also provided any aspects or
combination of aspects according to any one of the claims.
[0181] Any combination of the features described in connection with
any of the aspects is also provided, even if not explicitly
disclosed.
[0182] With reference to FIG. 2, an exemplary architecture (100) is
shown that may be implemented, in particular when GBA is used. A
device 110 (in the example, an M2M Device and/or a User Equipment)
is associated with a card 112 (in the example, a UICC) and a Client
116 (in the example, a Device Management (DM) client. Note that
this client could also be an LWM2M Client, namely a client that can
manage the device itself and service/applications provided by the
device e.g. asset control). The device 110 is also associated with
a device authentication component 114 (in the example, a GAA
server). Further, a server 120 is provided (in the example, a DM
server), the server associated with a server authentication
component 122 (in the example, a Network Application Function
(NAF)). Further, an authentication component 130 is provided (in
the example, a Bootstrapping Server Function (BSF)) and a register
140 (in the example, an HLR or HSS). Also, four different
interfaces are provided for communication between the various
components, in particular interface Ua 150 between device 110 and
server 120, interface Ub 160 between device 110 and authentication
component 130, interface Zn 170 between authentication component
130 and server 120, and interface Zh/Zh' between authentication
component 130 and register 140.
[0183] In particular, with reference to GBA, document TS 33.220
defines the following components and interfaces, which are shown on
FIG. 2. NAF, the "Network Application Function", is a server-side
component of an application that may be secured using GBA. In a
preferred embodiment, the NAF may be a software component within a
Device Management (DM) Server.
[0184] Some aspects of a BSF, HLR/HSS, UE, Ua, Ub, Zh/Zh' and Zn
are provided in "Details of 3GPP standards and technologies used to
implement aspects of the method and system" above.
[0185] On successful authentication of the device 110, the BSF 130
derives the shared secret Ks_NAF, which is retrieved by the NAF. In
a preferred embodiment, the BSF 130 would most likely be on a
separate server from the HLR/HSS 140, but within an M2M platform
cluster.
[0186] The HLR/HSS may be "GBA-aware" (so that it stores details
for a GBA user subscription) or may be a legacy component. In a
preferred embodiment, the HLR/HSS would be the HLR or HSS of an M2M
mobile operator (i.e. one dedicated specifically to serving M2M
connections).
[0187] The UE 110 is, in the proposed solution, an M2M device.
[0188] In a preferred embodiment, the Ua is the interface between a
Device Management client 116 and Device Management server 120.
[0189] In a preferred embodiment, the Ub would be the interface
between the "GAA Server" component 114 of the device and the BSF
130.
[0190] In a preferred embodiment, the Zn interface is used.
[0191] In the proposed solution, this interface is between the
Device Management Server 120 and the BSF 130. The WS version of the
interface would allow placement of a DM Server in multiple
locations (not just in the M2M operator/platform cluster), and
allow future NAFs in multiple locations.
[0192] With reference to FIG. 3, the procedure for setting up the
secure communication in accordance with the present invention is
now described, in particular when GBA is used.
[0193] At 205, the UE 110 contacts over interface Ua the NAF 122
(in the described embodiment, the Device Management client 116
contacts the Device Management server 122) and discovers that the
NAF requires it to acquire a shared secret using GBA. This could be
because there is no existing secret, or the existing secret has
expired, or is otherwise considered invalid by the NAF.
[0194] The exact interface and communication method may be specific
to the application concerned. One possible interface and
communication method for OMA Lightweight M2M is discussed
below.
[0195] Over the internal UE interface from DM client to GAA server:
at 210, the DM client 116 requests the GAA server 114 to obtain a
shared secret. It presents an identifier for the corresponding NAF
(NAF_Id).
[0196] Over the Ub Interface: at 215, The UE 110 contacts the BSF
(GAA Server 114 contacts the BSF 130). This may be a basic http GET
request. The UE presents an "IMPI" (equivalent of an IMSI) or a
"TMPI" (equivalent of a TMSI) for anonymity reasons, if one is
available.
[0197] Over the Zh or Zh' Interface: at 220, the BSF 130 requests
an authentication vector from the HLR/HSS 140. At 225, the HLR/HSS
140 returns a fresh vector, consisting of a RAND, AUTN, XRES, CK,
and IK, for example.
[0198] The BSF 130 generates a transaction identifier (B-TID) and
passes (230) the B-TID together with the RAND and AUTN back to the
UE 110. It may also indicate the lifetime of the B-TID, and the
associated key.
[0199] Over the internal UE interface from the GAA Server to the
UICC: at 235, the GAA Server 114 forwards the RAND and AUTN to the
UICC 112 which validates the AUTN. If the AUTN is valid, then the
BSF 130 is authenticated. At 240, the UICC 112 returns a RES, CK
and IK to the GAA Server 114.
[0200] At 245, the UE 110 (GAA Server 114) contacts the BSF 130
again, using the resulting RES for HTTP Digest authentication
(which is identified in "Details of 3GPP standards and technologies
used to implement aspects of the method and system" above).
[0201] The BSF 130 verifies the HTTP Digest using the XRES. If it
matches, then the UE 110 has been successfully authenticated. The
BSF 130 stores the tuple <IMPI, B-TID, RAND, CK, IK> and
tells at 250 the UE 110 that the authentication was successful. The
UE 110 stores <B-TID, RAND, CK, IK>.
[0202] Over the internal UE 110 interface from DM client 116 to GAA
server 114: the UE 110 (GAA Server 114) derives a secret Ks_NAF
using the CK, IK, RAND, IMPI and NAF_Id. At 255, it passes Ks_NAF
and the B-TID back to the DM client 116.
[0203] Over the Ua interface again: at 260, the UE 110 (DM Client
116) contacts the NAF (DM Server 122) and presents the B-TID as
retrieved above.
[0204] Over the Zn Interface: at 265, the NAF 122 contacts the BSF
130, and presents the BTID. The BSF 130 authenticates the NAF,
derives the corresponding Ks_NAF, and at 270 returns it to the NAF,
together with an indicator of key lifetime.
[0205] The UE 110 (DM Client 116) and NAF (DM Server 122) now both
share Ks_NAF. They can use it directly, or to derive their own
session keys for further communication.
[0206] Again, the exact interface and communication method may be
specific to the application concerned. One possible interface and
communication method for OMA Lightweight M2M is discussed
below.
[0207] As discussed above, the solution could be used in
conjunction with the LWM2M standard. This standard can be viewed as
a successor to existing OMA Device management standards (OMA DM 1.0
to 1.3), but heavily optimized for low end machine-type devices,
and with an extended management scope beyond the device itself
including the management of services provided by the M2M device
such as asset control. This contrasts for instance with OMA DM 2.0
which is the successor for consumer devices like smart-phones,
tablets etc. Other widely-used Device Management standards include
TR-069, which was developed by the Broadband Forum for managing
Customer Premises Equipment (in particular DSL modems).
[0208] The exemplary flow described with reference to FIG. 3 is
very generic, and can be used with many different sorts of device
management protocols (or other application protocols). As can be
seen, many details of the Ua interface are outside the scope of
3GPP and are left to other standards to complete (or left to
proprietary implementations). However, integration with the LWM2M
standard is possible, as described in these examples.
[0209] Under the specification (see above), the security for OMA
LWM2M is based on DTLS v1.2 (see above) and CoAP (see above). Both
the client and server must support pre-shared key DTLS (e.g. see
section 7.1.1, page 41), whereas support for certificate-based
authentication is only optional. This means that a key derived by
GBA (Ks_NAF) could be used as a DTLS pre-shared key and it would
work with any DM client/DM server pair.
[0210] The general approach for pre-shared key TLS is referenced in
"Details of 3GPP standards and technologies used to implement
aspects of the method and system" above. The GBA and TLS-PSK
protocols work well together. In 205 described above, the "Server
Hello" message contains a field where the server can indicate that
it supports GBA-bootstrapping, and in response, the client can then
provide an identifier (B-TID) for an already bootstrapped key
(260). Or if the client doesn't already have a bootstrapped key, it
asks the GAA server to get one, before resuming the "Client Hello"
and "Server Hello" at 260. The use of the Ks_NAF to derive session
keys is then specified entirely within the TLS-PSK protocol. The
3GPP spec assumes HTTP/TLS, but the basic approach looks the same
for CoAP/DTLS.
[0211] To improve consistency with the OMA profile of GBA, the
LWM2M spec may need to define a "protocol identifier" for DTLS
pre-shared key and have it registered by OMNA (see section 5.2.1 of
OMA GBA Profile, Approved Version 1.1-31 Jul. 2012 found at
http://technical.openmobilealliance.org/Techncal/release
program/sec cf archive.aspx).
[0212] Aside from GBA aspects, the M2M device may be configured to
support the security of OMA LWM2M, which is referenced in "Details
of 3GPP standards and technologies used to implement aspects of the
method and system" above.
Additional Aspects
1. Device Development for GBA
[0213] As can be seen from FIG. 2 and FIG. 3, the M2M device may
contain several internal components. It should support a DM client
which is "GBA aware", as well as a "GAA Server" component.
[0214] The GAA Server component should support internal interfaces
to the DM client and to the SIM card (UICC) as well as the external
Ub interface to the BSF. The interface to the UICC may be
particularly challenging, as the M2M device may not expose an
existing API to allow device software to send commands to the UICC.
One possibility (that may be used) is for the modem to expose AT
commands. However, this may not be at a sufficiently low level
(AT+CSIM allows raw APDUs to be communicated to the UICC) in every
case. Further, there may be security issues: while the GAA Server
must be able to interface to the UICC, general applications
installed on the device should not be able to use this interface,
as that could allow external parties to impersonate the device (and
engender fraud on the cellular network). So the API to the SIM Card
should be privileged, as well as being sufficiently low level to be
usable.
2. Ub Tunneling, or GBA Push
[0215] The interface to the BSF is based on http and HTTP Digest
authentication. One alternative may be "tunneling" the Ub interface
within the Ua interface, so that the device only needs to support
the CoAP protocol (not HTTP as well).
[0216] A related alternative is using the GBA "Push" variant, and
carrying push messages (Upa interface) within the Ua interface.
Both of these would require identifying suitable commands and
parameters in the Ua interface (i.e. the relevant Device Management
protocol) to carry the tunnel or push messages. The interfaces and
message flow for GBA push are outlined below (see also 3GPP TS
33.223, entitled "3G Security; Generic Authentication Architecture
(GAA); Generic Bootstrapping Architecture (GBA) Push function", it
can currently be retrieved by
http://www.3gpp.org/ftp/Specs/html-info/33223.htm).
[0217] With reference to FIG. 4, an example Processing and message
flow for GBA Push follows: [0218] 1. A NAF establishes a shared NAF
SA with a UE which is registered for Push services. It knows the
identity of the subscriber. [0219] 2. The Push-NAF generates the
GPI (GBA Push info) Request and sends the GPI Request to the BSF.
[0220] 3. Upon receiving the request from the NAF, the BSF checks
that the NAF is authorized, and resolves the requested subscriber
identifier to a private identifier (e.g. IMSI). [0221] 4. The BSF
fetches a new AV (authentication vector) and subscriber's GUSS (GBA
User Security Settings) from the HSS. [0222] 5. The HSS sends the
AV and the GUSS to the BSF. [0223] 6. When the BSF receives the AV
Response from the HSS, it generates the NAF keys based on the
requested NAF_Id and creates the relevant GPI Response. [0224] 7.
The BSF sends the GPI Response to the NAF. [0225] 8. The NAF stores
the received information together with other user information in a
NAF SA. [0226] 9. The NAF then forwards the GPI to the UE over Upa
using the selected transport mechanism and the given transport
address. [0227] 10. When the UE receives the message containing the
GPI, it processes the GPI as for regular GBA, and stores the
corresponding NAF SA(s)
[0228] The UE and NAF are now ready to use the established NAF
SA.
[0229] TR33.223 specifies that Upa is a new interface that is
separate from Ua--"a new reference point Upa is introduced between
the NAF and the UE" (Section 4.2.1). As such, the Ua interface
should be unaware of whether GBA or GBA-push is being used.
3. Provisioning the Address of the BSF and the NAF
[0230] The address of the BSF (http URL) may be pre-loaded when the
device is manufactured. It could be device managed itself, which
would seem to create a "chicken-and-egg" problem, but the DM Server
could, for instance, provide an address for an acceptable BSF in
the ServerHello. Or http traffic might be routed by the M2M mobile
operator to a default BSF address. Similarly, the location of the
preferred DM Server might need to be pre-loaded, or the M2M mobile
operator could route CoAP traffic to a default DM Server
address.
4. Flavour of GBA (GBA-ME, GBA-U, GBA-SIM Etc.)
[0231] Several different versions of GBA are referenced in "Details
of 3GPP standards and technologies used to implement aspects of the
method and system". GBA-U has security advantages, but also
logistic advantages: it permits a longer lifetime for the B-TID as
the derived key is stored more securely. It allows safe retention
of Ks during power-off cycles for instance. GBA-U requires specific
support from the UICC, so would have a (modest) increment to the
cost. Since M2M devices are typically provided with a new UICC
anyway at manufacture, it is a software/development cost rather
than a hardware cost. Also, in a model with a customised UICC, this
may allow for a solution using restricted AT commands to the modem,
rather than full AT+CSIM.
5. Location of the NAF (DM Server) and Type of Zn Interface
[0232] The architecture example allows for there to be several DM
Servers in different locations: it could be part of an M2M platform
(e.g. M2M mobile operator) cluster, or hosted elsewhere by a
network operator/service provider, or perhaps by a customer of said
operator/provider. The BSF may need to be located within a
firewalled Demilitarized Zone (DMZ), or perhaps connected via an
http proxy in the DMZ (so allowing external http Web Service access
from NAFs), and then would execute the Diameter interface to the
HLR/HSS. It may be undesirable to expose an http interface directly
onto the server supporting the HLR, or to tunnel Diameter through
firewalls. However, if the DM Server is itself part of the M2M
platform cluster then this may be over-engineering. Possibly, a
Diameter solution for the Zn interface then becomes acceptable.
6. Use of Zh or Zh' Interface
[0233] Ideally, the HLR may be upgraded to a full HSS with support
for the Zh reference point. However, if the HLR/HSS only supports
Zh' then the BSF will need to be more complicated, and take on some
of the subscription management functions (profiling, lifetime,
security policies) typically associated with the HSS.
7. Development of NAF Component
[0234] While the NAF functionality looks fairly straightforward, it
will need to be developed for each DM Server used, and for each
additional application which uses GBA.
[0235] GBA keys could be used to protect SMS (e.g.
encrypt/integrity protect SMS using a secure packet interface e.g.
like ETSI TS 102.225 which is used for SIM OTA). This SMS channel
is likely to be more efficient than DTLS.
[0236] In addition, regardless of GBA, a secure SMS protocol could
be linked to a Device and/or Service management protocol, namely:
using a secure SMS protocol (e.g. originally designed for SIM OTA
(102 225)), but now adapted for LWM2M communications, combined with
using the LWM2M protocol to define (and manage) the necessary
parameters for the secure SMS protocol (i.e. the relevant KIc, KID,
SPI, TAR, and keys).
[0237] GBA could be used to securely derive the keys.
[0238] Further aspects and advantageous or preferable features are
described in the following paragraphs.
[0239] LWM2M needs a security solution for the SMS bearer. Without
a solution, SMS will not be usable as a bearer, severely limiting
scope of LWM2M. A solution to this problem is to use SIM OTA
security (e.g. see TS 102 225).
[0240] TS 102.225 relies on the keys and parameters being already
agreed between client and server. However, it is difficult to
pre-load these into LWM2M client devices, and ensure that they are
sent to servers, because there is no present infrastructure for
doing so. It would be pointless to deliver the keys and parameters
over unsecured SMS.
[0241] There are various proposed solutions for delivering these
keys and parameters in a secure way.
[0242] In a first solution, there is provided switching bearer to
UDP/Coap and running DTLS. The DTLS session can be used to secure
the LWM2M Bootstrap protocol. The LWM2M Bootstrap can be used to
set the TS 102.225 keys and parameters securely. Note that managed
resources/objects need to be defined to allow the Bootstrap server
to update them; the format of these resources is specified in the
numbered paragraphs below.
[0243] In a second solution, there is provided relying on a SIM
card (UICC) which has already having been provisioned with keys and
parameters, and using this card to terminate TS 102 225 security.
Please note that, because this solution provides a secure channel,
the same channel can be used to deliver other keys and
parameters.
[0244] In a third solution, there is provided use of GBA to set up
the keys and parameters. This works because the GPI (GBA Push Info)
can be delivered over unsecured SMS. So, there is no requirement to
have an initial key to protect the SMS. (Note that the delivery of
the parameters like Kic, KID, SPI and TAR is not obvious, but these
are only 6 bytes, and there are fields in the GPI e.g. App_Lbl,
NAF_Id, P-TID which could be used to carry this info.)
[0245] Further details are provided in the numbered paragraphs
below.
[0246] UDP channel security for [COAP] is referenced in "Details of
3GPP standards and technologies used to implement aspects of the
method and system" above.
[0247] Since the LWM2M protocol utilizes DTLS for authentication,
data integrity and confidentiality purposes, the LWM2M Client and
LWM2M Server SHOULD keep a DTLS session in use for as long a period
as can be safely achieved without risking compromise to the session
keys and counters. If a session persists across sleep cycles,
encrypted and integrity-protected storage SHOULD be used for the
session keys and counters.
[0248] Note that the Client-Server relationship of DTLS (i.e. who
initiated the handshake) is separate from the Client-Server
relationship of LWM2M.
[0249] Considering that any device with a LWM2M Client can be
managed by any LWM2M Server and LWM2M Bootstrap Server the choice
of Cipher Suites is not limited to the list defined in Section 9 of
[CoAP]. Due to the sensitive nature of Bootstrap Information,
particular care has to be taken to ensure protection of that data
including constraints and dependencies within a LWM2M
Client/Bootstrap Server relationship according to the adopted
security mode.
[0250] Concerning Bootstrap from a Smartcard, the same care has to
be taken and a secure channel between the Smartcard and the LWM2M
Device SHOULD be established as described in Appendix H of OMA
LWM2M in reference to GlobalPlatform Secure Channel Protocol 03
(SCP 03) Amendment D v1.1 September 2009.
[0251] The keying material used to secure the exchange of
information using a DTLS session may be obtained using one of the
bootstrap modes referenced in "Details of 3GPP standards and
technologies used to implement aspects of the method and system"
above.
[0252] The Resources (i.e. "Security Mode", "Public Key or
Identity", "Server Public Key or Identity" and "Secret Key") in the
LWM2M Security Object that are associated with the keying material
are used either [0253] 1) for providing UDP channel security in
"Device Registration", "Device Management & Service
Enablement", and "Information Reporting" Interfaces if the LWM2M
Security Object Instance relates to a LWM2M Server, or, [0254] 2)
for providing channel security in the Bootstrap Interface if the
LWM2M Security Object instance relates to a LWM2M Bootstrap
Server.
[0255] LWM2M Clients MUST either be directly provisioned for use
with a target LWM2M Server (Manufacturer Pre-configuration
bootstrap mode) or else be provisioned for secure bootstrapping
with an LWM2M Bootstrap Server. Any LWM2M Client which supports
Client or Server initiated bootstrap mode MUST support at least one
of the following secure methods: [0256] 1) Bootstrapping with a
strong (high-entropy) pre-shared secret, as described in section
7.1 of OMA LWM2M. The cipher-suites defined in this section MUST
NOT be used with only a low-entropy pre-shared secret. [0257] 2)
Bootstrapping with a temporary, low-entropy pre-shared secret (such
as a PIN, password and private serial number) using the
cipher-suite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, as defined in
RFC5489. [0258] 3) Bootstrapping with a public key or
certificate-based method (as described in sections 7.1.2 and 7.1.3
of OMA LWM2M). The LWM2M client MUST use a unique key-pair, one
which is unique to each LWM2M client.
[0259] For full interoperability, a LWM2M Bootstrap Server SHALL
support all of these methods.
[0260] NOTE: The above security methods can also be used by the
LWM2M Bootstrap Server to provision KIc and KID for SMS channel
security (see below for SMS channel security).
SMS Channel Security
SMS Secured Packet Structure Mode
[0261] The Secured Packet Structure is based on [3GPP TS 31
115]/[ETSI TS 102 225]] which is defining secured packets for
different transport mechanisms. The solution was originally
designed for securing packet structures for UICC based
applications, however, for LWM2M it is suitable for securing the
SMS payload exchanged between client and server.
[0262] The SMS Secured Packet Structure mode specified in this
section MUST be supported when the SMS binding is used.
[0263] A LWM2M Client which uses the SMS binding MUST either be
directly provisioned for use with a target LWM2M Server
(Manufacturer Pre-configuration bootstrap mode or Smart Card
Provisioning) or else be able to bootstrap via the UDP binding.
[0264] The end-point for the SMS channel (delivery of mobile
terminated SMS, and sending of mobile originated SMS) SHALL be
either on the smartcard or on the device. When the LWM2M Client
device doesn't support a smartcard, the end-point is on the LWM2M
Client device.
[0265] A LWM2M Client, Server or Bootstrap Server supporting SMS
binding SHALL discard SMS messages which are not correctly
protected using the expected parameters stored in the "SMS Binding
Key Parameters" Resource and the expected keys stored in the "SMS
Binding Secret Keys" Resource, and SHALL NOT respond with an error
message secured using the correct parameters and keys.
Device End-Point
[0266] If the SMS channel end-point is on the device the following
settings SHALL be applied:
[0267] Class 1 SMS as specified in [3GPP TS 23.038]
[0268] TP-PID of 111101 (ME Data Download) as specified in [3GPP TS
23.040]
[0269] TP-OA: the TP-OA (originating address as defined in [3GPP
23.040] of an incoming command packet (e.g. CoAP request) MUST be
re-used as the TP-DA of the outgoing packet (e.g. CoAP
response)
Smartcard End-Point
[0270] If the SMS channel end-point is on the smart card the
following settings SHALL be applied:
[0271] Class 2 SMS as specified in [3GPP TS 23.038]. The [3GPP TS
23.040] SMS header MUST be defined as below: [0272] TP-PID: 111111
(USIM Data Download) as specified in [3GPP TS 23.040] [0273] TP-OA:
the TP-OA (originating address as defined in [3GPP 23.040] of an
incoming command packet (e.g. CoAP request) MUST be re-used as the
TP-DA of the outgoing packet (e.g. CoAP response)
SMS Secured Packet Mode Mechanisms
1. Secure SMS Transfer to UICC
[0274] A SMS Secured Packet encapsulating a CoAP request received
by the LWM2M device, MUST be--according to [ETSI TS 102 225]/[3GPP
TS 31.115]--addressed to the LWM2M UICC Application in the
Smartcard where it will be decrypted, aggregated if needed, and
checked for integrity.
[0275] If decryption and integrity verification succeed, the
message contained in the SMS MUST be provided to the LWM2M
Client.
[0276] If decryption or integrity verification failed, SMS MUST be
discarded.
[0277] The mechanism for providing the decrypted CoAP Request to
the LWM2M Client relies on basic GET DATA commands of [GP SCP03].
This data MUST follow the format as below
data_rcv_::=<address><coap_msg> address::=TP_OA;
originated address
coap_msg::=COAP_TAG<coap_request_length><coap_request>-
; coap_request_length::=16BITS_VALUE coap_request::=CoAP message
payload
[0278] NOTE: In current LWM2M release, the way the LWM2M Client
Application is triggered for retrieving the available message from
the Smartcard is at the discretion of the device: i.e. a middle
class LWM2M Device implementing [ETSI TS 102 223] ToolKit with
class "e" and "k" support could be automatically triggered by
Toolkit mechanisms, whereas a simpler LWM2M device could rely on a
polling mechanisms on Smartcard for fetching data when
available.
2. Secured SMS Transfer to LWM2M Server
[0279] For sending a CoAP message to the LWM2M Server, the LWM2M
Client prepares a data containing the right TP-DA to use,
concatenated with the CoAP message and MUST provide that data to
the LWM2M UICC Application in using the [GP SCP03] STORE-DATA
command.
[0280] According to [ETSI TS 102 225]/[3GPP TS 31.115] the
Smartcard will be in charge to prepare (encryption/concatenation)
the CoAP message before sending it as a SMS Secure Packet ([ETSI TS
102 223] SEND_SMS command).
[0281] The SMS Secured Packet MUST be formatted as Secured Data
specified in section 7.3.1.2.
[0282] The Secure Channel as specified in Annex H SHOULD be used to
provide the prepared data to the Smartcard.
[0283] The SMS channel security is provided by the Secured Packet
Structure [ETSI TS 102 225] and [SCP080] which is defining secured
packets for different transport mechanisms.
[0284] The solution was originally designed for securing packet
structures for UICC based applications, however, for LWM2M it is
suitable for securing the SMS channel between client and
server.
[0285] The SMS channel security specified in this section MUST be
applied when the SMS binding is used.
[0286] When the LWM2M device supports a smartcard, the security
SHOULD be terminated on the smartcard. The LWM2M client SHOULD pass
SMS messages to the smartcard for encryption and integrity
protection before sending, and SHOULD pass encrypted SMS messages
received from the LWM2M server to the smartcard for decryption and
integrity checking.
[0287] A LWM2M Client which supports the SMS binding SHALL support
the Secured Packet Structure as defined in [ETSI TS 102 225] and
[SCP080]. The LWM2M Client SHALL share the relevant
keys--identified by KIc and KID--with a LWM2M Bootstrap Server
during bootstrapping, or with a LWM2M Server otherwise.
[0288] A LWM2M Bootstrap Server which supports the SMS binding
SHALL support the Secured Packet Structure as defined in [ETSI TS
102 225] and [SCP080].
[0289] A LWM2M Server which supports the SMS binding SHALL support
Secured Packet Structure as defined in [ETSI TS 102 225] and
[SCP080].
[0290] In SMS Secured Packet Structure mode, a CoAP message as
defined in [CoAP] MUST be encapsulated in [3GPP 31.115] Secured
Packets, in implementing--for SMS Point to Point (SMS_PP)--the
general [ETSI 102 225] specification for UICC based
applications.
[0291] The following applies to LWM2M Client and LWM2M Bootstrap
Server and LWM2M Server: [0292] The "Command Packet" command
specified in [3GPP 31.115]/[ETSI TS 102 225] MUST be used for both
CoAP Request and Response message. [0293] The Structure of the
Command Packet contained in the Short Message MUST follow [3GPP
31.115] specification. [0294] Single DES SHALL NOT be relied on.
[0295] AES or Triple DES with three different keys MUST be used.
[0296] Preferably, AES should be used. Where AES is used it should
be used with CBC mode for encryption (see coding of KIc in [ETSI TS
102 225] section 5.1.2) and in CMAC mode for integrity (see coding
of KID in [ETSI TS 102 225] section 5.1.3). [0297] SPI SHALL be set
as follows (see coding of SPI in [ETSI TS 102 225] section 5.1.1).:
[0298] cryptographic checksum [0299] ciphering [0300] The ciphering
and crypto graphic checksum MUST use either AES or Triple DES
[0301] Single DES SHALL NOT be used [0302] AES SHOULD be used
[0303] When Triple DES is used, then it MUST be used in outer CBC
mode and 3 different keys MUST be used [0304] When AES is used it
MUST be used with CBC mode for ciphering (see coding of KIc in
[ETSI TS 102 225] section 5.1.2) and in CMAC mode for integrity
(see coding of KID in [ETSI TS 102 225] section 5.1.3 [0305]
process if and only if counter value is higher than the value in
the RE [0306] Preferably, TAR (see coding of TAR in [ETSI TS 101
220], section 6) SHALL be set to a value in the range BF FF 00-BF
FF FF.
[0307] NOTE: A TAR for LWM2M SMS security will be requested from
ETSI SCP and the range above applies only until the TAR has been
assigned. [0308] Secured Data: contains the Secured Application
Message which MUST be coded as a BER-TLV, the Tag (TBD: e.g. 0x05)
will indicate the type (e.g. CoAP type) of that message.
[0309] There will be two different TARs for terminating the
security on the smartcard or on the device.
[0310] The ciphering and integrity keys and associated counter
values SHOULD be held in a smart card or other tamper-resistant
secure storage environment (e.g. embedded secure element). The
client SHOULD pass MT SMS to the smart card/SE for decryption and
integrity checking, and SHOULD pass MO SMS to the smart card/SE for
encryption and integrity protection before sending.
[0311] If the keys and associated counter values are not stored in
the above recommended way, they SHALL be treated as session keys
with a lifetime no greater than the duration of the Registration
Lifetime. The LWM2M Client SHALL acquire fresh discard the key
material on each "Register" or "Update" operation, load fresh key
material using one of the mechanisms described below, and reset the
counters. [0312] Re-bootstrapping via the GBA Push mechanism, as
described in [OMA DM v2.0] section 9.3.1.3. GBA Push uses a UICC to
generate a so called Ks_(ext/int)_NAF shared secret both in the
network and in the device. From this master key Ks_(ext/int)_NAF,
two session secrets are then generated: the DMBEK and the DMBIK.
The value of the KIc (ciphering key for SMS) SHALL be set by
truncating DMBEK to the relevant key length (taking bits 0 to 127
for AES-128, or bits 0 to 167 bits for 3DES), and the value of the
KID (integrity key for SMS) SHALL similarly be set by truncating
DMBIK to the relevant key length (bits 0 to 127 for AES-128, or
bits 0 to 167 for 3DES). The GBA Push Info SHALL be delivered to
the LWM2M Client using a Class 1 SMS as specified in [3GPP TS
23.038] with a TP-PID of 111101 (ME Data Download) as specified in
[3GPP TS 23.040]. [0313] Re-bootstrapping from the Smart Card by
one of the following methods: [0314] Using the above-described GBA
Push mechanism, specifically with GBA-U, and with the Smart Card
generating the DMBIK and DMBEK from Ks_int_NAF. [0315] Using Remote
File Management (RFM) or Remote Application Management (RAM) as
specified in [ETSI TS 102.226]. The LWM2M Server SHALL generate
random new key data of appropriate length for KIc and KID and
ensure these are delivered to the Smart Card by a Class 2 SMS as
specified in [3GPP TS 23.038] with a TP-PID of 111111 (USIM Data
Download) as specified in [3GPP TS 23.040], protected using the
relevant OTA security keys for RFM or RAM.
[0316] The Smart Card SHALL place the updated session keys in the
provisioning file EF_LWM2M_Bootstrap. [0317] Re-bootstrapping via
the UDP binding, secured as described in Section 7.1 (UDP
Security).
[0318] Where the UDP binding is unavailable, the LWM2M Server (or
Bootstrapping Server) SHOULD send SMS to the LWM2M Client to
refresh the session keys before the next attempted "Register" or
"Update" operation. If the LWM2M Client attempts to contact the
LWM2M Server using an expired registration, or attempts to
"Register" or "Update" using a stale key, the LWM2M Server SHALL
respond with an error (4.00 Bad Request) and SHALL send SMS to
refresh the session keys. However, the LWM2M Server SHOULD send
such SMS prior to the expiry of the current Registration, if the
LWM2M Client is awake; or if the LWM2M Client is in a sleep cycle,
the LWM2M Server (or Bootstrapping Server) SHOULD send such SMS on
the next wake up. These measures will avoid a failed "Register" or
"Update" operation.
[0319] As for Section 7.1 (UDP Security), where a session persists
across sleep cycles, encrypted and integrity-protected storage
SHOULD be used for the session keys and counters. Alternatively,
new session keys SHALL be established by one of the above
mechanisms on wake up from a sleep cycle.
[0320] Preferably, KIc, KID, SPI and TAR SHALL be stored in the
"SMS Binding Key Parameters" Resource.
[0321] Preferably, the corresponding key values should be stored in
the "SMS Binding Secret Keys" Resource.
[0322] A LWM2M Client which uses the SMS binding may either be
directly provisioned for use with a target LWM2M Server
(Manufacturer Pre-configuration bootstrap mode) or else be able to
bootstrap via the UDP binding.
[0323] A LWM2M Client, Server or Bootstrap Server supporting SMS
binding SHALL discard SMS messages which are not correctly
protected using the expected parameters stored in the "SMS Binding
Key Parameters" Resource and the expected keys stored in the "SMS
Binding Secret Keys" Resource, and SHALL NOT respond with an error
message secured using the correct parameters and keys.
LWM2M Object: LWM2M Security
[0324] Description: This LWM2M object provides the keying material
of a LWM2M Client appropriate to access a specified LWM2M Server.
One Object Instance SHOULD address a LWM2M Bootstrap Server
[0325] These LWM2M object resources MUST only be changed by a LWM2M
Bootstrap Server or SmartCard provisioning and MUST NOT be
accessible by any other LWM2M Server.
[0326] Example Object Info:
TABLE-US-00001 Object Multiple Object ID Object URN Instances?
Mandatory? LWM2M 0 Yes Yes Security
[0327] Resource Info:
TABLE-US-00002 Resource Name Type Range or Enumeration Units
Descriptions LWM2M String 0-255 bytes -- Uniquely identifies the
Server URI LWM2M Server or LWM2M Bootstrap Server, and is in the
form: "coaps://host:port", where host is an IP address or FQDN, and
port is the UDP port of the Server. Bootstrap Boolean -- Determines
if the current Server instance concerns a LWM2M Bootstrap Server
(true) or a standard LWM2M Server (false) Security Integer 0-3 --
Determines which UDP Mode channel security mode is used 0:
Pre-Shared Key mode 1: Raw Public Key mode 2: Certificate mode 3:
NoSec mode Public Key Opaque -- Stores the LWM2M Client's or
Identity Certificate (Certificate mode), public key (RPK mode) or
PSK Identity (PSK mode). The format is defined in Section E.1.1.
Server Opaque -- Stores the LWM2M Server's or Public Key LWM2M
Bootstrap Server's or Identity Certificate (Certificate mode),
public key (RPK mode) or PSK Identity (PSK mode). The format is
defined in Section E.1.1. Secret Key Opaque -- Stores the secret
key or private key of the security mode. The format of the keying
material is defined by the security mode in Section E.1.1. This
resource MUST only be changed by a bootstrap server and MUST NOT be
readable by any server. SMS Integer 0-255 Determines which SMS
Security payload security mode is used Mode (see section 7.2) 0:
Reserved for future use 1: Secure Packet Structure mode device
terminated 2: Secure Packet Structure mode smartcard terminated 3:
NoSec mode 255: Proprietary modes SMS Binding Opaque 6 bytes --
Stores the KIc, KID, SPI and Key TAR. The format is defined in
Parameters Section D.1.2. SMS Binding Opaque 32-48 bytes -- Stores
the values of the keys Secret Keys for the SMS binding. This
resource MUST only be changed by a bootstrap server and MUST NOT be
readable by any server. LWM2M Integer MSISDN used by the LWM2M
Server SMS Client to send messages to the Number LWM2M Server via
the SMS binding. The LWM2M Client SHALL silently ignore any SMS not
originated from unknown MSISDN Short Server Integer 1-65535 -- This
identifier uniquely ID identifies each LWM2M Server configured for
the LWM2M Client. This resource MUST be set when the Bootstrap
Server resource has false value. Default Short Server ID (i.e. 0)
MUST NOT be used for identifying the LWM2M Server. Client Hold
Integer s Relevant information for a Off Time Bootstrap Server
only. The number of seconds to wait before initiating a Client
Initiated Bootstrap once the LWM2M Client has determined it should
initiate this bootstrap mode
UDP Channel Security: Security Key Resource Format
[0328] This section defines the format of the Secret Key and Public
Key and Identity resources of the LWM2M Server and LWM2M Bootstrap
Objects when using UDP Channel security. These resources are used
to configure the security mode and keying material that a Client
uses with a particular Server. The Objects are configured on the
Client using one of the Bootstrap mechanisms described in Section
5.1 of OMA LWM2M. The use of this keying material for each security
mode is defined in Section 7.1 of OMA LWM2M.
Pre-Shared Key (PSK) Mode
[0329] The PSK is a binary shared secret key between the Client and
Server of the appropriate length for the Cipher Suite used
[RFC4279]. This key is composed of a sequence of binary bytes in
the Secret Key resource. The default PSK Cipher Suites defined in
this specification use a 128-bit AES key. Thus this key would be
represented in 16 bytes in the Secret Key Resource.
[0330] The corresponding PSK Identity for this PSK is stored in the
Public Key or Identity resource. The PSK Identity is simply stored
as a UTF-8 String as per [RFC4279]. Clients and Servers MUST
support a PSK Identity of at least 128 bytes in length as required
by [RFC4279].
Raw-Public Key (RPK) Mode
[0331] The raw-public key mode requires a public key and a private
key of the appropriate type and length for the Cipher Suite used.
These keys are carried as a sequence of binary bytes with the
public key stored in the Public Key or Identity Resource, and the
private key stored in the Secret Key Resource. The default RPK
Cipher Suites defines in this specification use a 256-bit ECC key.
Thus the Certificate Resource would contain a 32 byte public key
and the Secret Key Resource a 32 byte private key.
Certificate Mode
[0332] The Certificate mode requires an X.509v3 Certificate along
with a matching private key. The private key is stored in the
Secret Key Resource as in RPK mode. The Certificate is simply
represented as binary X.509v3 in the value of the Public Key or
Identity Resource.
SMS Payload Security: Security Key Resource Format
[0333] This section defines the format of the Secret Key and Public
Key and Identity resources of the LWM2M Server and LWM2M Bootstrap
Objects when using SMS Payload security. These resources are used
to configure keying material that a Client uses with a particular
Server. The Objects are configured on the Client using one of the
Bootstrap mechanisms described in Section 5.1. The use of this
keying material is defined in Section 7.2.
[0334] The SMS key parameters are stored in the order KIc, KID,
SPI, TAR (KIc is byte 0).
[0335] Ordering of bits within bytes SHALL follow ETSI TS 102 221
"Coding Conventions" (b8 MSB, b1 LSB).
Unbootstrapping
[0336] If a Security Object Instance is to be deleted, some related
resources and configurations need to be deleted or modified.
Therefore when Delete operation is sent via Bootstrap Interface,
the Client MUST proceed following procedure. [0337] 1. If there is
an Object Instance that can be accessed only by a Server of the
Server Object Instance (i.e. the Server is Access Control Owner and
the LWM2M Server can access the Object Instance only in an Access
Control Object Instance), the Object Instance and the corresponding
the Access Control Object Instance MUST be deleted [0338] 2. If an
Object Instance can be accessed by multiple Servers including the
Server, which Security Object Instance is to be deleted, then:
[0339] An ACL Resource Instance for the Server in Access Control
Object Instance for the Object Instance MUST be deleted [0340] If
the Server is Access Control Owner of the Access Control Object
Instance, then the Access Control Owner MUST be changed to another
Server according to the rules below: The Client MUST choose the
Server who has highest sum of each number assigned to an access
right (Write: 1, Delete: 1) for the Access Control Owner. If two or
more Servers have the same sum, the Client MUST choose one of them
as the Access Control Owner. [0341] 3. Observation from the Server
MUST be deleted [0342] 4. The Server Object Instance MUST be
deleted [0343] 5. Client MAY send "De-register" operation to the
Server
[0344] Note: To monitor the change of Access Control Owner, the
Server MAY observe Access Control Owner Resource.
[0345] FIG. 5 shows a system 100 for establishing a secure
connection with a machine to machine (M2M) device using the generic
bootstrapping architecture (GBA) standard (defined in TS 33.220),
which is part of a complex of standards called Generic
Authentication Architecture, a guide to which is provided in TR
33.919. The system 100 comprises a network application function
(NAF) 122, which may be a software component within a device
management server 120, a user equipment (UE) 110, which is an M2M
device, a bootstrapping server function (BSF) 130 and a home
location register (HLR)/home subscriber system (HSS) 140.
[0346] The NAF 122 is configured to provide any sort of application
or service to the UE 110 via communications channel Ua 150. It may
be any server or network component which terminates the Ua
interface (described below) from the UE 110.
[0347] The UE 110 comprises a device management (DM) client 116
that is configured to communicate with the NAF 122 via
communications channel Ua 150. The interface and communication
methods between the DM client 116 and NAF 122 via Ua 150 may be of
any suitable type. For example, any suitable device management
protocol may be utilised, such as OMA DM 2.0, OMA lightweight M2M,
constrained application protocol (CoAP), CoAP over datagram
transport layer security (DTLS) (CoAPs), TR-069 etc, and/or any
suitable M2M services may be executed via Ua 150, such as binary
short messaging services (SMS), reporting an M2M sensor reading;
M2M location reporting etc.
[0348] The UE 110 also comprises a generic authentication
architecture (GAA) server 114 that is configured to communicate
with the BSF 130 via communications channel Ub 160. The interface
and communication methods between the GAA server 114 and the BSF
130 via Ub 160 may be of any suitable type. For example hypertext
transfer protocol (http), http over transport layer security (TLS)
(https) etc.
[0349] The UE 110 also comprises a universal integrated circuit
card (UICC) 112, for example a subscriber identity module (SIM)
card or embedded SIM, which may securely hold data relating to the
UE 110.
[0350] The BSF 130 is configured to utilise the GBA standard
(defined in TS 33.220) to enable a shared secret to be derived
(bootstrapped) using the existing security association between a
mobile network and the UICC 112 so that the NAF 122 and UE 110 are
able to establish a secure association for secure communications
via Ua 150.
[0351] To that end, the BSF 130 is configured to communicate with
the NAF 122 via Zn 170 so that the NAF 122 is able to request
and/or obtain a shared secret that the NAF 122 may use to establish
secure communication with the UE 110.
[0352] Furthermore, the BSF 130 is also configured to communicate
with the HLR/HSS 140 via Zh 180 so that it may utilise the mobile
network data contained in the HLR/HSS 140 as part of the GBA
process. The interface and communication methods between the BSF
130 and the HLR/HSS 140 via Zh 180 may be of any suitable type. The
HLR/HSS 140 may be any server side element that stores subscription
details and credentials for each UICC issued by an operator. It may
be "GBA-aware" (so that it stores details for a GBA user
subscription), for example an HSS, or it may be a legacy component
that is not "GBA-aware", for example an HLR.
[0353] FIG. 5 also identifies communication steps (a) to (o)
between the elements of system 100, wherein those steps are used to
carry out the GBA process of establishing a shared secret between
the NAF 122 and the UE 110.
[0354] FIG. 6 shows an example sequence diagram that includes the
communication steps (a) to (o) that are used for establishing a
shared secret between the NAF 122 and the UE 110. The shared secret
enables keys to be established at the NAF 122 and the UE 110 so
that secure communication can take place between the NAF 122 and
the UE 110. For example, the shared secret may itself be a key for
establishing secure communication, and/or a session key(s) may be
derived from the shared secret in order to establish secure
communication.
[0355] In step (a), the DM client 116 contacts the NAF 122 via Ua
150, for example to request a service and/or application from the
NAF 122. In step (b), the NAF 122 responds by indicating that it
supports GBA-bootstrapping and that a shared secret is required in
order to establish secure communication for the NAF 122 to provide
the requested service and/or application to the UE 110. The
communication in step (b) may, for example, be a "server hello"
message. Alternatively, the NAF 122 may contact the DM client 116
via Ua 150 in step (b) without step (a) having been carried out
(for example, if the NAF 122 wishes to establish secure
communication with the UE 110 in order to provide a service and/or
application to the UE 110).
[0356] If the DM client 116 already has a bootstrapped key, it may
proceed to step (m) and provide the NAF 122 with an identifier for
the bootstrapped key, for example a transaction identifier such as
a B-TID (Bootstrap Transaction Identifier). This is described in
more detail below and may enable the subsequent steps (n) and (o)
to be carried out and a secure connection to be established between
the NAF 122 and UE 110.
[0357] If the DM client 116 does not already have a bootstrapped
key, for example because no shared secret has yet been derived, or
the existing shared secret has expired, or is otherwise considered
to be invalid by the NAF 122 (for example, if the DM client 116 has
provided a B-TID in step (m) and the NAF 122 has responded that it
considers the corresponding shared secret to be invalid), the DM
client 116 may set about acquiring a new shared secret using
GBA.
[0358] In step (c), the DM client 116 requests that the GAA server
114 obtain a shared secret. In step (c), the DM client 116 will
also pass to the GAA server 114 an identifier of the NAF 122, for
example NAF_Id (which may be a concatenation of NAF FQDN and Ua
security protocol Id), which it has obtained in step (b).
Alternatively, rather than step (c) being carried out after steps
(a) and (b), or step (b), the UE 110 may itself identify that it
requires a bootstrapped key in order to establish secure
communication with the NAF 122 and therefore carry out step (c)
without either of steps (a) or (b) taking place first. In this
case, the identifier of the NAF_Id may be stored in memory on the
UE 110, or obtained by the UE 110 by any other means.
[0359] In step (d), the GAA server 114 contacts the BSF 130 to
request that a shared secret be derived. The request may be a basic
http GET request, or any other suitable request. The GAA server 114
may also present to the BSF 130 in step (d) an identifier of the UE
110, for example an international mobile subscriber identity (IMSI)
or a temporary mobile subscriber identity (TMSI), or an IP
multimedia private identity (IMPI) or temporary mobile private
identity (TMPI) if anonymity is required.
[0360] In step (e), the BSF 130 requests an authentication vector
from the HLR 140. In step (f), the HLR/HSS 140 returns a new
authentication vector to the BSF 130. The authentication vector may
comprise a random or pseudorandom number (RAND), an authentication
token (AUTN), an expected response (XRES), a cipher key (CK) and an
integrity key (IK). The CK and the IK are derived from an existing
shared secret, K, (for example using the RAND and AUTN) that is
shared between the network provider and the UE 110, wherein the
network stores their value of K and the UE 110 stores its value of
K in the UICC 112. The contents of the authentication vector are
described in more detail in the 3GPP "Security Architecture"
specification TS 33.102, which may be found at
http://www.3gpp.org/ftp/specs/html-info/33102.htm.
[0361] The existing shared secret may alternatively be the Ki, for
example in 2G/GSM, which is explained in more detail in the 3GPP
specification TS 11.11 "Specification of the Subscriber Identity
Module-Mobile Equipment (SIM-ME) Interface" (originally GSM 11.11),
in particular in sections 8.16 and 9.2.16, which may be found at
http://www.3gpp.org/DynaReport/1111.htm.
[0362] Having received the authentication vector, the BSF 130
generates a transaction identifier (B-TID) and transmits the B-TID
along with part of the authentication vector, for example the RAND
and AUTN, back to the GAA server 114 in step (g). The BSF 130 may
also indicate to the GAA server 114 in step (g) the lifetime of the
B-TID and an associated key(s). The associated key may be, for
example, a Ks, which is a concatenation of CK and IK. For example,
as explained in 3GPP specification TS 33.220, the BSF 130 may
generate key material Ks by concatenating CK and IK and generate
the B-TID by taking the base 64 encoded RAND value and the BSF
server name i.e. base64encode(RAND)@BSF_servers_domain_name.
[0363] The GAA server 114 may then attempt to authenticate the BSF
130 by forwarding the RAND and AUTN to the UICC 112 in step (h).
The RAND and AUTN may be used as inputs to the USIM application on
the UICC 112 to run an Authentication and Key Agreement (AKA)
algorithm, as explained in 3GPP TS33.102. If the UICC 126 validates
the AUTN, the BSF 130 will be authenticated and the UICC returns a
RES (which may be generated as part of the AKA algorithm), a CK and
an IK to the GAA server 114 in step (i).
[0364] In step (j), the GAA server 114 uses the RES to protect
communication with the BSF 130 so that the BSF 130 can authenticate
the UE 110. The communication in step (j) may be an http digest
message so that http digest authentication may be executed.
However, the communication in step (j) may take any other suitable
form for the BSF 130 to authenticate the UE 110.
[0365] The BSF 130 may then authenticate the UE 110, for example
using XRES to verify an http digest. If there is a match, the UE
110 is successfully authenticated and the BSF 130 may store a tuple
comprising, for example, the identifier of the UE 110, such as the
IMPI, IMSI, TMPI or TMSI, (which the BSF 130 received from the UE
110 in step (d)), the B-TID (which the BSF 130 generated after step
(f)), the RAND, the CK and the IK (all of which the BSF received in
the authentication vector in step (f)) and notifies the GAA Server
114 in step (k) that authentication was successful.
[0366] On receipt of the indication in step (k) that authentication
was successful, the GAA Server 114 may store in memory on the UE
110 the B-TID and RAND (which the GAA Server 114 received from the
BSF 130 in step (g)) and the CK and IK (which the GAA Server 114
received from the UICC 112 in step (i)). The GAA Server 114 may
then generate key material Ks by concatenating CK and IK and derive
a shared secret, Ks_NAF, using Ks, RAND, the identifier of the UE
110 (such as the IMPI, IMSI, TMPI or TMSI) and the NAF_Id (which it
received in step (c)). In step (I) the B-TID and derived Ks_NAF are
then passed to the DM client 116.
[0367] The Key Derivation Function is described in Annex B of TS
33.220. In particular, section B.3 indicates that:
Ks_NAF=KDF (Ks, "gba-me", RAND, IMPI, NAF_Id), Ks_ext_NAF=KDF (Ks,
"gba-me", RAND, IMPI, NAF_Id), and Ks_int_NAF=KDF (Ks, "gba-u",
RAND, IMPI, NAF_Id).
[0368] All of these derivations involve RAND as an input
parameter.
[0369] However, all of these also involve Ks as an input parameter,
where Ks=CK.parallel.IK is constructed from the output returned by
the USIM, and of course RAND was an input parameter to the USIM. So
the "RAND" has already been used. It may be possible to simply
modify the derivation functions so they omit the RAND, or
substitute a known fixed value (all zeroes, say) for the RAND.
Therefore, Ks_NAF may alternatively be derived using Ks, the
identifier of the UE 110 and the NAF_Id, without using RAND.
[0370] The DM client 116 now has the secret Ks_NAF and session
identifier B-TID. However, the NAF 122 does not yet have the secret
so it is not yet possible for a secure connection over Ua 150 to be
established.
[0371] In step (m), the DM client 116 contacts the NAF 122 and
presents the B-TID to the NAF 122. The NAF 122 is then able in step
(n) to contact the BSF 130 and present it with the B-TID that the
DM client 116 had passed to the NAF 122.
[0372] Having received the B-TID from the NAF 122, the BSF 130 can
authenticate the NAF 122, derive the Ks_NAF from the Ks that is
associated with the B-TID (for example by generating key material
Ks by concatenating CK and IK and then deriving Ks_NAF using Ks,
RAND, the identifier of the UE 110 and the NAF_Id) and return the
Ks_NAF to the NAF 110 together with an indicator of the lifetime of
the key associated with the B-TID (for example, the Ks).
[0373] Thus, if Ks has expired, the NAF 122 is able to contact the
UE 110 and notify it of the expiry, in which case steps (c) to (I)
may be undertaken again by the UE 110 to obtain a new Ks and
therefore a new Ks_NAF. If the Ks is still valid, the NAF 122 and
the UE 110 will now both have a valid Ks_NAF, which may be used
directly as a key to establish secure communication on Ua 150, or
may be used by the NAF 122 and the UE 110 to derive their own
session keys for further secure communication on Ua 150.
[0374] The interface between the UE 110 and the BSF 130 over Ub 160
is based on http and HTTP Digest authentication. Whilst it may be
possible to implement communications using http and HTTP Digest
authentication over Ub 160 without requiring a full browser
implementation, carrying out communications using http and HTTP
Digest on Ub 160 and CoAP communications on Ua 150 may cause
additional complexities when the UE 110 is an M2M device.
[0375] In the above process, the UICC 112 utilises the USIM
application to run an Authentication and Key Agreement (AKA)
algorithm, as explained in 3GPP TS33.102, in order to obtain the CK
and IK (or Ks) and RES.
[0376] However, in an alternative, the UICC 112 may utilise the SIM
application on the UICC 112. In this instance, the command "RUN
GSM" could be utilised on the UICC 112, as defined in section 8.16
and 9.2.16 of 3GPP TS 11.11 (originally GSM 11.11). The input to
the command may be a 16 byte (128 bit) "RAND" and the output may be
a 4 byte (32 bit) "SRES" (abbreviation for signed response)
together with an 8 byte (64 bit) cipher key "Kc". The SIM card
implements two algorithms at once: A3 (the "authentication"
algorithm) combines the RAND with the 128 bit secret Ki (stored on
the UICC 112) and returns SRES; A8 (the "key agreement" algorithm)
combines RAND with Ki and returns Kc.
[0377] In normal GSM communication the SRES is passed to mobile
terminal to be sent to the GSM base-station (where the base station
compares it against an expected SRES which it has obtained from the
Authentication Centre AuC, along with the RAND and the Kc). After
successful authentication, the cipher key Kc is used to encrypt
traffic between the mobile terminal and the GSM base station.
However, 2G GBA performs some additional operations (that are
described TS 33.220) with the SRES and Kc in order to bring the
overall security level closer to that achieved using a USIM with
GBA.
[0378] Operators may be free to implement their own versions of A3
and A8, but various industry example algorithms have existed since
the 1990s (COMP128, COMP128v2, COMP128v3). The most secure example
algorithm is based on the Advanced Encryption Standard (AES) and is
called "GSM MILENAGE":
http://www.3gpp.org/DynaReport/55205.htm.
[0379] The major differences between SIM and USIM are: there is no
AUTN (i.e. no way for the SIM to authenticate the source of the
RAND) when using SIM; there is no integrity key ("IK"), only a
ciphering key when using SIM; the cipher key-length is shorter (64
bits instead of 128 bits). Further, the crypto-algorithms which use
Kc for ciphering (A5/1, A5/2, A5/3) are much weaker than the cipher
algorithms used in 3G and LTE.
[0380] In an alternative implementation, a GBA "push" variant may
be utilised and push messages may be carried to the UE 110 within
the Ua 150 interface.
[0381] FIG. 7 shows a system 600 for establishing a secure
connection with a machine to machine (M2M) device using the generic
bootstrapping architecture (GBA) standard and the GBA "push
variant".
[0382] The system is similar to that shown in FIG. 5, but comprises
a Upa interface 155 between the UE 110 and NAF 122 for carrying
push messages within the Ua interface 150. The system 600 also
comprises a Zpn interface 175 between the NAF 122 and the BSF 130
for carrying push related information.
[0383] FIG. 7 also identifies communication steps (v) to (z)
between the elements of system 600, wherein those steps are used to
carry out a GBA push process of establishing a shared secret
between the NAF 122 and the UE 110.
[0384] FIG. 8 shows an example sequence diagram that includes the
communication steps (v) to (z) that are used for establishing a
shared secret between the NAF 122 and the UE 110 so that secure
communication between the NAF 122 and the UE 110 can be
established.
[0385] When the NAF 122 determines that a shared secret needs to be
established between the NAF 122 and the UE 110 (for example, when
the UE 110 notifies the NAF 122 that it does not have a shared
secret, which may take place in response to a request by the NAF
122 to establish secure communication, or at any other time) and
that the UE 110 is registered for push services (for example,
because the UE 110 notifies the NAF 122 to that effect) the NAF 122
will generate a GBA push information (GPI) request and transmit it
to the BSF 130 in step (v). The GPI request may comprise an
identifier of the UE 110, for example the IMPI, IMSI, TMPI or TMSI
of the UE 110, and/or an identifier of the NAF 122, for example a
NAF_Id.
[0386] The NAF may determine that UE 110 is registered for push
services because the UE 110 notifies the NAF 122 to that effect.
Alternatively, the NAF 122 may have a pre-established table that is
based on UE 110 identifier range and indicates if the UE 110 is
registered for push services or not. The NAF 122 may look up an
identifier presented to it by the UE 110 and check it against the
UE 110 identifier range table in order to determine if the UE 110
is registered for push services. Alternatively, the NAF 122 may
transmit the request in step (v) before checking that the UE 110 is
registered for push services, and rely on the BSF to advise it if
the UE is registered and authorised.
[0387] On receiving the GPI request from the NAF 122, the BSF 130
may check that the UE 110 and the NAF 122 are authorized for
establishing secure communication using a push implementation. The
BSF 130 may itself have authorisation data for UEs and NAFs, or it
may obtain an indication of whether or not the UE 110 and NAF 122
is authorised from the HLR/HSS 140 as part of step (w) described
below. For example, UE and NAF authorisation data may be part of
the GUSS described below, or may be retrieved from the NLR/HSS 140
separately from the GUSS.
[0388] If the identifier of the UE 110 is a public identifier, for
example an IMPI or TMPI, the BSF 130 may optionally resolve the
identifier to a private identifier, for example an IMSI or
TMSI.
[0389] If the UE 110 and NAF 122 is authorised, in step (w) the BSF
130 transmits to the HLR/HSS 140 a request for a new authentication
vector (AV) and the subscriber's GBA User Security Settings (GUSS).
Alternatively, the BSF 130 may transmit the request in step (w)
before checking that the UE 110 and NAF 122 is authorised for push
services, and rely on the HLR/HSS to advise it if the UE 110 and
NAF 122 is authorized, for example if an indication of
authorization forms part of the GUSS. The GUSS are settings per
user, containing BSF specific information and the set of all
application-specific user security settings, USS (i.e. settings
particular to each UE 110 and NAF 122 pairing).
[0390] In step (x), the HLR/HSS 140 returns the AV and the GUSS to
the BSF 130. As explained earlier in respect of FIGS. 4 and 5, the
AV may comprise a RAND, an AUTN, an XRES, a CK and an IK.
[0391] The BSF 130 may then check the GUSS, for example to
determine if the user/subscription of the UE 110 is authorised to
access the service and/or what type of keys should be used for the
establishment of secure communication etc. The BSF 130 may generate
and store any keys that are required, and these keys may be based
on the identity of the NAF 122 (for example based on the NAF_Id).
For example, if the shared secret, Ks_NAF (described above) is to
be used directly as a key for establishing secure communications,
the BSF 130 may generate the Ks_NAF in the manner identified above.
If another derived key is to be used as a key for establishing
secure communications, for example Ks_ext_NAF or Ks_int_NAF, the
BSF 130 may generate Ks and then derive the necessary key(s).
[0392] The BSF 130 will also generate a GPI Response comprising
information that enables the NAF 122 and the UE 110 to set up a
secure association (SA) (described in more detail below). After
generating the GPI Response, the BSF 130 sends the GPI Response to
the NAF 122 in step (y). For example, the GPI Response may comprise
at least part of the authentication vector, for example the RAND
and AUTN. The GPI Response may also comprise an identifier, a P-TID
(push transaction identifier), that may be used to identify key
material to be used to establish secure communication (for example
the Ks). In this way, the P-TID may be considered to be a push
implementation version of the B-TID identified above. The GPI
response may also comprise information indicating what key(s)
should be used to establish secure communication and/or how those
keys may be derived and/or how the key(s) should be used to
establish secure communication. The GPI response may also comprise
an indication of the life-time of the key(s), which indicates for
how long the key(s) may be used before they need to be
refreshed.
[0393] If the BSF 130 has determined that the UE 110 is not
authorised or registered for push services, the BSF 130 may
transmit to the NAF 122 in step (y) a "not authorized" message. If
the NAF 122 is maintaining a local database of UEs which are
authorized or registered for push services, for example the
pre-established table described above, the NAF 122 may then update
its local database to record if the UE is authorised for push
services.
[0394] Having received the GPI response, the NAF 122 may set up and
store a security association (NAF_SA) comprising at least some of
the GPI response information and any other suitable user
information, for example an identifier of the UE 110 etc.
[0395] In step (z), the NAF 122 forwards the GPI response to the DM
client 116 in a push message using the UPa 155, which in turn
forwards the GPI response to the GAA server 114. When the GAA
server 114 receives the GPI response, it may process the contents
of the GPI response to set up and store on the UE 110 a
corresponding NAF_SA. For example, the UE 110 may pass the AUTN and
RAND that was part of the GPI response to the UICC 112 in order to
authenticate the BSF and obtain the CK and IK from the UICC 112,
for example by running an authentication challenge AUTHENTICATE on
the USIM application of the UICC as explained above. If the AUTN is
accepted by the UICC 112, the BSF 130 can be considered by the UE
110 to have been authenticated. The UICC 112 may then return a CK
and IK to the GAA server 114, using which the GAA server 114 can
derive a Ks and subsequently a shared secret, Ks_NAF (as explained
earlier).
[0396] Having received the GPI response and generated the Ks_NAF,
the GAA server 114 is able to set up and store its NAF_SA. The
NAF_SA may comprise a key(s) for establishing secure communication.
The GPI response can inform the UE 110 what the key(s) should be,
for example if the Ks_NAF may be used directly as the key, or if
another key(s) should be derived and stored as part of the NAF_SA.
If a new key(s) should be derived, the UE 110 may follow the
derivation process indicated in the GPI response.
[0397] Having established the NAF_SA at the UE 110, both the NAF
122 and the UE 110 will have the NAF_SA, thereby enabling secure
communication to be established between the two. As part of
establishing secure communication, the NAF 122 may effectively
validate the UE 110 through successful use of the Ks_NAF (since
only a legitimate UE 110 could derive the correct Ks_NAF and use
them with the NAF 122).
[0398] FIG. 9 shows an alternative implementation wherein a GAA
server 114' is implemented within a wireless communication module
118 in the UE 110. The wireless communication module 118 may be,
for example, a modem or a baseband processor.
[0399] The GAA server 114' may be the same as the GAA server
defined in 3GPP standards specifications, for example TR 33.905, or
it may include only the parts of the standard GAA server that are
required to carry out the below described processes.
[0400] The wireless communication module 118 may be accessed from
application logic within the UE 110 (for example, the DM client
116, or any other application within the UE 110) using AT commands.
For example, the DM client 116 may use a custom AT command with an
identifier of the NAF, for example NAF_Id, as a parameter of the AT
command in order to pass the identifier of the NAF to the GAA
server 114' in step (c) described above. The DM client 116 may then
expect a shared secret, for example Ks_NAF, and a transaction
identifier, for example B-TID, to be returned as an output to the
AT command in step (I) described above.
[0401] When the GAA server 114' has the identifier of the NAF,
steps (d) to (k) explained above may be carried out so that the GAA
server 114 can return a shared secret, for example Ks_NAF, and a
transaction identifier, for example B-TID, to the DM client 116 in
step (I) as an output to the AT command. In particular, because the
wireless communication module 118 supports a low-level interface
with the UICC 112, the GAA server 114' will be able to obtain the
material that it requires to derive the shared secret (for example,
CK, IK) and/or enable the BSF 130 to authenticate the UE 110 (for
example, RES).
[0402] For example, in step (h) the GAA server 114' may use ETSI TS
102 221 (UICC-Terminal interface; Physical and logical
characteristics), which allows raw Application Protocol Data Units
(APDUs) to be communicated to the UICC 112 in order to pass the
RAND and AUTN to the UICC 112. RAND and AUTN will be parameters of
the AUTHENTICATE command issued to the USIM application so that the
USIM application can run the AKA algorithm. CK, IK and RES may then
be returned as an output to the AUTHENTICATE command in step (i).
In an alternative, only RAND may be passed as an input to the SIM
application on the UICC 112 (or the USIM application running in a
GSM Security Context) and Kc and SRES returned in step (i) (as
explained in more detail in 3GPP TS 11.11).
[0403] By implementing the GAA server 114' on the wireless
communication module 118, it is possible to access low level,
secure parts of the UICC 112 in order to carry out the GBA process
described above, without exposing low level UICC 112 commands or
other direct access to the UICC 112 up to the application logic,
for example via AT+CSIM to the DM client 116 or any other general
applications. Thus, security of the UICC 112 can be maintained to
prevent fraudulent parties from impersonating the UE 110 in order
to engender fraud on the cellular network.
[0404] FIG. 10 shows an alternative implementation wherein an
interface application 114a is implemented as an application on an
application processor of the UE 110 and a security module 114b is
implemented within a wireless communication module 118 in the UE
110. The wireless communication module 118 may be, for example, a
modem or a baseband processor.
[0405] The interface application 114a is configured to perform part
of the functionality of the GAA server 114 described above, for
example interfacing with Ub 160. The interface application 114a may
terminate the interface Ub 160 at the UE 110. The interface
application 114a may thus include, for example, a TCP/IP stack
and/or http interface functionality.
[0406] The security module 114b is configured to perform the secure
functionality of the GAA server 114', for example interfacing with
the UICC 112, in particular interfacing with the USIM (or SIM)
application on the UICC 112.
[0407] The interface application 114a may therefore terminate the
Ub 160 interface and handle communication between the UE 110 and
the BSF 130 in steps (d), (g), (j) and (k) described above. For
example, the interface application 114a may receive the B-TID, RAND
and AUTN in step (g) and forward these on to the security module
114b for use in obtaining the CK and IK from the UICC 112. The RAND
and AUTN (and optionally also the NAF_Id) may be forwarded by the
interface application 114a to the security module 114b using a
custom AT command, and the interface application 114a may receive
the RES, or the CK, IK and RES, as an output parameter to the AT
command. In an alternative, where the SIM application is being used
on the UICC 112, the RAND (and optionally also the NAF_Id) may be
forwarded to the security module 114b using a custom AT command and
the Kc and SRES returned as an output parameter to the AT command.
The interface application 114a may then use the RES or SRES to
protect communication with the BSF 130 in step (j).
[0408] As well as passing the RAND (and optionally also the AUTN
and/or the NAF_Id) to the security module 114b as an input to the
AT command, the AT command may also include some flag that
indicates the variety of GBA that is required, for example GBA-ME,
GBA-U, GBA-SIM, GBA with ISIM etc.
[0409] Likewise, the interface application 114a may receive the
notification of successful authentication in step (k) and derive
the shared secret, Ks_NAF. Furthermore, the interface application
114a may be instructed by the security module 114b to contact the
BSF 130 with a request for a shared secret in step (d).
[0410] The interface application 114a may thus operate as a proxy
to the security module 114b.
[0411] Because the security module 114b is implemented on the
wireless module 118, the DM client 116 may still interface with it
using AT commands in order to obtain a shared secret (for example,
Ks_NAF), in the same way as described in respect of FIG. 9.
Alternatively, the DM client 116 may use an application programming
interface (API) to communicate with the interface application 114a,
while the interface application 114a in turn uses AT commands to
interface with the security module 114b (which is an alternative
not represented in the Figures).
[0412] Furthermore, the security module 114b is also able to
interface with the USIM (or SIM) application on the UICC 112 in
order to obtain the material required to derive the shared secret,
in the same way as described in respect of FIG. 9. For example, the
DM client 116 may use an API to pass an identifier of the NAF (for
example, NAF_Id) to the interface application 114a. The interface
application 114a may then use AT commands to interface with the
security module 114b to obtain the shared secret (and optionally
also the RES or SRES), and return the shared secret to the DM
client 116.
[0413] The interface application 114a may thus operate as a proxy
to the security module 114b for communication via Ub interface 160
and/or for communication with the DM client 116.
[0414] In this way, IP and http communications functionality may be
kept in the applications processor, away from the wireless module
118. Security functionality may be kept on the wireless module 118,
where it may interface as necessary with the UICC 112 and where it
is away from the applications processor. Thus, insecure elements of
the GAA server 114' may be kept in the interface application 114a,
away from the UICC 112, thereby improving security of the UICC 112.
Furthermore, the wireless module 118 will not have to terminate the
Ub 160 interface, thereby simplifying the configuration of the
wireless module 118.
[0415] As will be appreciated, in both of the implementations shown
in FIGS. 9 and 10, the secure functionality of the GAA server 114'
(i.e. the parts of the GAA server 114' that interface with the UICC
112) are implemented on the wireless module 118. Therefore, in both
implementations, a security module 114b is implemented on the
wireless module 118. However, in the implementation shown in FIG.
9, the functionality of the interface application 114a is also
implemented on the wireless module 118, wherein the functionality
of the interface application 114a and the security module 114b
together make up the GAA server 114'. As such, the implementation
shown in FIG. 9 may be considered to implement both the interface
application 114a and the security module 114b on the wireless
module 118.
[0416] The interface application 114a may be implemented as a
`stand alone` application on the application processor of the UE
110. In an alternative, it may be implemented as a `plug-in` to the
DM client 116, or the functionality of the interface application
114a may be incorporated into the DM client 116 such that the
interface application 114a is the DM client 116.
[0417] Whilst in the above implementations, communications between
the interface application 114a and the security module 114b (and
optionally also between the DM client 116 and the security module
114b) are described as taking place using custom AT commands, it
will be appreciated that any suitable commands or protocols may be
utilised. For example, a customised Radio Interface Layer (RIL) may
be used to communicate with the wireless communication module 118
(more information may be found at
http://en.wikipedia.org/wiki/Radio Interface Layer), or where the
wireless communication module 118 is an external wireless
communication module, a USB or Ethernet interface may be used.
[0418] FIG. 11 shows an alternative implementation wherein the
security module 114b is implemented within a wireless communication
module 118 in the UE 110. The wireless communication module 118 may
be, for example, a modem or a baseband processor.
[0419] This implementation is similar to that shown in FIGS. 9 and
10, but utilises the GBA "push variant" for establishing a secure
connection with the UE 110, which is described in more detail above
in respect of FIGS. 7 and 8.
[0420] As described in respect of the implementations shown in
FIGS. 9 and 10, the wireless communication module 118 may be
accessed from the application logic within the UE 110 (for example,
the DM client 116, or any other application within the UE 110)
using AT commands. Thus, the DM client 116 may use a custom AT
command with the GPI as a parameter in order to pass the GPI to the
security module 114b. The DM client 116 may then expect a shared
secret, for example Ks_NAF, to be returned as an output to the AT
command.
[0421] When the security module 114b has the GPI, it will have the
material that it requires to derive the shared secret, for example
it may have the identifier of the NAF, the RAND and the AUTN. The
security module 114b is able to use the RAND and AUTN to obtain the
RES, CK and IK from the UICC 112 using the USIM application on the
UICC 112 (or use just the RAND to obtain the SRES and Kc from the
UICC 112 using the SIM application on the UICC 12) and derive the
shared secret, for example Ks_NAF, in the same way as described in
respect of FIG. 9 above. The security module 114b may then return
the shared secret, for example Ks_NAF, to the DM client 116 as an
output to the AT command.
[0422] Alternatively, rather any using AT commands, the DM client
116 may use any other suitable commands. For example, the DM client
116 may use an API, or a customised Radio Interface Layer (RIL), or
where the wireless communication module 118 is an external wireless
communication module, a USB or Ethernet interface, to communicate
with the security module 114b in order to pass the GPI to the
security module 114b and receive the shared secret in return.
[0423] Again, by implementing the security module 114b on the
wireless communication module 118, it is possible to access low
level, secure parts of the UICC 112 in order to carry out the GBA
process described above, without exposing low level UICC 112
commands, or other direct access to the UICC 112 up to the
application logic, for example via AT+CSIM to the DM client 116 or
any other general applications. Thus, security of the UICC 112 can
be maintained to prevent fraudulent parties from impersonating the
UE 110 in order to engender fraud on the cellular network.
[0424] Furthermore, because in the push variant there is no Ub
interface 160, an http client is not required on the UE 110, and
thus it is possible to implement only the secure functionality of
the GAA server 114' (i.e. the parts of the GAA server 114' that
interface with the UICC 112) as the security module 114b on the
wireless module 118.
[0425] FIG. 12 shows an alternative implementation wherein the GAA
server 114' is implemented within the UICC 112 in the UE 110. The
GAA server 114' may be implemented as an applet within the UICC
112.
[0426] The GAA server 114' will interface with the Ub 160 interface
so as to carry out steps (d), (g), (j) and (k), which are described
above. The GAA server 114' may be accessed from application logic
within the UE 110 (for example, the DM client 116, or any other
application within the UE 110) using AT commands. For example, the
DM client 116 may use a commonly supported AT command with an
identifier of the NAF, for example NAF_Id, as a parameter of the AT
command in order to pass the identifier of the NAF to the GAA
server in step (c) described above. In particular, the DM client
116 may re-purpose commonly supported commands such as AT+CPBW
(write to the UICC's phone book), or AT+CMGS (send an SMS), or
AT+CRSM (which is a flexible command allowing data to be
communicated to and from the UICC 112 whilst still shielding the
SIM or USIM application from being called directly). Such commands
may be used to write the identifier of the NAF to the UICC's phone
book or the UICC's store of SMS messages or any other location in
the UICC's memory. Alternatively, any other suitable UICC location
for writing the identifier of the NAF may be utilised, for example
any one or more of the ad hoc files available on the UICC 112 to
store data from the UE 110, such as a standard folder which is used
for device management provisioning in OMA. These locations may
therefore be used as a "read/write buffer" to pass input and output
parameters to and from the GAA server 114' running on the UICC 112.
For this, existing, commonly supported AT commands may be
re-purposed, or custom AT commands may be utilised.
[0427] The GAA server 114 may then be configured to run
periodically, or on an event-triggered basis, and monitor the
buffer for recent "writes". When a "write" is identified, it may
retrieve the data written to the file and treat this as an
input.
[0428] For example, if the DM client 110 writes an identifier of
the NAF 122 to a location on the UICC 112 in step (c), steps (d) to
(i) as described above may be carried out so that the GAA server
114' can obtain the material it requires in order to derive the
shared secret, for example Ks_NAF. In particular, after the GAA
server 114 has obtained RAND and AUTN in step (g), it may interface
with the USIM application on the UICC 112 in step (h) and obtain
the CK, IK and RES in step (i) (or it may use RAND and interface
with the SIM application on the UICC 112 in step (h) and obtain the
Kc and SRES in step (i)).
[0429] After the GAA server 114' has derived the shared secret, for
example Ks_NAF, it may write the shared secret to a location on the
UICC 112 as an "output". The GAA server 114' may also write a
transaction identifier, for example B-TID, to the same location, or
to a different location.
[0430] The DM client 116 may be configured to monitor the
location(s) on the UICC 112 periodically and read the shared secret
and/or transaction identifier from the location(s). For example,
the DM client 116 may re-purpose commonly supported commands, for
example AT+CPBR (read from the UICC's phonebook) or AT+CMGR (read
from the UICC's SMS message store), or any other commands suitable
for reading the output stored on a file of the UICC 112 (for
example, AT+CRSM). Thus, the DM client 116 may obtain the shared
secret and/or transaction identifier in step (I).
[0431] By implementing the GAA server 114' on the UICC 112, it is
possible to carry out the GBA process described earlier in order to
establish secure communication between the NAF 122 and the UE 110
without exposing sensitive parts of the UICC 112 to applications on
the UE 110. In particular, the USIM (or SIM) on the UICC 112 may be
kept inaccessible to the application logic, thus maintaining the
security of the UICC 112.
[0432] Furthermore, the DM client 116, or any other application on
the application logic, may interface with the GAA server 114' to
provide inputs and obtain outputs by re-purposing commonly
supported AT commands, or by utilising custom AT commands. This may
simplify the implementation of the UICC 112 containing the GAA
server 114' as an applet. Alternatively, any other suitable
commands may be used to enable the DM client 116 to interface with
the GAA server 114', for example a custom Radio Interface Layer
(RIL), or PC/SC (more information can be found at
http://en.wikipedia.org/wiki/PC/SC), or SATSA (JSR 177) for J2ME
(more information can be found at
http://en.wikipedia.org/wiki/Security and Trust Services API for
J2ME), or interchip USB (where one of the chips is in the UICC 112)
(more information can be found at
http://en.wikipedia.org/wiki/InterChip USB), or http to a webserver
on the UICC 112 (more information can be found at
http://technical.openmobilealliance.org/Technica/release
program/scws vf 2.aspx).
[0433] FIG. 13 shows an alternative implementation wherein an
interface application 114a is implemented as an application on an
application processor of the UE 110 and a security module 114b is
implemented within the UICC 112 on the UE 110. The security module
114b may be implemented as an applet within the UICC 112.
[0434] This implementation is similar to that shown in FIG. 10 in
that it separates out the interface functionality and the security
functionality of the GAA server 114'. Therefore, the interface
application 114a may terminate the Ub 160 interface at the UE 110
and the security module 114b may interface with the USIM (or SIM)
application on the UICC 112 in order to obtain the material it
requires to derive the shared secret. In a similar way to that
described in respect of FIG. 10 above, the security module 114b and
interface application 114a may interface with each other in order
to pass any necessary data between the two. For example, the
interface application 114a may re-purpose common AT commands (such
as AT+CPBW or AT+CMGS or AT+CRSM) to write the AUTN and RAND to a
location(s) on the UICC 112. The security module 114b may then
write to the same location(s) or a different location(s) any
material that the interface application 114a may require, for
example the RES or SRES, so that the interface application 114a may
read the material off the UICC 112 and utilise it further as part
of the GBA process (for example by using RES or SRES to protect
communication with the BSF via the Ub interface).
[0435] The DM client 116 may interface with the security module
114b in the same way as described in respect of FIG. 12 (i.e. the
DM client 116 may use AT commands, or any other suitable commands,
to write an identifier of the NAF to a location(s) on the UICC 112,
which the security module 114b may then read as an input. The
security module 114b may write the shared secret, for example
Ks_NAF, and/or an identifier of the transaction, for example B-TID,
to the UICC 112 buffer and the DM client may read the shared secret
and/or transaction identifier from the buffer using AT commands, or
any other suitable commands).
[0436] Alternatively, the DM client 116 may use an application
programming interface (API) to communicate with the interface
application 114a, for example to pass an identifier of the NAF
(NAF_Id) to the interface application 114a. The interface
application 114a in turn can use AT commands to interface with the
security module 114b in order to write the NAF_Id to the UICC 112
(either to the same location as the AUTN and RAND, or to a
different location) so that the security module 114b can obtain the
shared secret and write it to a location on the UICC 112 so that
the interface application 114a can read the shared secret and
return it to the DM client 116. Alternatively, the security module
114b may write to a location(s) on the UICC 112 material using
which the shared secret can be derived, for example CK and IK, or
Kc, such that the interface application 114a may derive the shared
secret and pass it on to the DM client 116.
[0437] The interface application 114a may thus operate as a proxy
to the security module 114b for communication via Ub interface 160
and/or for communication with the DM client 116. In one example,
the functionality of the interface application 114a may be
performed by the DM client 116 (i.e. the interface application 114a
and the DM client 116 may be considered to be the same entity), or
the interface application 114a may be a plug-in component within
the DM client 116.
[0438] In this implementation, not only is the security of the UICC
112 maintained by implementing the security module 114b on the UICC
112, communications functionality may also be kept in the
application processor, away from the UICC 112. Thus, insecure
elements of the GAA server 114' may be kept in the interface
application 114a, away from the UICC 112, thereby improving the
security of the UICC 112. Furthermore, the security module 114b
will not have to terminate the Ub 160 interface, thereby
simplifying the configuration of the UICC 112.
[0439] As explained earlier, it will be appreciated that in both of
the implementations shown in FIGS. 12 and 13, the secure
functionality of the GAA server 114' (i.e. the parts of the GAA
server 114' that interface with the UICC 112) are implemented on
the UICC 112. Therefore, in both implementations, a security module
114b is implemented on the UICC 112. However, in the implementation
shown in FIG. 12, the functionality of the interface application
114a is also implemented on the UICC 112, wherein the functionality
of the interface application 114a and the security module 114b
together make up the GAA server 114'. As such, the implementation
shown in FIG. 12 may be considered to implement both the interface
application 114a and the security module 114b on the wireless
module 118.
[0440] The interface application 114a may be implemented as a
`stand alone` application on the application processor of the UE
110. In an alternative, it may be implemented as a `plug-in` to the
DM client 116, or the functionality of the interface application
114a may be incorporated into the DM client 116 such that the
interface application 114a is the DM client 116. In another
alternative, the interface application 114a may be implemented on a
wireless communication module 118.
[0441] Whilst in the above implementations, communications between
the interface application 114a and the security module 114b (and
optionally also between the DM client 116 and the security module
114b) are described as taking place using custom AT commands, it
will be appreciated that any suitable commands or protocols may be
utilised. For example, GBA-U commands may be used if the security
module 114b on the UICC 112 supports them (the security module 114b
may be configured on the UICC 112 to receive and respond to GBA-U
commands), or PC/SC (more information can be found at
http://en.wikipedia.org/wiki/PC/SC), or SATSA (JSR 177) for J2ME
(more information can be found at
http://en.wikipedia.org/wiki/Security and Trust Services API for
J2ME), or interchip USB (where one of the chips is in the UICC 112)
(more information can be found at
http://en.wikipedia.org/wiki/InterChip USB), or http to a webserver
on the UICC 112 (more information can be found at
http://technical.openmobilealliance.org/Technical/release
program/scws v1 2.aspx), etc. may be used.
[0442] FIG. 14 shows an alternative implementation wherein the
security module 114b is implemented within the UICC 112. The
security module 114b may be implemented as an applet within the
UICC 112.
[0443] This implementation is similar to that shown in FIGS. 12 and
13, but utilises the GBA "push variant" for establishing a secure
connection between the NAF 122 and the UE 110, which is described
in more detail above in respect of FIGS. 7 and 8.
[0444] As described above in respect of the implementations shown
in FIGS. 12 and 13, the security module 114b may be accessed by the
DM client 116 using AT commands (either custom or re-purposed).
Thus, the DM client 116 can write the GPI to a location on the UICC
112 using an AT command (for example, AT+CPBW or AT+CMGS or
AT+CRSM). The security module 114b may then read this and utilise
the information within the GPI (for example, the RAND and AUTN) to
obtain the material it requires (for example, CK and IK) to derive
the shared secret, for example Ks_NAF. The GAA server 114' can then
write this to a location on the UICC 112 and the DM client 116 can
read the shared secret from the UICC 112 using an AT command (for
example, AT+CPBR or AT+CMGR or AT+CRSM) in order to obtain the
shared secret.
[0445] Whilst in the above implementations, communications between
the DM client 116 and the security module 114b are described as
taking place using AT commands, it will be appreciated that any
suitable commands or protocols may be utilised. For example, GBA-U
commands may be used if the security module 114b on the UICC 112
supports them, (the security module 114b may be configured on the
UICC 112 to receive and respond to GBA-U commands), or PC/SC (more
information can be found at http://en.wikipedia.org/wiki/PC/SC), or
SATSA (JSR 177) for J2ME (more information can be found at
http://en.wikipedia.org/wiki/Security and Trust Services API for
J2ME), or interchip USB (where one of the chips is in the UICC 112)
(more information can be found at
http://en.wikipedia.org/wiki/InterChip USB), or http to a webserver
on the UICC 112 (more information can be found at
http://technical.openmobilealliance.org/Technical/release
program/scws v1 2.aspx), etc. may be used.
[0446] As explained in respect of FIGS. 12 and 13, the security of
the UICC 112 maintained by implementing the security module 114b on
the UICC 112. Furthermore, because in the push variant there is no
Ub interface, an http client is not required on the UE 110, and
thus it is possible to implement only the secure functionality of
the GAA server 114' (i.e. the parts of the GAA server 114 that
interface with USIM or SIM) on the UICC 112, thereby simplifying
the configuration of the UICC 112.
[0447] It is to be understood that the above description is given
by way of example and only for the benefit of understanding the
solution, and it must include also any combination of the above
features, as well as any alterations, modifications or otherwise
addition which could be done by a skilled person by use of his/her
skills and/or general knowledge in the relevant and/or neighbouring
art.
[0448] 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.
[0449] For example, the UICC 112 described above may be any sort of
integrated circuit card (ICC) (also known as a smart card, or chip
card), for example a subscriber identity module (SIM) card or IP
Multimedia Services Identity Module (ISIM) card.
[0450] Whilst FIGS. 10 and 13 show the interface application 114a
as a separate application to the DM client 116, it will be
appreciated that the interface application 114a may be implemented
as a plug-in component to the DM client 116. Alternatively, the
functionality of the interface application 114a may form part of
the functionality of the DM client 116 such that the DM client 116
performs the operations of the interface application 114a. These
alternatives may be used in particular if the Ub interface 160 is
"tunneled" to the DM client 116 via Ua 150, or via a different
interface Ua' that is distinct from Ua 150 (wherein Ua' may be
established to confirm or not to conform to any standards and may
be terminated by the DM client 116 or the interface application
114a).
[0451] In any event, regardless of how data is transmitted to and
from the UE 110, the security module 114b described above may be
configured to receive the material it requires to derive the shared
secret (for example, the NAF_Id and RAND) from one or more
applications on the UE 110. The one or more applications on the UE
110 may be implemented on the applications processor of the UE 110
(for example, from the interface application 114a and/or the DM
client 116), or within the wireless communications module 118 (as
explained above in respect of FIG. 13). Alternatively, where the
security module 114b is implemented as part of the GAA server 114'
on either the UICC 112 or the wireless communication module 118,
the security module 114b may receive the material it requires from
a connection that is terminated at the security module 114b/GAA
server 114'.
[0452] FIGS. 11 and 14 both show the DM client 116 terminating the
Upa 155 interface. However, it will be appreciated that any
application on the UE 110 may terminate the Upa interface 155. For
example, the configurations shown in FIGS. 11 and 14 may further
comprise the interface application 114a, or any other application,
which may terminate Upa and write the GPI to a location on the UICC
112 so that the security module 114b may obtain the shared secret.
The interface application 114a, or any other application, may then
read the shared secret from a location on the UICC 112 and pass it
on to the DM client 116, or the DM client 116 may itself read the
shared secret from a location on the UICC 112. The interface
application 114a, or any other application, may be implemented on
the application processor, or on a wireless communication module
118. Furthermore, rather than terminating Upa 115, the interface
application 114a, or any other application, may terminate an
interface through which Upa is "tunneled", for example Ua'.
[0453] The wireless communication module 118 may be, for example, a
modem or a baseband processor. In some implementations, M2M devices
have chips that include the functionality of a baseband processor
(or modem) and the UICC directly wired onto a printed circuit board
(PCB). An applications processor, antenna, peripherals etc. may
also be wired directly onto the PCB. Therefore, the term "wireless
communication module" is intended to encompass not only standalone
wireless communication modules (for example, a standalone modem, or
a standalone baseband processor), but any component or group of
components that are configured to execute the functionality of a
wireless communication module.
[0454] Furthermore, in the above described embodiments and the
representations shown in the Figures, the interfaces between the
NAF 122 and the UE 110, between the BSF 130 and the NAF 122 and
between the BSF 130 and the HLR/HSS 140 are represented as direct
interfaces. However, it will be appreciated that any one or more of
those interfaces may take any suitable form, whereby one or more
intermediate devices or elements, for example communication routing
devices, may be implemented as part of the interfaces. Likewise,
the interfaces between the elements within the UE 110 (for example,
between the UICC 112, GAA server 114', security module 114b,
interface application 114a, DM client 116 etc.) are represented as
direct interfaces. However it will be appreciated that any one or
more of those interfaces may take any suitable form, whereby one or
more intermediate elements, for example communication routing
devices, may be implemented as part of the interfaces.
* * * * *
References