Patent Description:
Machine to Machine (M2M) communication (M2M) may be an Internet paradigm that may be used to remotely configure and control a very large amount of electronic equipment and may open up additional possibilities with respect to services such as automotive, industry control, traffic management and building automation, may reduce cost for maintenance, surveillance, production, transport and communications, and/or the like. However, configuration and/or control using M2M communication and/or units or devices may not be possible if the principles for configuring and updating the M2M units or devices themselves may not be secure and/or efficient in terms of device management (DM) routines and principles. Unfortunately, current systems do not provide such efficient and/or secure M2M device or unit provisioning that may be desired. Document <CIT> discloses that a a wireless device is pre-provisioned with a temporary device identifier. A registration server acts as a trusted agent. The wireless device connects to the registration server, via a provisioning server in the home network, by using its temporary device identifier to obtain access information about the home network. The wireless device subsequently connects to the home network, by using said access information, to download permanent security credentials (e.g. USIM) from the home network.

Systems, methods, and/or techniques for providing access network independent device provisioning of machine-to-machine (M2M) devices belonging to different M2M application domains may be disclosed. For example, a unique reference to a preliminary M2M ID module (PMI) associated with a M2M device. The M2M device with the PMI may be registered at a M2M ID provider (MIP). A M2M ID (MI) to replace the PMI may be generated using the MIP. Additionally, a secure mutually authenticated communication channel may be set up with the M2M device within an application domain and/or may be provided for secure authorization of requests to the M2M device using the MI.

The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, not is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to the examples herein that may solve one or more disadvantages noted in any part of this disclosure.

A more detailed understanding of the embodiments disclosed herein may be had from the following description, given by way of example in conjunction with the accompanying drawings.

A detailed description of illustrative embodiments may now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the examples described herein.

As described herein, machine-to-machine (M2M) communication may be an Internet paradigm that may change technology. For example, the possibility to remotely configure and control a very large amount of electronic equipment with M2M may open up additional and/or new possibilities with respect to services such as automotive, industry control, traffic management, building automation, and/or the like and may reduce cost for maintenance, surveillance, production, transport and communications, and/or the like. However, this may be achieved if the principles for configuration and updating of M2M units or devices in a network may be secure and cost efficient in terms of device management routines and principles.

<FIG> illustrates an example of a M2M network <NUM> that may include M2M units or devices 202a-c. According to an example, in the system or network <NUM>, the M2M units or devices 202a-c may be networked and/or may be controlled and/or operated by back-end servers such as a device management server <NUM>, an application server <NUM> or by an end-user device <NUM> such as smart phones, lap top computers or desktops. The M2M units or devices 202a-c themselves have all general Internet connectivity but the access network used may be of different types including, but not limited to, cellular access, WLAN access, fixed broadband access or corporate network access, and/or the like. For example, as shown in <FIG>, a M2M device or unit 202a may be connected to a WLAN <NUM> through which it may connect to the internet <NUM>, the M2M device or unit 202b may be connected to cellular network <NUM> (e.g., that may be one or more of the networks described in <FIG> and <FIG>) through which it may connect to the internet <NUM>, and the M2M device 202c may be directly connected to the internet <NUM>.

In the example shown in <FIG>, the M2M units or devices 202a-c may be connected to the Internet and, consequently, vulnerable to network based attacks. As such (e.g., to combat such attacks), the M2M units or devices may be authenticated and protected communications may be provided and/or allowed over the Internet. According to an example, the M2M units or device such as the M2M units or devices 202a-c may be provisioned with trusted communication security credentials such that one or more methods for setting up secure communication channels with external entities such as the Internet Key Exchange (IKE) and Internet Security Protocol (IPSEC) protocol suits and/or TLS and DTLS protocol suits. With a communication domain such as one for a single operator cellular network domain, credential provisioning for secure communication establishment may be based on Universal Integrated Circuit Card (UICC) credentials. However, in one or more typical M2M examples including one or more examples described herein, a single operator access or even cellular network access may not be assumed, but some M2M units may be have direct internet connection through other means such as fixed network access through Power over Ethernet (PoE) cables, local wireless access points over IEEE <NUM>. <NUM> networks like ZigBee, Bluetooth, through WLAN access, and/or the like. As such, UICC based authentication and secure network communication set-up may not a viable option as one or more of the M2M units or devices may not have a SIM card or embedded SIM. Additionally, in an example, a traditional way or manner of handling such an issue by using different identification and/or authentication methods for different units may not be cost efficient (e.g., as they may use the end applications to handle several different authentication options in parallel). Further, the number of different M2M units or devices for an application may be large and one or more of the M2M units or devices may be resource constraint devices with limited memory and computing power. This may imply that there may need to be cost efficient and light weight techniques to provision the M2M units or devices with the credential information needed to allow secure authentication and connection set- up with the M2M units or devices within a single application domain. The examples herein may be used with resource constrained devices and may be compatible with the Constrained Application Protocol (CoAP) that may be under development by the IETF Constrained RESTful Environments (core) working group.

The system and/or methods herein may address one or more of the problems associated with current M2M units or devices and/or systems. For example, the systems and/or methods herein may provide an a access network independent system for efficient and secure device provisioning of a large amount of heterogeneous M2M units belonging to different M2M application domains.

According to an example, a secure device life-cycle may be provided and/or managed (e.g., in M2M systems). For example, from a security architecture perspective, the devices or the device platforms may be an important part of an M2M security solution. To design such systems or architectures that may be used or work in real and practical use case scenarios or examples, a life-cycle management perspective for the devices or device platforms may be analyzed and/or used (e.g., may be taken into account).

<FIG> illustrates an example a device life cycle perspective that may illustrate (e.g., from a security perspective) functions or actions that may be typically part of a connected device's lifecycle. For example, <NUM>-<NUM> may be performed and a device (e.g., the M2M units or devices 202a-c) may continue to be in operation over time (e.g., as shown by n). In an example, <NUM>-<NUM> and/or n may illustrate (e.g., from a security perspective) one or more functions or actions that may be part of a connected device's lifecycle. As shown, the life of the device may start with a manufacture phase including the hardware manufactured at <NUM> and software and configuration customization at <NUM> and <NUM> for the device (e.g., 202a-c). The next phase may be the deployment phase in which the device (e.g., 202a-c) may be customized to be able to operate for the network it may reside in and based on or according to its end customer requirements. The configurations that may be performed at installation on the device (e.g., 202a-c) though physical presence at <NUM>, locally at <NUM>, and/or remotely at <NUM> from a management server may be distinguished. The device (e.g., 202a-c) may then be operation at <NUM> during the operational phase. The device may be taken out of service (e.g., out of operation at <NUM>) with some regularity such that new software may be installed or for physical maintenance at <NUM>. The device (e.g., 202a-c) may continue to be in operation and/or upgradeable over time (e.g., as shown by n). In this device life-cycle perspective, operation of the device (e.g., 202a-c) in the operation phase may be provided and/or guaranteed (e.g., if the right security and/or safety mechanisms may be available in the other phases such as the manufacture and/or deployment phase).

In one or more examples herein, communications security and access control for resource constraint M2M units or devices may be provided and/or used. For example, authentication and authorization of resource constraint connected devices (e.g., such as those shown in <FIG> and <FIG> including 202a-c) may be performed or provided where key management such as heavy key management and authorization decisions may be performed by a certain entity in the network. This example may be illustrated in <FIG>. As shown, an advantage with this example may be that it may enable or allow offloading of computational demanding security processing of a M2M constraint device while still allowing end-to-end security between an end user device such as an end user device <NUM> (e.g., that may be the same or similar to the device <NUM>) and/or an application server <NUM> (e.g., that may be the same or similar to the server <NUM>) and M2M units such as a M2M unit or device <NUM> (e.g., that may be the same or similar to the units or devices 202a-c).

According to the model, the M2M unit <NUM> may be provisioned with an initial key material at device deployment and a trust relation (e.g., as shown by <NUM>, for example, imprinting in <FIG>) based on this key material may be established between the M2M unit <NUM> and the back-end system (e.g., <NUM> in <FIG>), for example, at <NUM>. may be used to set up secure connections between end-user devices such as the end user device <NUM> and/or application server <NUM> (e.g., at <NUM>) and/or to make fine grain authorization decisions for services offered by the M2M units to remote units. For example, a trust relationship may be established by imprinting between the M2M unit or device <NUM> and key and authorization server <NUM> (e.g., the back-end system) at <NUM>, a M2M key and authorization request may be provided and/or received (e.g., after the trust relationship) between the back end system such as the key and authorization server <NUM> and the application server <NUM> or end user device <NUM> at <NUM>, and a secure connection may be established by the M2M unit <NUM> and the end user device <NUM> and application server <NUM> at <NUM>. This model may be adopted by IETF and may be associated with Authentication and Authorization in Constrained Environments (ACE) in IETF.

For example, at <NUM>, the key may be stored at the M2M unit or device <NUM> and in the authorization server (e.g., during imprinting or imprinted thereon). The M2M unit or device <NUM> and the authorization server <NUM> may share (e.g., after imprinting) a secret that in turn may be used to set-up secure connections between application servers such as <NUM> and/or end user devices such as <NUM> at <NUM>. As such, in an example, the application servers or end user devices such as <NUM> and/or <NUM> may contact or communicate with the authorization server <NUM> that may (e.g., first) check and/or determine whether these devices may be authorized to connect to the M2M unit or device <NUM>. If authorized, the authorization server <NUM> may issue credentials (e.g., based on the one it shares with the M2M unit) such that the application servers and/or end user devices (e.g., <NUM> and/or <NUM>) may convince (e.g., using or supplying the credentials) the M2M unit or device <NUM> that they may be authorized to connect thereto and may use such credentials for establishing secure connections between the application server <NUM> and/or end user device <NUM> and the M2M unit or device <NUM> at <NUM>.

In one example, an option such as a main option to protect CoAP applications and other constraint M2M units, end-to-end, may be a Datagram TLS DTLS protocol. The DTLS handshake protocol may assume that involved peers may have been previously provided with some security material. This may include a set of preinstalled keys that may be used during the DTLS handshake agreeing on a premaster secret. Such a premaster secret may be used with one or more random values that may be generated by a client and server to compute a master secret from which the security material may be generated. DTLS may provide different approaches such as two main approaches to provide preinstalled keys.

An example approach (e.g., a first approach) may assume that each DTLS node may retain an asymmetric key pair. During the handshake, a server (e.g., which may be theM2M unit <NUM> acting as a server in a DTLS connection) may provide its own public key to a client (e.g., which may be <NUM> or <NUM> acting as a DTLS client in a secure end to end connection) such that the latter may secretly send the premaster secret as part of the ClientKeyExchange message, which may be part of a DTLS secure set-up procedure or end to end security channel establishment in <FIG>. In an example, this key provisioning policy may indicate or admit that key pairs may be provided either with or without an associated certificate. In the former case, the key pair may come together with an X. <NUM> certificate that may bind it to its Authority Name and may be signed by some common trust root. In an example, DTLS nodes may retain a list of root trust anchors and associated public keys that can be used to validate certificates. In the latter example, also known as raw public key, key pairs may include or come with no certificate, and may be generated by manufacturers and installed on nodes before deployment. Then, a DTLS node may rely on out-of-band techniques to validate raw public keys received by other peers, and typically retains a list of identities of peers it may communicate with.

An additional or alternative approach (e.g., a second approach) may assume that each DTLS node may retain a list of symmetric pre-shared keys (PSKs). Each one of such keys may include a list of nodes it may be used to communicate with, and may be generally shared by multiple entities such as more than two entities. Practically, a DTLS client (e.g., <NUM> or <NUM>) may share a symmetric key with a DTLS server (e.g., <NUM>) it may want to communicate with. During the DTLS handshake, the client may indicate which particular symmetric key may be going to be used, specifying a PSK identity (ID) in the ClientKeyExchange message. To help the client to select which identity may be used, the server may optionally provide a PSK identity hint in the ServerKeyExchange message. Both the client and server may compute the premaster secret from the symmetric key they may have agreed upon.

For some constraint devices the PSK approach may be example that may be used and, on the other hand, the standard DTLS approach for PSK may not scale well for a large number of M2M nodes as described herein with respect to the proposed credential provisioning example.

Further, in examples, M2M security provisioning standards may be provided and/or used. For example, secure provisioning of mobiles and devices may be subject to standardization including one or more secure device credential provisioning standards described herein and/or SIM provisioning described herein.

In an example, M2M systems and/or devices or units may be subject to one M2M. For example, the M2M industry imitative may include working with creating improved interoperability among M2M vendors and service providers. So far a general requirements specification as well as a couple architecture analysis specification that may have been publicly released may be used.

The one M2M requirements may include that an M2M system be able to remotely and securely provision M2M security credentials in M2M devices and/or gateways. There may not be a specific method for this provisioning, but methods such as 3GPP Generic Bootstrapping Architecture (GBA), EAP-based methods, and/or the like may be used. EAP may be a flexible framework where a "suitable" authentication method may be used as "plug in" to the protocol. The 3GPP GBA framework may be used for bootstrapping security though the usage of the SIM credentials for a third party application. One M2M may be global standardization initiative that may be provided and/or used by ETSI.

According to an example, M2M systems and/or devices or units may be subject to ETSI (e.g., ETSI <NUM><NUM>). The ETSI specification may define an M2M functional architecture for M2M services using an IP capable underlying network such as those defined by 3GPP, TISPAN and 3GPP2. Methods or procedures for bootstrapping, security, and management as well as charging may be provided.

The ETSI M2M architecture may provide or assume a security relation between the M2M device and/or gateway domain and the network domain where the services nodes may reside. This relation may be defined through a root key, a shared symmetric key between the M2M node and the M2M service provider, and/or the like. The root key may be used for subsequent authentication with the M2M service provider and, on the network side it may be managed by a specific key server such as, for example, a M2M Authentication Server (MAS). The provisioning may be performed or done by the boot strap server or, for example, in the ETSI standard, the M2M Service Bootstrap Function (MSBF).

There may be three different ways or techniques for provisioning this key (e.g., the key that may be imprinted or stored in an example i.e., an empty M2M unit or device may be imprinted with a key and/or may be bootstrapped where a key may or may not be already available or installed (e.g., the M2M unit or device may not be empty) as described herein) into a device including, one or more of the following. For example, the root key may be provisioned to the device as manufacture or at deployment. In this example, it may be the responsibility of the M2M service provider to make sure that the procedure may be secure and reliable. Additionally, in an example, the root key may be derived from network credentials such as SIM credentials (e.g., where the specification described herein may include tech and/or principles for how this may be done or performed). Further, according to an example, the root may be provisioned in an access independent method, for example, in case the M2M service provider and the network operator may not share a common trust relation.

<FIG> illustrates an example of an access independent method (e.g., in ETSI) that may be used. Other specific methods may be used (e.g., that may be divided into one or more sub-methods). According to an example, each of the methods may share a basic procedure for root key bootstrapping.

As shown, at <NUM> in <FIG>, a M2M unit or device such as M2M unit or device <NUM> (e.g., that may be the same or similar to the units or devices 202a-c or <NUM>) may be pre-provisioned with a temporary credential, public key or (symmetric key) based. In the symmetric key example, the same temporary credentials may be also given to a M2M bootstrap (MSBF) such as bootstrap server (MSBF) <NUM> and/or authentication function (MAS) such as key server (MAS ) <NUM> in the M2M network domain (e.g., via an M2M service node such as M2M service node <NUM>). In the public key example, the MSBF and the M2M unit or device may share common trusted certificate authority (CA) or other means or techniques to verify certified public keys.

The preliminary credentials may be used to give the M2M node temporary connection to the M2M service provider that then may bootstrap the unit with further preliminary credentials that may be used for the actual device root key provisioning (e.g., at 2a-2b). This may be optional. For example, at 2a, an ordinary mutual authentication with the M2M service node maybe performed using the preliminary credentials (e.g., in form of a preliminary root key) shared between the M2M unit/device and the MAS. At 2b, using the mutual authenticated and protected channel established at 2a, the M2M node may bootstrap the M2M unit/device with additional security bootstrapping material such as private public key pairs and the trusted public key of the MSBF.

At <NUM>, using the pre-provisioned parameters (e.g., that may be obtained either directly in <NUM> or through <NUM> such as 2a-2b) the M2M unit/device and the MSBF make a protected key exchange and derive/deliver or shared root key and permanent device ID. This may take place through direct communication between the M2M unit/device and the MSBF or indirectly through the M2M service node.

At <NUM>, the device ID and the key agreed on at <NUM> may be securely transferred from the MSBF to the MAS. This may be performed using any suitable method or technique.

Additionally, in one or more examples herein, Open Mobile Alliance (OMA) Device Management (DM) may be provided and/or used. According to an example, the OMA standard may include a specification of device secure bootstrapping procedures. The OMA bootstrap information may include the device credentials that may be used to set up a secure session between an OMA client and an OMA Device Management (DM) server. Different bootstrap methods may be used in OMA including, for example, one or more of the following: factory bootstrap, smartcard bootstrap, client initiated bootstrap, or server initiated bootstrap.

The factory bootstrap may imply and/or may provide that credential information may be configured in the device at manufacture. In the smartcard bootstrap, the bootstrap information may be sent in a secure channel from the smart card directly to the client device. With client initiated and/or server initiated bootstrap, the bootstrap communication may be sent over the network to the OMA client. The protection method the standard may provide may use the 3GPP GBA framework for protecting the bootstrap communication channel. The OMA bootstrap information may allow or enable the OMA client to securely connect to a provisioning server over a secure channel such as TLS. The provisioning server may configure the client with the final credentials used to set up management sessions with the device.

SIM remote provisioning may be provided and/or used. For example, relaxing the hardware based SIM provisioning system and moving to a "soft" base SIM provision model or "downloadable SIM" model for M2M units may be discussed and/or described. Examples of a soft provisioning example or paradigm may be shown in <FIG>. In such examples, a wireless downloadable USIM credential provisioning system for M2M units may be provided as shown in <FIG>. For example, a device manufacture may be used <NUM>, a registration service <NUM>, a device user <NUM> (e.g., that may be the same or similar to the end user device <NUM>), and/or a network operator subscription service <NUM> may be used for provisioning M2M units or devices 502a, 502b (e.g., that may be the same or similar to the units or devices 202a-c, <NUM>, and/or <NUM>).

These approaches may be based on the principle of using preliminary access credentials to get temporary network access and then later replace this credential with permanent SIM credentials. A problem with these solutions or examples may be that the security of the solutions described in the examples above being built upon the assumption of utilizing the cellular access security mechanisms or that they may not provide a strong security model for the actual device credential provisioning. The system and/or methods described herein may address such problems. For example, the systems and/or methods described herein may work with any suitable network access method and may provide strong end-to-end security for connections that may be used in the device provisioning using the credentials given at device provisioning.

In the standardization direction for a cellular M2M unit, SIM provisioning may use a flexible SIM provisioning model and/or a special purpose so-called "embedded SIM" hardware module (e.g., that may be different from the original downloadable SIM main assumption). The GSMA specification may include a complete embedded SIM provisioning architecture where a specific entity such as a "Subscription Manger Secure Routing" entity may be the entity responsible for the actual SIM provisioning. The main device architecture may be based on the Global Platform concept of Security Domains for managing multiple credentials on a single embedded SIM. The architecture and security model may be complex and may be compatible with UICC base credentials. This may imply, in an example, that the model may not be suitable for non-SIM M2M units.

As described herein, systems and/or methods may provide an access network independent system for efficient and secure device provisioning of a larger amount of heterogeneous M2M units that may belong to different M2M application domains.

According to examples herein, an M2M application provider may be a different entity a manufacturer of the M2M units or devices. As such, a M2M unit provisional system that may rely on final device credential provisioning in factory may not be used in one example. An alternative may include using a SIM-based or an embedded SIM based provisioning system. Unfortunately, as described herein, such a system may work for M2M units with SIM or embedded SIM-cards and may not be a generic solution or example for an M2M application domain with heterogeneous network access. As such, systems and/or methods herein may include using a credential provisioning model similar to examples described herein for downloadable SIM, but compatible with security protocols such as IKE/IPESEC or TLS/DTLS.

<FIG> illustrates an example of a credential provisioning system and method that may include a downloadable SIM and may be compatible with security protocols such as IKE/IPESEC or TLS/DTLS as described herein. In examples, one or more devices (e.g., the M2M unit or device, and/or the like as described herein) may be configured to perform at least part of the method of <FIG>. For example, an access technology independent credential provisioning service may be offered to M2M application users. This service may be or may include a M2M ID Provider (MIP) such as a MIP <NUM> (e.g., that may provide a M2M ID (MI)) as shown in <FIG>. According to an example, an M2M unit such as M2M unit or device <NUM> (e.g., that may be the same or similar to the units or devices 202a-c, <NUM>, <NUM>, and/or <NUM>) may be equipped with one or more software based preliminary credentials in, for example, as part of a soft ID module that may be a Preliminary M2M ID (PMI) module and may be shown at <NUM>-<NUM>. For example, as shown, the PMI module may be installed and/or provided on the M2M unit or device <NUM> by a device manufacturer <NUM> during manufacturing and/or provisioning of the device thereby. In an example, the PMI module may include preliminary credentials. The preliminary credentials may be used to authenticate the M2M unit or device <NUM> and/or establish secure communication channels, for example, to provision or provide a more permanity credential such as a MI as described herein.

An M2M application provider such as an end application device and/or server <NUM> may receive a unique reference to the PMI of the M2M unit or device <NUM> and may register the unit at the MIP, for example, using a K/AS (e.g., K/AS <NUM>) that may be an application key and authorization server. In an example, this may be performed at M2M unit acquisition and may be shown at <NUM>-<NUM>. For example, an owner of the M2M unit or device <NUM> may receive the PMI (e.g., when acquired and/or via access of the unit by a third party) as an electronic file and/or by reading the PMI from the M2M unit or device <NUM> at <NUM> and may register such information (e.g., via the device with the MIP as shown at <NUM> and <NUM>.

The M2M application provider (e.g., <NUM>) may use the service provided by the MIP (e.g., <NUM>) to replace the PMI (e.g., within the M2M application provider domain) with a permanent M2M credential module such as a M2M ID (MI). This may be protected end-to-end using the pre-shared-key or public key based credentials (e.g., which may be described in more detail below) in the PMI. This may be performed at the device deployment, according to an example, and may be shown at <NUM>. For example, at <NUM>, the PMI module in the M2M unit or device <NUM> may be replaced with the MI.

In an example, the MI may be used by the M2M application provider (e.g., <NUM>) to set up secure mutually authenticated communication channels with the M2M units (e.g., <NUM>) within the applications domain and/or for secure authorization at service access requests to the M2M units (e.g., which may be shown at <NUM>-<NUM>). For example, the end application device or server <NUM> may send a session key request for the MI (e.g., that may be registered and/or provided at <NUM>) to the K/AS <NUM>. The K/AS <NUM> may return (e.g., send) an identifier and/or indication associated with the MI to the end application device or server <NUM> and may be received thereby. The M2M unit or device <NUM> and end application server <NUM> may establish the communication channels by authenticating each other with the MI as described herein. For example, the end application device or server <NUM> may compare an identifier or indication associated with the MI in the M2M unit or device <NUM> with the identifier or indication received at <NUM> in response to the session key request and if such information may match may establish the communication channel at <NUM>.

The examples herein (e.g., such as the system and/or method in <FIG>) may be based on use of a software module that may hold or include the M2M unit credential information such as the M2M ID (MI) and secret/public keys used for the set-up of secure connections with the M2M unit and/or for making authorization decisions. As such, in an example, such software module may be protected from attacks trying to read out secret information or modifying the ID information. This may be performed or done by running the M2M software module in a protected execution environment. An example of a protected M2M unit may be shown in <FIG>. In an example, as shown in <FIG>, the M2M unit or device <NUM> may include a system on chip <NUM>. The system on chip <NUM> may include an ID module (IM) <NUM> that may be used to store the information (e.g., the identifier and/or keys, and/or the like as described herein) associated with the MI and/or PMI. As shown, the IM <NUM> may be part of an application framework <NUM>, one or more libraries <NUM>, and/or an operating system (OS) kernel <NUM> that may be part of the system on chip <NUM> of the M2M unit or device <NUM>. These may be above, for example, in a stack, a processor or CPU <NUM> and/or an MMU <NUM> (e.g., that may access device resources such as memory, DMA, controllers, and/or the like) of the system on chip <NUM> and/or below, for example, in the stack, one or more applications <NUM> on the M2M unit or device <NUM>. Additionally, other secure execution environment implementation options may be used in examples herein and may be described in more detail below.

According to the examples herein, a PMI can be kept after the installation of the IM or replaced by long term credential such as the MI in the IM depending on the end application user requirements. Thus, in examples, the IM may hold the PMI that may be replaced by the MI and/or the PMI and the MI. If the PMI may be kept, it may be used to later reset the M2M unit into its original factory setting by a separate reset command from a current owner. This may enable or allow an ownership transfer of the M2M unit and a possibility to register the M2M unit by a new user or owner domain based on the PMI credentials.

The examples herein (e.g., the system and/or methods herein) may provide one or more advantages. For example, the systems and/or methods may enable or allow application and access technology independent M2M unit credential provisioning (e.g., in factory). As such, the example systems and/or methods herein may decouple the access independent provision functions from the access dependent provision functions. This may be useful or attractive when a single application domain may manage several different M2M units with one or more different access requirements. Further, in an example, the network dependent credential provision may be performed or done for the different access technologies. For SIM based units, this provisioning may be performed or done using, for example, the standard proposed examples that maybe specified by GSMA and the systems and/or methods herein may be independent and compatible with such provisioning.

The systems and/or methods herein may provide a high level of security at the same time as it may enable or provide decoupling of device credential and M2M manufacturing. In particular, according to an example, this may enable or allow M2M software configuration/flashing at factory without defining the end use of the device. In an example, the final credential provision may be performed or done at device deployment phase. This may be beneficial or attractive as that may be the time where other application dependent configurations/flashing typically may be performed or done. To have cost efficient configurations at deployment, direct manual configurations of the M2M unit may be avoided. As such, configurations may be performed or done remotely in an example. Remote configurations may be sensitive to network based attacks and may be protected. The systems and/or methods herein may give such a protection using the preliminary credentials that may be already installed in factory.

Furthermore, the final credential provisioning may be performed or done away from the M2M application domain (e.g., which may imply that after the initial registration, the PIM may not be able to influence the security of the system or compromise M2M units).

The credential model in the systems and/or methods herein may enable or allow running M2M preliminary soft credentials provisioning as a separate business and/or service to M2M application providers without assuming a particular access technology for the M2M unit (e.g., except for global Internet access in an example). In examples, the systems and/or methods herein may work with constraint devices and may be compatible with the IETF core working group communication model as well as the IETF ACE working group preliminary security architecture.

Similar to the example systems and/or methods herein, ETSI may provide a framework for secure bootstrapping of device credentials using preliminary credentials provided at the factory phase. However, a drawback with ETSI may be that it may use (e.g., require) a complete trust relation between the bootstrapping function (MSBF) in the network and the entity in the network responsible for handling the device credentials such as the MAS in the ETSI example and the K/AS in the systems and/or methods (e.g., the model) herein. In an example, according to the standard, the credentials may be directly delivered from the MSBF to the MAS (e.g., when the final credentials may have been derived between the M2M unit and the MSBF). Opposite of such an example, in the system and/or methods herein, the bootstrapping server such as the MIP may be used as initial trusted server for bootstrapping the M2M unit or device and then may not need to be trusted or have further relation with the entity actually managing the device or units once they may be deployed. This example may enable or allow running the device registration and/or bootstrapping as a separate business and/or service where the M2M application owner registers his or her M2M unit or device for first time bootstrapping and with preliminary credentials. These may be later exchanged with the real credentials that may be maintained by the end system application using a secure end-to-end protected final provisioning method as described herein.

Furthermore, according to examples, the systems and/or methods herein may be based on the same or similar authentication and protected communication method that may be used used for connections and authentication functions described herein. This may simplify the implementation on the device side and may be more suitable for resource constraint M2M units or devices.

The OMA DM framework may be similar to the systems and/or methods described herein in the sense that credentials may be provided through a secure bootstrap procedure. However, the systems and/or methods herein may provide a particular approach (e.g., a three function or action approach) where first initial credentials may be configured into the device. Next, these credentials may be used at device deployment to connect to a specific initial provisioning server that may direct the device to the final end user domain where the final device credentials may be given. An advantage with such an approach compared to the OMA DM framework may be that this may enable or allow a device at factory to be given initial general security parameters that may be used and/or provided at deployment (e.g., and may be replaced as described herein) and, for example, when the end-user has registered the device, may be exchanged with the final permanent credentials. This may be a flexible model (e.g., system and/or method) that may enable or allow running credentials provisioning as a specific service and/or business for a broad range of devices independent of the end application domain.

In an example, the systems and/or methods for provisioning herein may be based on use of a symmetric key for the software based credentials modules (e.g., may be pre-shared key (PSK) based). This may be an example that may be used herein as such a solution may work with resource constraint M2M units or devices with limited computations capabilities.

This example may include (e.g., an assumption of) using a DTLS protocol to securely identify M2M units or devices and provide secure communication. The same principle may be used using the TLS or the IKE/IPSEC protocols or any other secure identification and/or communication principle.

According to an example, the MIP and/or the manufacturer may be responsible for providing M2M units with a PIM. The material that may be used for the PIM may be generated using one or more master keys. The same or similar master key may be used for key generation to a large number of different M2M units, which may simplify the credential provisioning. An example MIP master key may include KMIP or KMIP and IDKMIP or IDKMIP may be a unique identifier for this key.

In an example, a secure key server or authorization server (e.g., K/AS) may handle the device configuration at the M2M application domain. A K/AS may provide or manage keys such as two different keys for each M2M that may be registered at the K/AS. For example, the K/AS may manage a permanent master key (e.g., a KSM2M or KSM2M) that used to renew device master keys and/or a master key (e.g., a KM2M or KM2M) that may be used to generate session keys for securing end application communication between the M2M unit and the end application domain. As such, in examples herein, the KM2M may be master key that may be provided from the K/AS to the M2M to set up secure sessions with a M2M unit that (e.g., shared between K/AS and the M2M unit) and/or the KSM2M may be permanent unit master key that may be provided from the K/AS to M2M unit to generate new KM2M keys (e.g., shared between K/AS and the M2M unit).

An example system and/or method of credential provisioning (e.g., that may us a pre-shared key (PSK)) may be provided as described herein (e.g., below) and shown in <FIG> (and/or generally in <FIG>). In examples, one or more devices (e.g., the M2M unit or device, and/or the like as described herein) may be configured to perform at least part of the method of <FIG>. For example, as shown in <FIG>, at <NUM>, a M2M unit (e.g., <NUM>) may be at manufacture (e.g., with a device manufacturer such as <NUM>) and may be configured with basic software or applications such as firmware, operating system and generic applications. The M2M unit may be provided with an "empty" Identity Module (IM) (e.g., <NUM>) that may be a software module running in a protected execution environment on the device as described herein. According to an example, an empty instance of this module may be configured at <NUM> or in an alternative or additional example, at <NUM> in combination with <NUM> yielding or generating a fully configured module directly to provide, for example, the PIM on the IM.

The module (e.g., IM <NUM>) may provide one or more of following functions (e.g., according to one example when an interface may be based on a PKCS #<NUM> standard). The module may provide secure, (e.g., confidentiality and integrity protected) persistent storing of one or more the following parameters: a permanent master key, a master key, a unique identifier for the master key trust anchor for the IM such as the MIP or K/AS, a unique identifier, ID, of the M2M unit, a manufacture device key for the M2M unit, a uniform resource identifier (URI) (or other network address) of the MIP or K/AS for the IM (e.g., depending on if it is a PIM or final IM). The module may further provide an API towards other software modules running on the M2M unit offering through this interface operations on the parameters described herein (e.g., above).

At <NUM>, the IM or module may be modified, for example, with the PIM. There may be different examples for such a modification or customization (e.g., as shown in 2a and 2b). For example, at 2a (e.g., as part of the final M2M unit SW customization), the "empty" IM at <NUM> may be customized with a preliminary key material such as the parameters described above in <NUM>. At <NUM> an, in particular, 2a the "empty" IM may be transformed into a fully functional PIM. For example, at 2a, the MIP may use a random function to generate a unique and sufficiently long random value (e.g., long enough to provide entropy for high level randomness and/or security) that may serve as a Preliminary Identity (PID) for the M2M unit. The MIP may use a suitable secure Pseudo Random Function (PRF) such as a HMAC function with SHA-<NUM>, KMIP and PID and may calculate a preliminary master key, KMPM2M, for the M2M unit as KMPM2M = PRF(KMIP,PID). The KMPM2M may be a preliminary master key for a M2M unit that may be shared between the MIP and the M2M unit. According to an example, the KMIP may be a M2M ID provider generic master key (e.g., that may be provided therefrom).

Further (e.g., at 2a), the PID, a IDKMIP (e.g., an identifier for KMIP) and the KMPM2M as well as a network identifier such as URIMIP of the MIP may be securely transferred (e.g., confidentiality and integrity protected) using a suitable secure channel, to the manufacturer from the MIP. In an example, the parameters may be transferred or sent in a batch (e.g., to several potential new M2M units at the same time). The manufacturer may use a PRF to calculate a sufficient long manufacturer device key for the unit, MKM2M. The MKM2M may be a manufacturer device key for an M2M unit that may be provided from the manufacturer to the entity that may acquire the M2M unit.

The manufacturer (e.g., at 2a) may securely configure the M2M PIM as follows with reference to the IM description or parameters described herein (e.g., at <NUM>). For example, the manufacturer may configure the permanent master key, which may be may be kept as empty, the KMPM2M, the IDKMIP, the PID, the MKM2M, and/or the URIMIP.

According to an example, at 2b (e.g., in an alternative or additional example), as part of the final M2M unit SW customization, the "empty" IM explained at <NUM> may be customized with preliminary key material such as the parameters described at <NUM>. During this process, the "empty" IM may be transformed to a functional PIM (e.g., a fully functional PIM) as follows. The MIP securely (e.g., over a protected channel) may provide the device manufacturer a batch master key KMPM2M valid for security configuration of a batch of n different M2M units. The MIP may further provide an ID value for the master key IDKMIP.

According to an example, the MIP may provide the device manufacturer a Pseudo Random Function (PRF) to be used to calculate factory master keys for the devices as described herein. For example, the manufacturer may use a good random function to generate a unique and sufficient long random value that serve as a Preliminary Identity (PID) for the M2M unit. The manufacture may further use the PRF to a calculate a preliminary master key, KMPM2M, for the M2M unit as KMPM2M = PRF(KMPM2M,PID). The manufacturer may use a suitable PRF to calculate a sufficient long manufacturer device key for the unit, that may be a MKM2M.

In an example (e.g., at 2b), the manufacturer may securely configure the M2M PIM as follows with reference to the IM description at <NUM> (e.g., with the parameters thereof). For example, the manufacturer may configure the permanent master key, which may be kept as empty, the KMPM2M, the IDKMIP, the PID, the MKM2M, and/or the URIMIP.

As shown in <FIG>, at <NUM>, the M2M unit (e.g., <NUM>) may be provided to an owner such as a M2M application owner (e.g., via an end application server or device <NUM>). In an example (e.g., when the M2M unit may be acquired by the M2M application owner), the PID and MKM2M of the M2M unit may be included or provided (e.g., as part of the unit) and/or received from the manufacturer by the M2M application owner (e.g., via <NUM>). A reference such as a URI and/or the like to the MIP responsible for the preliminary M2M unit credential registration may also be provided or included and/or received thereby (e.g., via <NUM>). The M2M application unit (e.g., <NUM>) may further include or receive (e.g., at <NUM>) an electronic certificate that may certify that the application owner really may be the true owner of the acquired M2M unit.

At <NUM>, the K/AS (e.g., <NUM>) may connect or communication with the MIP over an interface such as a secure channel. For example, the M2M application owner (e.g., via the device or server <NUM> and K/AS <NUM>) that may be operating the M2M unit (e.g., <NUM>) may contact the MIP (e.g., <NUM>) over a secure channel to establish communication between the M2M unit and MIP. The PID may be sent to the MIP (e.g., via the channel or interface that may be established) by the device or server <NUM> and K/AS <NUM>. According to an example, as shown at <NUM>, the certificate may be sent to the MIP and/or the K/AS to prove that the M2M application owner may be an actual owner of the subject M2M unit. The K/AS may transfer to the MIP at least one or more of the following information: the network identifier such as a URIK/AS address of the application owner key and/or authorization server K/AS, a K/AS preliminary key identifier (IDPK/AS), a second preliminary randomly selected master key such as a KMP2M2M for the M2M unit that may be generated by the K/AS using a secure key generation process, and/or the like. As such, in an example, the KMP2M2M may be another or second preliminary randomly selected master key that may be shared between K/AS and MIP and given to the M2M unit by the MIP.

According to an example, at <NUM>, the MIP (e.g., <NUM>) may store the information (e.g., described in <NUM>) together with the record of the M2M with PID. For example, the MIP may store one or more of the following: the network identifier such as a URIK/AS address of the application owner key and/or authorization server K/AS, a K/AS preliminary key identifier IDPK/AS, a second preliminary randomly selected master key such as a KMP2M2M for the M2M unit that may be generated by the K/AS using a secure key generation process, and/or the like together with the record of the M2M with PID. In an example, at <NUM>, the K/AS (e.g., <NUM>) may store KMPM2M at the PID M2M record.

As shown in <FIG>, at <NUM>, one or more of the following may be performed. For example, at M2M first time device deployment (e.g., directly after the M2M unit may have or get full Internet access (e.g., for the first time)), the following may be performed or take place. In an example, the M2M unit (e.g., <NUM>) may use the URI of MIP to contact the MIP (e.g., <NUM>) it may belong to or be associated with (e.g., at 6a). Further, according to an example (e.g., using the IDKMIP, PID, and the KMPM2M), the M2M unit and the MIP may establish (e.g., at 6b) a secure PSK-based DTLS connection, for example, using PID combined with IDKMIP as key identifier. The MIP may determine (e.g., look up at 6c) the record of the connected M2M unit and may transfer the information such as the network identifier such as a URIK/AS address of the application owner key and/or authorization server K/AS, a K/AS preliminary key identifier IDPK/AS, a second preliminary randomly selected master key such as a KMP2M2M for the M2M unit that may be generated by the K/AS using a secure key generation process, and/or the like (e.g., described at <NUM>).

The M2M unit (e.g., <NUM>) may use (e.g., at 6d) the information received from the transfer from the MIP (e.g., together with factory configurations) to generate create a new (or replace the old) IM (e.g., <NUM>). According to an example, the IM may include the permanent master key, which may be kept as empty, the KMP2M2M, the IDPK/AS, the PID, the MKM2M, the URIK/AS, and/or the like. The M2M unit may use (e.g., at 6e) the information configured in the IM (e.g., at 6c) to determine or look up the K/AS and establish a secure PSK- based DTLS connection with the K/AS using the combination of PID and IDPK/AS as a key identifier and MKM2M∥MP2M2M as a PSK key (i.e., the manufacturer key together with the MP2M2M. According to an example, there may be different options of how these keys may be combined including a pure concatenation of the two keys, an XOR of the two keys, and/or the like. The IP address such as IPv6 or IPv4 of the M2M units may be recorded or received by the K/AS and stored together with the M2M ID and the rest of the M2M information in a suitable database or storage component (e.g., at 6f). In an example, the K/AS may generate (e.g., at <NUM>) one or more of the following parameter: a KSM2M, a KM2M, an ID such as a unique ID for the M2M unit, and/or the like. The K/AS may pre-generate these values in one example.

The key material, and/or the like that may be used to fully customize a new IM may be securely (over the protected DTLS connection) transferred (e.g., at <NUM>) from the K/AS to the M2M unit including, for example, the KSM2M, the KM2M, the IDK/AS (e.g., the permanent K/AS key identifier), the ID, kept empty or an indication thereof, URIK/AS, and/or the like. The M2M unit may be configured for the particular M2M application domain with application specific configuration information and software (SW) (e.g., at 6i). According to an example, this information may be transferred and protected under the established DTLS connection.

As shown in <FIG>, at <NUM> (e.g., when the end user application server or user device may want to communicate with a certain M2M unit), the end user application or user device (e.g., <NUM>) may determine or looks up its address and ID and may contact the K/AS (e.g., <NUM>). According to examples, the K/AS and the application server or user device may be combined and may be the same physical unit and/or, as described herein, may be separate entities. Additionally, in an example, the K/AS may function as a M2M unit discovery server that used to find a certain service or particular M2M unit. At <NUM>, the K/AS may find or determine (e.g., match) the record for the requested M2M unit and may obtain or receive KM2M, may generate a sufficient large random nonce, N and/or may use this nonce to calculate a DTLS pre-shared session key, KS = PRF(KM2M,N) and may transfer N and KS to the end user application server or user device. In one example (e.g., optionally), the end user application or user device may receive or get an authorization token based on KM2M from the K/AS that may be used to get access to particular services provided by the M2M unit (e.g., <NUM>) and/or to authenticate the M2M unit.

In an example, at <NUM>, the end user application server or user device (e.g., <NUM>) may contact the M2M unit or device (e.g., <NUM>) and may set up a secure DTLS connection with the M2M unit with mutual authentication. The DTLS connection may be established using the combined values ID, IDK/AS, N as key identifier in the DTSL PSK handshake with KS as premaster secret. For example, such values may be compared to authenticate the M2M unit or device with the end application server or user device. According to an example (e.g., when receiving N), the M2M unit may be able to calculate KS using the stored iKM2M and the received nonce.

In an example, the key KM2M may be used a limited number of times in order not to have the risk of compromising the security of the scheme. As such (e.g., when the K/AS may have generated a certain number of KS from KM2M), the K/AS may initiate a key updated session with the M2M unit and, may securely transfer a nonce value and may use the key KSM2M to calculate a new KM2M. Further, in an example, the key may be used to perform a M2M unit secure reset in case of a fatal device failure.

In an example, the systems and/or methods for provisioning herein may be based on a public key (e.g., may be public key based). According to such an embodiment, the M2M units may configured at manufacture and deployment time with light-weight public key material such a raw public keys or light weight certificates. The same principle may also be used in accordance with an advanced Public Key Infrastructures (PKI) such as PKIX, and/or other public key based techniques.

An example system and/or method of credential provisioning (e.g., that may use a public key or may be public key based) may be provided as described herein (e.g., below) and shown in <FIG> (and/or generally in <FIG>). The method may be similar to that shown in <FIG> (e.g., except in one or more examples different information such as keys, URIs, and/or the like may be used for such credential provisioning). In examples, one or more devices (e.g., the M2M unit or device, and/or the like as described herein) may be configured to perform at least part of the method of <FIG>. As shown in <FIG>, for example, at <NUM>, the M2M unit (e.g., <NUM>) may be at manufacture and may be configured with basic SW such as firmware, an operating system and/or generic applications (e.g., by a device manufacturer such as <NUM>). The M2M unit may also be provided with an "empty" (e.g., an empty instance of this module may be configured at <NUM> or in an alternative embodiment, this may be combined with <NUM> described herein (e.g., below) giving a fully configured module directly) Identity Module (IM) (e.g., <NUM>), which may be a software module running in a protected execution environment on the device. According to an example, this module may provide at least one or more of the following functions (e.g., where such an interface may be based on the PKCS #<NUM> standard). For example, the module may provide secure (e.g., confidentiality and integrity protected) persistent storing of at least one or more of the following parameters: a private and public key of a public key pair that may be used to securely identify the M2M unit, storage of hash or complete raw public keys of an external trusted entity such as the MIP (e.g., <NUM>) or an M2M application domain key and authorization server or a traditional root certificate for a similar or same purpose, a unique identifier, ID, of the M2M unit, a manufacture device key for the M2M unit, a URI (or other network address) of the MIP or K/AS for the IM (e.g., depending on if it is a PIM or final IM), and/or the like. In examples, this module may also be provided with an API towards other software modules running on the M2M unit that may offer or provide through this interface public and private key operations on the parameters described herein (e.g., a private and public key, a hash or raw public keys, a unique identifier or ID, a manufacture device key, a URI, and/or the like described above).

At <NUM> (e.g., as part of the final M2M unit SW customization), the "empty" IM (e.g., from <NUM>) may be customized with preliminary key material such as the parameters above described herein (e.g., above at <NUM>). During this process the "empty" IM may be transformed to a PIM (e.g., a fully functional PIM). In an example, at least one or more of the following parameters or information may be generated and configured in the IM. For example (e.g., at 2a), M2M private public keys, PPkM2M, (e.g., a first M2M private public key pair) may be generated "on board" the M2M unit while trusted public key and/or root certificates may be transferred to the M2M through a manufacture process. Further, in an example, a M2M private public key pair may be transferred to the M2M unit though a manufacture process. In this example, the M2M public key (or a hash of it) may be securely transferred from the manufacture to the MIP as part of the registration process after M2M manufacture (e.g., during M2M unit shipment).

According to an example (e.g., at 2b), a PID may be generated and/or configured in the IM. PID may be a secure one-way hash of the device public key where, for example, PID = H(PuM2M). This value may be transferred through the manufacturer to the MIP (e.g., if option <NUM> may apply the on board generation option in 2a).

A unique reference, H(PuMIP), to the MIP raw public key or root certificates may be securely provided or sent (e.g., at 2c) to the manufacturer such that it may configure the M2M unit with these parameters (done for a whole batch of M2M units). In an example, the unique reference may be a cryptographically (e.g., strong) one-way hash of the MIP public key or certificate.

In examples, the manufacturer may use (e.g., at 2d) a PFR such as a suitable PRF to calculate a sufficient long manufacturer device key for the unit, MKM2M, which may be configured into the IM of the M2M unit. Further (e.g., at 2e), the network identifier, URIMIP, of the MIP may be securely configured in the IM of the M2M unit.

As shown in <FIG>, at <NUM>, the M2M unit (e.g., <NUM>) may be provided to an owner such as a M2M application owner (e.g., via <NUM> and/or <NUM> in an end application domain). In an example (e.g., when the M2M unit may be acquired by the M2M application owner), the PID and MKM2M of the M2M unit may be included or provided (e.g., as part of the unit) and/or received from the manufacturer. A reference such as a URI and/or the like to the MIP responsible for the preliminary M2M unit credential registration may also be provided or included and/or received. The M2M application unit may further include or receive (e.g., at <NUM>) an electronic certificate that may certify that the application owner really may be the true owner of the acquired M2M unit.

At <NUM>, the K/AS (e.g., <NUM>) may connect or communication with the MIP (e.g., <NUM>) over an interface such as a secure channel. For example, the M2M application owner operating the M2M unit may contact the MIP over a secure channel to establish communication between the M2M unit and MIP. The PID may be sent to the MIP (e.g., via the channel or interface that may be established). The M2M unit (e.g., via K/AS) may receive or get in return from the MIP a unique reference to the preliminary public key of the M2M unit, PuM2M (e.g., where the PuM2M may be a public key part of PPkM2M). According to an example, the certificate (e.g., that may be received at <NUM>) may be sent to the MIP to prove that the M2M application owner may be an actual owner of the subject M2M unit. Additionally (e.g., as shown at <NUM>), at least one or more of the following information may be transferred to the MIP: the network identifier, URIK/AS address of the application owner key and/or authorization server K/AS, a unique reference, H(PuK/AS) (e.g., a reference that may be based on a public key associated with K/AS), to a raw public key or root certificate of the K/AS, and/or the like. According to an example, a private key may also be provided and/or used including, for example, as a private key part of PPkM2M (e.g., PrM2M).

In an example, at <NUM>, the MIP store the information such as the network identifier, URIK/AS address of the application owner key and/or authorization server K/AS, a unique reference, H(PuK/AS), to a raw public key or root certificate of the K/AS, and/or the like (e.g., transferred at <NUM>). In an example, the information may be stored together with the record of the M2M with PID and the K/AS may store the reference to PPkM2M at the PID M2M record.

As shown in <FIG>, at <NUM> (e.g., at M2M first time device deployment, for example, directly after the M2M unit may have full Internet access for the first time), at least one or more of the following may be performed or may take place. For example (e.g., at 6a), the M2M unit may use the URI of MIP to determine and contact the MIP it may belong to or be associated with. Additionally (e.g., using the PIM), the M2M unit and the MIP establish a secure DTLS connection (e.g., at 6b). In an example (e.g., at 6c), the MIP may determine and/or look up a record of the M2M unit and the information transferred such as such as the network identifier, URIK/AS address of the application owner key and/or authorization server K/AS, a unique reference, H(PuK/AS), to a raw public key or root certificate of the K/AS, and/or the like (e.g., shown at <NUM>).

The M2M unit (e.g., <NUM>) may use the information (e.g., received at 6a) to determine or look up the K/AS and establish a secure DTLS connection with the K/AS (e.g., at 6d). The M2M unit may be authenticated in the DTLS handshake using the M2M public key reference received (e.g., at <NUM>) and the corresponding private keys in the PMI and K/AS respectively.

According to an example (e.g., at 6e), the M2M unit may use a secure challenge response protocol to make sure that the K/AS may have knowledge of the device manufacture key MKM2M. In one example (e.g., if the challenge response may fail), the M2M unit may abort the registration process with an error message or the procedure may be continued, but the device owner (e.g., via an output or indication on the M2M unit) may be warned that the MIP may be trying to compromise the M2M unit.

A unique ID for the M2M unit may be selected or chosen (e.g., at 6f) by the K/AS (or it may keep its old PID). Further (e.g., at 6f), the IP address such as IPv6 or IPV4 of the M2M units may be recorded by the K/AS and stored together with the M2M ID and the rest of the M2M information in a suitable database or storage component.

According to an example, the M2M unit may support one or more IMs (e.g., <NUM>) including multiple IMs and (e.g., at <NUM>) the key material, and/or the like that may be used customize (e.g., fully customize a new IM may be transferred from the K/AS to the M2M unit) based on one or more of the following. In an example (e.g., if the "on board" key generation example may be used), the key reference may also be transferred back to the K/AS. Additionally (e.g., if multiple IMs may not be supported), this information may replace the old PIM on the M2M unit in the IM (e.g., <NUM>).

For example, to customize, a private and public key of a public key pair, Pk'M2M = {Pr'M2M, Pu'M2M}, may be used to secure identify the M2M unit (or in an alternative or additional example this information may be generated "on board" the M2M unit and then the public key or a unique reference to this public key may be transferred to the K/AS) (e.g., as shown at 6gi). The Pk'M2M may be a second (e.g., a final customization) M2M unit private public key pair where, for example, Pu'M2M may be a public key part of Pk'M2M and Pr'M2M may be a private key part of Pk'M2M.

Further (e.g., as shown at 6gii), a hash or complete raw public keys of K/AS and the other entities that may utilize the service may be sent or provided to the M2M unit, for example, within the application domain to customize. According to an example (e.g., if the number of entities within the domain may be large), a root certification such as a traditional root certificate of the K/AS may be transferred.

According to an example (e.g., at 6giii), a unique permanent identifier ID in the form of a secure one-way hash of the M2M public key, ID = H(Pu'M2M) and/or (e.g., at 6giv) permanent URI (or other network address) of the K/AS may be provided to the M2M unit or sent thereto, for example, for customization.

The M2M unit may be configured (e.g., at <NUM>) for the particular M2M application domain with application specific configuration information and SW. In an example, this information is transferred protected under the established DTLS connection.

According to an example (e.g., when the end user application server or user device may want to communicate with a certain M2M unit), the application or user device may determine or look up its address and may contact the K/AS as shown in <FIG>, for example, at <NUM>. In examples herein, the K/AS and the application server or user device may be one entity or the same physical unit and/or as described herein separate entities. According to an example, the K/AS may further or also function as a M2M unit discovery server that may be used to find a certain service or particular M2M unit. The application or user device may also receive or get a unique reference to the raw public key material that may be used by the M2M for secure communication and/or, in an example (e.g., optionally), an authorization token from the K/AS that used to get access to particular services provided by the M2M unit (e.g., at <NUM>).

The end user application server or user device (e.g., <NUM> at <NUM>) may contact or communicate with the M2M and may set up a secure DTLS connection with the M2M unit with mutual authentication. The M2M unit may use the credential information (e.g., received at 6f) for this authentication while the end user application server or user device may use the M2M credential information (e.g., obtained at <NUM>).

In an example, ID module protection may be provided for provisioning as described herein. For example, an aspect of the examples herein may be how the IM in the M2M unit actually may be provided. As described herein, the IM may be be protected from internal SW attacks as well as from network based attacks in order to not compromise the long term M2M secret that may be used to securely identify the M2M unit and to set up secure connections with external entities. This may indicate or imply that a secure execution environment may be available where the IM application may run. In examples herein, there may be different implementation options for such ID module protection.

According to an example (e.g., in an first implementation), a traditional OS may be used. For example, the IM may be run (e.g., directly) upon a standard operation system such as Linux, iOS, Windows Unix or a real time OS such as FreeRTOS and/or the like as a native application. This example may be shown in <FIG>. The IM <NUM> may use one or more isolation properties offered by a standard OS kernel <NUM> and a secure boot process (is this the boot SW in <FIG>) of the complete OS and this secure boot process may be used to protect the IM from modification at system start-up. For example, the IM <NUM> may be part of a trusted computing base separate from the M2M application system <NUM> (e.g., that may include applications <NUM> and/or the application framework <NUM>) that may be non-trusted. The TCB may include the IM <NUM>, the OS kernel <NUM>, one or more hardware components (e.g., such as <NUM>, <NUM>, <NUM>, and/or the like as shown in <FIG>) of the M2M unit or device (e.g., <NUM>) and a secure boot <NUM> for software. Being part of the TCB as shown may enable protection of the IM from modification in one or more examples herein. Using this example may be cheaper as standard software and hardware may be used and it may be easily provided on multiple systems. On the other hand, the security level may not be a high (e.g., it may not be particularly high) as a trusted computing base (TCB) may be larger. In this example, it may also be easier to provide multiple different IM instances on the system. The different IM instances may be protected by the ordinary OS kernel isolation techniques or methods.

In an example (e.g., in a second implementation), TrustZone may be used. For example, an ARM TrustZone (TZ) technology may be used. The ARM TZ technology may be a system on chip (SoC) based secure isolation mechanism that may enable or allow running security critical applications in dedicated execution environment (e.g., a secure world). The applications running in the secure world may be reached by the applications in the non-secure world through a dedicated hardware protected API. The TCB may be smaller and may use a secure boot process of the secure world in addition to adapted SoC hardware. This example may be possible for system with SoC TZ support where, for example, adaptation of SoC hardware peripherals may be used give the promised security level. In a TZ system, in an example, the IM may be run as a dedicated application in in the secure world as shown in <FIG>. For example, the IM <NUM> may be part of a trusted computing base separate from the M2M application system <NUM> (e.g., that may include applications <NUM> and/or the application framework <NUM>) and/or an OS <NUM> that may be non-trusted. The TCB may include the IM <NUM>, a mini OS <NUM>, one or more hardware components that may support ARM TZ in an example (e.g., such as <NUM>, <NUM>, <NUM>, and/or the like as shown in <FIG>) of the M2M unit or device (e.g., <NUM>) and a secure boot <NUM> for software. According to an example (e.g., given that a min-OS with better or improved separation properties may be provided), this example may enable or allow running multiple parallel IMs on a single system.

According to another or additional example (e.g., a third implementation), virtualization-based IM module protection may be used. For example, the IM may be run in a dedicated Virtual Machine (VM) that may be protected from the rest of the system through the isolation properties provided by a virtualization layer such as a hypervisor or separation kernel. This principle may be illustrated in <FIG>. For example, the IM <NUM> may be part of a trusted computing base separate from the M2M application system <NUM> (e.g., that may include applications <NUM> and/or the application framework <NUM>) and/or an OS <NUM> that may be non-trusted. The TCB may include the IM <NUM>, a mini OS <NUM>, a hypervisor <NUM>, one or more hardware components (e.g., such as <NUM>, <NUM>, <NUM>, and/or the like as shown in <FIG>) of the M2M unit or device (e.g., <NUM>) and a secure boot <NUM> for software. In this example, the M2M applications may be running in a dedicated VM and the IM application in another VM. The hypervisor may provide the IM API through RPC calls or though the offering of share memory buffers from the none-secure VM to the secure VM. According to an example, the security of the system may be dependent on a secure boot process of the hypervisor layer as well as the whole VM where the IM may be running as well as the IM itself. Multiple, isolated IM applications may be be provided by running them in different protected (e.g., by the hypervisor) VMs. This may be an example that may provide a higher level of security and may be implemented resource constraint devices without TZ support (e.g., devices with memory management unit (MMU) and/or memory protection unit (MPU) support).

Further, in an example (e.g., a fourth implementation), a dedicated hardware module may be use for IM protection. For example, the IM may be run on a dedicated special purpose hardware module such as smart card or an SoC specific secure element as shown in <FIG>. For example, the IM <NUM> may be part of a trusted computing base separate from the M2M application system <NUM> (e.g., that may include applications <NUM> and/or the application framework <NUM>), an OS <NUM>, one or more hardware components (e.g., such as <NUM>, <NUM>, <NUM>, and/or the like as shown in <FIG>) of the M2M unit or device (e.g., <NUM>) and a boot <NUM> for software that may be non-trusted. The TCB may include the IM <NUM>, a mini OS <NUM>, a hypervisor <NUM>, and/or a secure hardware element (e.g., that may include one of <NUM>, <NUM>, <NUM>, and/or the like as shown in <FIG> with one or more of the other hardware components bing non-trusted) of the M2M unit or device (e.g., <NUM>). This example in <FIG> may isolate the IM (e.g., completely) from the potential hostile general system and the communication that may be allowed from the M2M application to the IM module may be the communication that may be given by the hardware interface to the secure element. Depending on the hardware capabilities (e.g., the MMU, MPU, and/or the like) of the secure element, it may be possible to run multiple different IM instances on the system or not. In an example, a drawback may include the extra secure element hardware cost for the M2M unit.

<FIG> illustrate example systems in which one or more of the examples herein may be implemented. As shown in <FIG>, one or more examples herein may be implemented in a garden equipment system <NUM>. In such an example, a piece of garden equipment may be a M2M unit or device as described herein (e.g., <NUM>). At <NUM>, the garden equipment (e.g., as shown as a hedge trimmer) may be set up with a software flash in factory such that the equipment may be equipped with software based preliminary credentials, PMI, as described herein. The PMI information may be (e.g., at the same time) sent to an independent third party registration service (e.g., such as the MIP <NUM>).

At <NUM> (e.g., when a reseller sells the equipment to an end-customer), the reseller (e.g., at the same time) may register a unique reference to the PMI of the reseller together with customer information (e.g., may include information) in its customer and device key database (e.g., <NUM>).

At <NUM>, the equipment may then be registered as "belonging" to the subject reselling organization through a registration request at the third party registration service.

At <NUM> (e.g., when the customer for the first time may use the new equipment or hedge trimmer, the equipment may connect (e.g., automatically) to the Internet. The equipment (e.g., upon connecting) may determine or looks up the third party registration service and may receive or credential information for connecting to the reselling management system key server for long-term credentials provisioning (e.g., the MI) as described herein.

The equipment may use the information sent and received at <NUM> to securely connect to the reselling organization's key server (e.g., <NUM>) to receive a long term device credentials such as the MI at <NUM>.

At <NUM>, the equipment may (e.g., securely and/or regularly) connect to a reselling organization's maintenance service that may provide device status so that the reselling organization may assist the customer with maintenance and device repair requests and help. The may is authenticated using the MI credentials stored at the key server in the reselling domain as described herein.

As shown in <FIG>, one or more examples herein may be implemented in a video surveillance system <NUM>. In such an example, a video surveillance camera may be a M2M unit or device as described herein (e.g., <NUM>). At <NUM>, the camera may be set up with a software flash in factory such that the camera may be equipped with software based preliminary credentials, PMI, as described herein. The PMI information may be (e.g., at the same time) sent to an independent third party registration service (e.g., such as the MIP <NUM>).

At <NUM> (e.g., when a security system integrator may acquire the camera), a system integrator (e.g., at the same time) may register a unique reference to the PMI in a building automation back-end system and/or equipment database (e.g., which may be responsible for managing the camera).

In an example, at <NUM>, the camera may then be registered as "belonging" to the subject building automation system that may use the camera through a registration request at the third party registration service (e.g., <NUM>).

At <NUM> (e.g., when the system integrator may install the new camera), the camera may (e.g., automatically) connect to the Internet. The camera (e.g., upon connecting) may determine or looks up a third party registration service and may receive credential information for connecting to the building automation key server (e.g., <NUM>) for long-term credentials provisioning.

At <NUM>, the camera may use the information received (e.g., at <NUM>) to securely connect to the building automation key server to receive long term device credentials such as MI.

The back-end system and/or the camera therein or associated therewith may use the long term credentials, MI, to securely remotely manage the video camera and/or to send real-time video data over a secure channel between the camera and the back end system.

<FIG> depicts a diagram of an example communications system <NUM> in which one or more disclosed embodiments may be implemented.

As shown in <FIG>, the communications system <NUM> may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU <NUM>), a radio access network (RAN) <NUM>/<NUM>/<NUM>, a core network <NUM>/<NUM>/<NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, and/or 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, and/or 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

The communications systems <NUM> may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and/or 102d to facilitate access to one or more communication networks, such as the core network <NUM>/<NUM>/<NUM>, the Internet <NUM>, and/or the networks <NUM>. By way of example, the base stations 114a and/or 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like.

The base station 114a may be part of the RAN <NUM>/<NUM>/<NUM>, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

The base stations 114a and/or 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, and/or 102d over an air interface <NUM>/<NUM>/<NUM>, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface <NUM>/<NUM>/<NUM> may be established using any suitable radio access technology (RAT).

For example, the base station 114a in the RAN <NUM>/<NUM>/<NUM> and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface <NUM>/<NUM>/<NUM> using wideband CDMA (WCDMA).

In another embodiment, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface <NUM>/<NUM>/<NUM> using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement radio technologies such as IEEE <NUM> (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard <NUM> (IS-<NUM>), Interim Standard <NUM> (IS-<NUM>), Interim Standard <NUM> (IS-<NUM>), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

Thus, the base station 114b may not be required to access the Internet <NUM> via the core network <NUM>/<NUM>/<NUM>.

The RAN <NUM>/<NUM>/<NUM> may be in communication with the core network <NUM>/<NUM>/<NUM>, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and/or 102d. For example, the core network <NUM>/<NUM>/<NUM> may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in <FIG>, it will be appreciated that the RAN <NUM>/<NUM>/<NUM> and/or the core network <NUM>/<NUM>/<NUM> may be in direct or indirect communication with other RANs that employ the same RAT as the RAN <NUM>/<NUM>/<NUM> or a different RAT. For example, in addition to being connected to the RAN <NUM>/<NUM>/<NUM>, which may be utilizing an E-UTRA radio technology, the core network <NUM>/<NUM>/<NUM> may also be in communication with another RAN (not shown) employing a GSM radio technology.

The core network <NUM>/<NUM>/<NUM> may also serve as a gateway for the WTRUs 102a, 102b, 102c, and/or 102d to access the PSTN <NUM>, the Internet <NUM>, and/or other networks <NUM>. For example, the networks <NUM> may include another core network connected to one or more RANs, which may employ the same RAT as the RAN <NUM>/<NUM>/<NUM> or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, and/or 102d in the communications system <NUM> may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, and/or 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.

<FIG> depicts a system diagram of an example WTRU <NUM>. As shown in <FIG>, the WTRU <NUM> may include a processor <NUM>, a transceiver <NUM>, a transmit/receive element <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display/touchpad <NUM>, non-removable memory <NUM>, removable memory <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and other peripherals <NUM>. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in <FIG> and described herein.

While <FIG> depicts the processor <NUM> and the transceiver <NUM> as separate components, it may be appreciated that the processor <NUM> and the transceiver <NUM> may be integrated together in an electronic package or chip.

The transmit/receive element <NUM> may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface <NUM>/<NUM>/<NUM>.

Thus, in one embodiment, the WTRU <NUM> may include two or more transmit/receive elements <NUM> (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface <NUM>/<NUM>/<NUM>.

<FIG> depicts a system diagram of the RAN <NUM> and the core network <NUM> according to an embodiment. As noted above, the RAN <NUM> may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface <NUM>. As shown in <FIG>, the RAN <NUM> may include Node-Bs 140a, 140b, and/or 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface <NUM>. The Node-Bs 140a, 140b, and/or 140c may each be associated with a particular cell (not shown) within the RAN <NUM>. The RAN <NUM> may also include RNCs 142a and/or 142b. It will be appreciated that the RAN <NUM> may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

As shown in <FIG>, the Node-Bs 140a and/or 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, and/or 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, and/or 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

The MSC <NUM> and the MGW <NUM> may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN <NUM>, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices.

The SGSN <NUM> and the GGSN <NUM> may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet <NUM>, to facilitate communications between and the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

<FIG> depicts a system diagram of the RAN <NUM> and the core network <NUM> according to an embodiment. As noted above, the RAN <NUM> may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface <NUM>.

The RAN <NUM> may include eNode-Bs 160a, 160b, and/or 160c, though it will be appreciated that the RAN <NUM> may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and/or 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface <NUM>. In one embodiment, the eNode-Bs 160a, 160b, and/or 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

Each of the eNode-Bs 160a, 160b, and/or 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in <FIG>, the eNode-Bs 160a, 160b, and/or 160c may communicate with one another over an X2 interface.

The MME <NUM> may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN <NUM> via an S1 interface and may serve as a control node. For example, the MME <NUM> may be responsible for authenticating users of the WTRUs 102a, 102b, and/or 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and/or 102c, and the like. The MME <NUM> may also provide a control plane function for switching between the RAN <NUM> and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

The serving gateway <NUM> may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN <NUM> via the S1 interface. The serving gateway <NUM> may generally route and forward user data packets to/from the WTRUs 102a, 102b, and/or 102c. The serving gateway <NUM> may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and/or 102c, managing and storing contexts of the WTRUs 102a, 102b, and/or 102c, and the like.

The serving gateway <NUM> may also be connected to the PDN gateway <NUM>, which may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet <NUM>, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

For example, the core network <NUM> may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN <NUM>, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. In addition, the core network <NUM> may provide the WTRUs 102a, 102b, and/or 102c with access to the networks <NUM>, which may include other wired or wireless networks that are owned and/or operated by other service providers.

<FIG> depicts a system diagram of the RAN <NUM> and the core network <NUM> according to an embodiment. The RAN <NUM> may be an access service network (ASN) that employs IEEE <NUM> radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface <NUM>. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, and/or 102c, the RAN <NUM>, and the core network <NUM> may be defined as reference points.

As shown in <FIG>, the RAN <NUM> may include base stations 180a, 180b, and/or 180c, and an ASN gateway <NUM>, though it will be appreciated that the RAN <NUM> may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and/or 180c may each be associated with a particular cell (not shown) in the RAN <NUM> and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface <NUM>. In one embodiment, the base stations 180a, 180b, and/or 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, and/or 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway <NUM> may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network <NUM>, and the like.

The air interface <NUM> between the WTRUs 102a, 102b, and/or 102c and the RAN <NUM> may be defined as an R1 reference point that implements the IEEE <NUM> specification. In addition, each of the WTRUs 102a, 102b, and/or 102c may establish a logical interface (not shown) with the core network <NUM>. The logical interface between the WTRUs 102a, 102b, and/or 102c and the core network <NUM> may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

The communication link between each of the base stations 180a, 180b, and/or 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, and/or 180c and the ASN gateway <NUM> may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, and/or 102c.

The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and/or 102c to roam between different ASNs and/or different core networks. The MIP-HA <NUM> may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet <NUM>, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices. The AAA server <NUM> may be responsible for user authentication and for supporting user services. The gateway <NUM> may facilitate interworking with other networks. For example, the gateway <NUM> may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN <NUM>, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. In addition, the gateway <NUM> may provide the WTRUs 102a, 102b, and/or 102c with access to the networks <NUM>, which may include other wired or wireless networks that are owned and/or operated by other service providers.

Although not shown in <FIG>, it should, may, and/or will be appreciated that the RAN <NUM> may be connected to other ASNs and the core network <NUM> may be connected to other core networks. The communication link between the RAN <NUM> the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and/or 102c between the RAN <NUM> and the other ASNs.

Although the terms device, UE, or WTRU may be used herein, it may and should be understood that the use of such terms may be used interchangeably and, as such, may not be distinguishable.

Claim 1:
A method associated with a M2M application provider, comprising:
receiving a unique reference to a preliminary M2M ID, PMI, of a M2M device; and
registering the M2M device at a M2M ID provider, MIP, by using an application key and authorization service, K/AS;
replacing the PMI with a M2M ID, MI, wherein the MI is generated by the MIP;
sending, to the K/AS, a session request associated with the MI;
receiving, from the K/AS, an identifier associated with the MI; and
establishing secure communication with the M2M device using the identifier.