Patent Description:
Digital identities are used, amongst others, for authentication, setting up secure communication channels, and for proving ownership of data. To create a digital identity, henceforth just referred to as identity, an issuer of the identity could link a cryptographic key as a credential to an identifier. This identifier can be a number, a text string, or any other digital representation of an element of a namespace, the set of all possible identifiers. A well-known example is a Public-Key Infrastructure (PKI) where the identities are the issued certificates, where the credentials are some public-key cryptographic key pairs, e.g. using the Rivest-Shamir-Adleman (RSA) public cryptosystems. Identifiers in a PKI are commonly the subject name that the certificate carries, but also other fields in a certificate can be used as the identifier.

While PKIs are well-known and widely used, for example, when using Transport Layer Security (TLS) connections to realize secure connections between a terminal device, such as a mobile phone, and a server, identities that are using symmetric key cryptosystems are widely used too. In fact, such symmetric key identities are, for example, used and are mandatory to support in the second, third, fourth, and fifth generation mobile network systems as standardized by the 3rd Generation Partnership Project (3GPP).

Compared to public-key cryptosystems, the symmetric key cryptosystems are faster and require keys of smaller sizes than keys used in the public-key cryptosystems. This is attractive for use in battery driven devices, such as mobile phones, and, particularly, constraint Internet of Things (IoT) devices.

However, for symmetric key cryptosystems the verifier (i.e., the entity that is to verify an identity of another entity) needs the same key as the prover (i.e., the entity that claims to have a said identity). But if the verifier has the same key, then the verifier can easily impersonate the prover. Hence, the prover must trust the verifier to not use or disclose this key it shares with the prover. Furthermore, the key management of symmetric keys does not allow the key to be shared from the prover to verifier during the system setup.

Most commonly used public-key cryptosystems are insecure when confronted with an attacker using a quantum computer. But symmetric key cryptosystems are known to be robust against being attacked by an attacker having access to a quantum computer. In the worst case, the prover has to switch to a scheme using a larger key size.

One issue with identities symmetric cryptosystems is the fact that the verifier must have the same key as used by the prover when proving the verifier is in possession of the secret key. Furthermore, the key must be securely made available at/to the verifier when needing it in, say, an authentication or identification process. Transporting the key to a verifier via an encrypted channel assumes there is already a key in place between the prover and the verifier. The latter might in certain setups be useful but, in general, there could be scenarios in which it is beneficial to not require that the verifier and the prover already have keys available from the start.

The above issues limit the possibility to be a verifier as it forces the prover to have different keys for each verifier. For example, in a system with N entities that all can act as provers and verifiers, the number of keys needed would be N·(N-<NUM>)/<NUM>, which is forbiddingly large when the value of N grows, as would be the case with billions of constrained devices that have limited storage capabilities.

Hence, there is still a need for improved mechanisms for authentication of devices.

<CIT> discloses an OEM authenticating a second circuit copy using a first circuit copy and a challenge/response protocol.

<CIT> discloses a secure programming system and method for provisioning and programming a target payload into a programmable device mounted in a programmer. The programmable device can be authenticated before programming to verify the device is a valid device produced by a silicon vendor.

<CIT> discloses a "factory mode" for a device, the "factory mode" allowing the device to execute untrusted operating system code, such as unsigned operating system code and operating system code that has been signed, but the certificate authority is not trusted.

An object of embodiments herein is to provide mechanisms that enable efficient authentication of an OEM as manufacturer of a communication device. The present invention is defined by the claims appended hereto.

According to a first aspect there is presented a method for authenticating an OEM entity as manufacturer of a communication device comprising an identification module. The method is performed by a network entity. The method comprises providing, towards the identification module, a challenge of a challenge-response authentication procedure. The method comprises obtaining, from the identification module, a first response of the challenge-response authentication procedure. The method comprises providing, towards the OEM entity and upon having obtained the response, the challenge. The method comprises obtaining, from the OEM entity, a second response of the challenge-response authentication procedure. The method comprises authenticating the OEM entity as the manufacturer of the communication device only when the second response matches the first response.

According to a second aspect there is presented a network entity for authenticating an OEM entity as manufacturer of a communication device comprising an identification module. The network entity comprises processing circuitry. The processing circuitry is configured to cause the network entity to provide, towards the identification module, a challenge of a challenge-response authentication procedure. The processing circuitry is configured to cause the network entity to obtain, from the identification module, a first response of the challenge-response authentication procedure. The processing circuitry is configured to cause the network entity to provide, towards the OEM entity and upon having obtained the response, the challenge. The processing circuitry is configured to cause the network entity to obtain, from the OEM entity, a second response of the challenge-response authentication procedure. The processing circuitry is configured to cause the network entity to authenticate the OEM entity as the manufacturer of the communication device only when the second response matches the first response.

According to a third aspect there is presented a computer program for authenticating an OEM entity as manufacturer of a communication device comprising an identification module. The computer program comprises computer program code which, when run on processing circuitry of a network entity, causes the network entity to perform a method according to the first aspect.

According to a fourth aspect there is presented a computer program product comprising a computer program according to the third aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium can be a non-transitory computer readable storage medium. identification module, causes the identification module to perform a method according to the fourth aspect.

According to a seventh aspect there is presented a method for authenticating an OEM entity as manufacturer of a communication device comprising an identification module. The method is performed by the OEM entity. The method comprises obtaining, from a network entity, a challenge of a challenge-response authentication procedure. The method comprises providing, towards the network entity, a second response of the challenge-response authentication procedure.

According to an eight aspect there is presented an OEM entity for authenticating the OEM entity as manufacturer of a communication device comprising an identification module. The OEM entity comprises processing circuitry. The processing circuitry is configured to cause the OEM entity to obtain, from a network entity, a challenge of a challenge-response authentication procedure. The processing circuitry is configured to cause the OEM entity to provide, towards the network entity, a second response of the challenge-response authentication procedure.

According to a tenth aspect there is presented a computer program for authenticating an OEM entity as manufacturer of a communication device comprising an identification module. The computer program comprises computer program code which, when run on processing circuitry of the OEM entity, causes the OEM entity to perform a method according to the seventh aspect.

According to an eleventh aspect there is presented a computer program product comprising a computer program according to at least one of the third aspect, the sixth aspect, and the tenth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium can be a non-transitory computer readable storage medium.

Advantageously these methods, this network entity, this identification module, this OEM entity, these computer programs, and this computer program product provide efficient authentication of the OEM entity as manufacturer of the communication device.

Advantageously these methods, this network entity, this identification module, this OEM entity, these computer programs, and this computer program product are efficient for constrained communication devices that have limited computation and storage capabilities.

In view of the above there is need for symmetric cryptography based identities that are easily manageable and for which there exist an identity issuance process and key infrastructure that avoids the above issues. The herein disclosed embodiments provide a framework in which a device owner can authenticate and bind a device manufacturer to a specific device based on a symmetric key infrastructure. In this respect, the Authentication Key Agreement (AKA) procedures of current 3GPP technologies for wireless communication support symmetric key based authentication towards a tamper resistant identity module that holds the credentials. But there is no means to establish in which device the identity module is used.

<FIG> is a schematic diagram illustrating a system <NUM> where embodiments presented herein can be applied. The system <NUM> comprises a communication device <NUM>. There could be different types of communication devices <NUM>. Examples include, but are not limited to, portable wireless devices, mobile stations, mobile phones, handsets, wireless local loop phones, user equipment (UE), smartphones, laptop computers, tablet computers, network equipped vehicles, network equipped sensors, and IoT devices.

The communication device <NUM> comprises an identification module <NUM>. The identification module <NUM> has been manufactured by a manufacturing entity <NUM> (in <FIG> denoted "EUM" being short for eUICC manufacturer, thus representing an illustrative example where the identification module <NUM> is an embedded UICC (eUICC). There could be different examples of identification modules <NUM>. In some examples the identification module <NUM> is part of, or implemented on, a Trusted Execution Environment (TEE). In particular, in some aspects the identification module <NUM> is a Universal Integrated Circuit Card (UICC), such as an eUICC or an integrated UICC (iUICC). That is, the TEE could be realized as any type of UICC, such as an eUICC or an iUICC (or a traditional UICC).

The system <NUM> further comprises an original equipment manufacturer OEM entity <NUM> claiming to have manufactured the communication device <NUM>. The authenticity of the OEM entity <NUM> as true manufacturer of the communication device <NUM> is assumed to be verified by a network equipment (NE) <NUM>. The network equipment <NUM> could be managed by, executed by, integrated with, collocated with, or part of, a mobile network operator (MNO) entity 200b or a device owner entity 200a. Thus, in some aspects the network entity <NUM> is a device owner entity 200a or an MNO entity 200b.

The system <NUM> further comprises a ledger <NUM> as representing any sort of external data register and storage.

In some aspects, the herein disclosed embodiments proposes to use mechanisms according to which the credential, stored in the identification module <NUM> of the communication device <NUM>, is used as a basis for authentication of the OEM entity <NUM> of the communication device <NUM> comprising the identification module <NUM>. This allows a device owner entity 200a to in a reliable manner establish that this particular OEM entity <NUM> has indeed produced this particular communication device <NUM> comprising this particular identification module <NUM>. Furthermore, the MNO that operates the network has, by means of the MNO entity 200b, the ability to perform a trustworthy verification that the credentials used in the identity for network access are securely stored. The MNO can thus verify that there is no risk that the communication device <NUM> will leak the secret, which would ruin the ability to identify securely the subscriber that operates the communication device <NUM>.

The embodiments disclosed herein in particular relate to mechanisms for authenticating an OEM entity <NUM> as manufacturer of a communication device <NUM> comprising an identification module <NUM>. In order to obtain such mechanisms there is provided a network entity <NUM>, a method performed by the network entity <NUM>, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the network entity <NUM>, causes the network entity <NUM> to perform the method. In order to obtain such mechanisms there is further provided an identification module <NUM>, a method performed by the identification module <NUM>, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the identification module <NUM>, causes the identification module <NUM> to perform the method. In order to obtain such mechanisms there is further provided an OEM entity <NUM>, a method performed by the OEM entity <NUM>, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the OEM entity <NUM>, causes the OEM entity <NUM> to perform the method.

Reference is now made to <FIG> illustrating a method for authenticating an OEM entity <NUM> as manufacturer of a communication device <NUM> comprising an identification module <NUM> as performed by the network entity <NUM> according to an embodiment.

The network entity <NUM> contacts the identification module <NUM> and requests the identification module <NUM> to respond to a challenge. Particularly, the network entity <NUM> is configured to perform step S104:
S104: The network entity <NUM> provides, towards the identification module <NUM>, a challenge of a challenge-response authentication procedure.

It is assumed that the identification module <NUM> responds to the challenge. Hence, the network entity <NUM> is configured to perform step S106:
S106: The network entity <NUM> obtains, from the identification module <NUM>, a first response of the challenge-response authentication procedure.

The network entity <NUM> contacts the OEM entity <NUM> and requests the OEM entity <NUM> to respond to the same challenge. Particularly, the network entity <NUM> is configured to perform step S108:
S108: The network entity <NUM> provides, towards the OEM entity <NUM> and upon having obtained the response, the challenge.

It is assumed that the OEM entity <NUM> responds to the challenge. Hence, the network entity <NUM> is configured to perform step S110:
S110: The network entity <NUM> obtains, from the OEM entity <NUM>, a second response of the challenge-response authentication procedure.

The network entity <NUM> has thus obtained two responses to the challenge; a first response from the identification module <NUM> and a second response from the OEM entity <NUM>. The authenticity of the OEM entity <NUM> can then be verified by comparing the second response to the first response. Particularly, the network entity <NUM> is configured to perform step S112:
S112: The network entity <NUM> authenticates the OEM entity <NUM> as the manufacturer of the communication device <NUM> only when the second response matches the first response.

Thus, the authentication fails when the second response fails to match the first response.

Embodiments relating to further details of authenticating the OEM entity <NUM> as manufacturer of the communication device <NUM> comprising the identification module <NUM> as performed by the network entity <NUM> will now be disclosed.

In some aspects the challenge in step S104 is only provided towards the identification module <NUM> when the network entity <NUM> has verified that the identification module <NUM> has been provisioned. Particularly, according to an embodiment the network entity <NUM> is configured to perform (optional) step S102:
S102: The network entity <NUM> obtains a verification of network provisioning of the identification module <NUM>. The challenge is then only provided towards the identification module <NUM> upon the network entity <NUM> having obtained the verification.

There could be different types of verifications for the network entity <NUM> to obtain. In some aspects the network provisioning of the identification module <NUM> is defined by that a key, K_OEM, has been provisioned for the communication device <NUM>. Particularly, according to an embodiment the verification is obtained by querying a ledger <NUM> that the key K_OEM has been provisioned for the communication device <NUM>. Further in this respect, the manufacturing entity <NUM> might publish in the ledger <NUM> that the identification module <NUM> has been provisioned with a key for a specific OEM string. Further in this respect, although a ledger <NUM> is used as an example where data can be stored, parts or all data can be stored elsewhere, i.e. not in the ledger <NUM> itself, and then the ledger <NUM> only will store a secure fingerprint, e.g. a cryptographic hash, such as Secure Hash Algorithm <NUM> (SHA-<NUM>) or the like, of the data that is stored elsewhere. When the identification module <NUM> is provided as an iUICC, the OEM entity <NUM> might also assume the role of manufacturing entity <NUM>.

In some aspects the challenge is accompanied by OEM specific data. The first response is then based on the OEM specific data. There could be different examples of OEM specific data.

In general terms, the OEM specific data is associated with, or coupled to, the OEM entity <NUM>. That is, the OEM specific data identifies a particular OEM and is hence unique for all OEM entities <NUM> for this particular OEM. In some non-limiting examples the OEM specific data relates to any of: the name, or other types of identity, of the MNO entity <NUM>, a serial number of the communication device <NUM> (as provided by the MNO entity <NUM>), Mobile Country Code (MCC) and Mobile Network Code (MNC) of the OEM, organization number of the OEM, Fully Qualified Domain Name (FQDN) of the OEM, name of production site, address or other contact information of the OEM, device model number or type of the communication device <NUM>.

In some aspects, when the network entity <NUM> is an MNO entity 200b, the network entity <NUM> provides a network access key towards the identification module <NUM>. Particularly, according to an embodiment the network entity <NUM> is configured to perform (optional) step S114:
S114: The network entity <NUM> provides, towards the identification module <NUM>, a network access key upon having authenticated the OEM entity <NUM> as the manufacturer of the communication device <NUM>.

The network entity <NUM> could further request the identification module <NUM> to confirm delivery of the network access key.

There could be different examples of network access keys. According to some examples the network access key is an Authentication Key Agreement (AKA) symmetric credential, or an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) public-key credential.

Reference is now made to <FIG> illustrating a method for authenticating an OEM entity <NUM> as manufacturer of a communication device <NUM> comprising an identification module <NUM> as performed by the identification module <NUM> according to an embodiment.

As disclosed above, the network entity <NUM> provides a challenge towards the identification module <NUM>. It is assumed that the identification module <NUM> obtains the challenge. Thus the identification module <NUM> is configured to perform step S202:
S202: The identification module <NUM> obtains, from a network entity <NUM>, a challenge of a challenge-response authentication procedure.

It is assumed that the identification module <NUM> responds to the challenge. Particularly, the identification module <NUM> is configured to perform step S204:
S204: The identification module <NUM> provides, towards the network entity <NUM>, a first response of the challenge-response authentication procedure.

Embodiments relating to further details of authenticating the OEM entity <NUM> as manufacturer of the communication device <NUM> comprising the identification module <NUM> as performed by the identification module <NUM> will now be disclosed.

As disclosed above, in some aspects the challenge is accompanied by OEM specific data, and the first response is derived based on the OEM specific data. Different examples of OEM specific have been given above.

There could be different ways for the identification module <NUM> to derive the first response that is provided towards the network entity <NUM> in step S204.

In some aspects the identification module <NUM> derives a key K_OEM as part of deriving the first response. In some examples the key K_OEM is derived based on the OEM specific data and a long-term key K. The first response is then derived based on the key K_OEM and the challenge.

As disclosed above, in some aspects when the network entity <NUM> is an MNO entity 200b, the network entity <NUM> provides a network access key towards the identification module <NUM>. Particularly, according to an embodiment the identification module <NUM> is configured to perform (optional) step S206:
S206: The identification module <NUM> obtains, from the network entity <NUM>, a network access key upon having authenticated the OEM entity <NUM> as the manufacturer of the communication device <NUM>.

As disclosed above, the network access key could be an AKA symmetric credential, or an EAP-TLS public-key credential.

Reference is now made to <FIG> illustrating a method for authenticating an OEM entity <NUM> as manufacturer of a communication device <NUM> comprising an identification module <NUM> as performed by the OEM entity <NUM> according to an embodiment.

As disclosed above, the network entity <NUM> provides a challenge towards the OEM entity <NUM>. It is assumed that the OEM entity <NUM> obtains the challenge. Thus the OEM entity <NUM> is configured to perform step S302:
S302: The OEM entity <NUM> obtains, from a network entity <NUM>, a challenge of a challenge-response authentication procedure.

It is assumed that the OEM entity <NUM> responds to the challenge. Particularly, the OEM entity <NUM> is configured to perform step S304:
S304: The OEM entity <NUM> provides, towards the network entity <NUM>, a second response of the challenge-response authentication procedure.

Embodiments relating to further details of authenticating the OEM entity <NUM> as manufacturer of the communication device <NUM> comprising the identification module <NUM> as performed by the OEM entity <NUM> will now be disclosed.

There could be different ways for the OEM entity <NUM> to derive the second response that is provided towards the network entity <NUM> in step S304. In some aspects the OEM entity <NUM> derives the second response from the key K_OEM and the challenge. There could be different ways for the OEM entity <NUM> to obtain the key K_OEM. In some aspects the key K_OEM is obtained from the manufacturing entity <NUM> of the identification module <NUM>. Further in this respect, when the OEM entity <NUM> obtains, or provisions, the identification module <NUM> from the manufacturing entity <NUM>, the OEM entity <NUM> might also requests a key (i.e., the key K_OEM) as derived from the long term key K stored on the identification module <NUM>, where the key K_OEM is derived as K_OEM = KDF(K, "OEM string"), where KDF is a Key Derivation Function, and "OEM string" represents OEM specific data.

One particular embodiment for authenticating an OEM entity <NUM> as manufacturer of a communication device <NUM> comprising an identification module <NUM> based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagrams of <FIG>, <FIG>, <FIG>, and <FIG>.

Steps S400-S410 of <FIG> are performed as part of producing the identification module <NUM>.

S400: The manufacturing entity <NUM> generates a long--term key K for the identification module <NUM>.

S410: The manufacturing entity <NUM> provisions the identification module <NUM> with the key K.

Steps S500-S540 of <FIG> are performed as part of providing the identification module <NUM> from the manufacturing entity <NUM> to the OEM entity <NUM>.

S500: The OEM entity <NUM> requests a key from the manufacturing entity <NUM>.

S510: The manufacturing entity <NUM> derives the key K_OEM as K_OEM = KDF(K, "OEM string").

S520: The manufacturing entity <NUM> provisions the OEM entity <NUM> with the key K_OEM.

S530: The manufacturing entity <NUM> attests in a ledger <NUM> that the key K_OEM has been provisioned.

S540: The OEM entity <NUM> attests in the ledger <NUM> that the key K_OEM has been provisioned.

Steps S600-S690 of <FIG> are performed as part of authenticating the OEM entity <NUM> by the device owner entity 200a.

S600: The device owner entity 200a verifies that the identification module <NUM> has been provisioned by checking in the ledger <NUM> that the key K_OEM for the identification module <NUM> has been provisioned.

S610: The device owner entity 200a generates a challenge of a challenge-response authentication procedure.

S620: The device owner entity 200a provides the challenge and OEM specific data in the form of "OEM string" towards the identification module <NUM>.

S630: The identification module <NUM> derives K_OEM from the key K and the "OEM string" as K_OEM = KDF(K, "OEM string").

S640: The identification module <NUM> derives a first response to the challenge from the key K_OEM and the challenge as response = KDF(K_OEM, challenge).

S650: The identification module <NUM> provides the first response towards the device owner entity 200a.

S660: The device owner entity 200a provides the challenge towards the OEM entity <NUM>.

S670: The OEM entity <NUM> derives a second response to the challenge from the key K_OEM and the challenge as response' = MAC(K_OEM, challenge), where MAC is short for message authentication code.

S680: The OEM entity <NUM> provides the second response towards the device owner entity 200a.

S690: The device owner entity 200a verifies that the second response matches the first response. If there is a match between the responses the device owner entity 200a can be assured that the OEM entity <NUM> is indeed the true manufacturer of the communication device <NUM> comprising the identification module <NUM>.

Steps S700-S750 of <FIG> are performed as part of creating a network subscription by the device owner entity 200a with the MNO entity 200b.

S700: The device owner entity 200a registers the communication device <NUM> and the OEM entity <NUM> with the MNO entity 200b.

S710: The MNO entity 200b requests a key from the manufacturing entity <NUM>.

S720: The manufacturing entity <NUM> derives the key K_MNO as K_MNO = KDF(K, "MNO string") where "MNO string" represents MNO specific data.

S730: The manufacturing entity <NUM> provides the MNO entity 200b with the key K_MNO.

S740: The manufacturing entity <NUM> attests in a ledger <NUM> that the key K_MNO has been provisioned.

S750: The MNO entity 200b attests in the ledger <NUM> that the key K_MNO has been provisioned.

The OEM entity <NUM> is thereby enabled to authenticate that the communication device <NUM> is trustworthy and if so provision a network access key (which for a <NUM> system can be an AKA symmetric credential or an EAP-TLS public-key credential).

The MNO entity 200b is thereby enabled to establish a key, here referred to as the key K_MNO, that could be used for secure and integrity protected provision.

Steps S800-S880 of <FIG> are performed as part of providing the identification module <NUM> with a network access key from the MNO entity 200b.

S800: Steps S600-S680 are performed but involving the MNO entity 200b instead of the device owner entity 200a.

S810: The MNO entity 200b verifies that the second response matches the first response. If there is a match between the responses the MNO entity 200b can be assured that the OEM entity <NUM> is indeed the true manufacturer of the communication device <NUM> comprising the identification module <NUM>.

S820: The MNO entity 200b generates a message authentication code as mac =MAC(K_MNO_rand1), where rand1 is a random number.

S830: The MNO entity 200b provides "MNO string", rand1, mac, and ENC(K_MNO, K_access || rand2 (optional)) towards the identification module <NUM>, where ENC is short for encryption, where K_access is the network access key, and where "x||y" denotes the concatenation of strings x and y.

S840: The identification module <NUM> generates K_MNO as K_MNO = KDF(K, "MNO string").

S850: The identification module <NUM> verifies that the received mac is equal to MAC(K_MNO, rand1).

S860: The identification module <NUM> decrypts ENC(K_MNO, K_access || rand2 (optional)) and extracts K_access and rand2 (optionally).

S870: The identification module <NUM> provides a confirmation (by stating confirmation=OK) and ENC(K_access rand2(optional)) towards the MNO entity 200b.

S880 (optional): The MNO entity 200b checks the confirmation and extracts rand <NUM>.

The K_MNO can thereby be used in process for provisioning of K_access that follows the GSMA Remote Subscription Provisioning (RSP) protocol (where GSMA is short for GSM Association, and where GSM is short for Global system for Mobile communication), e.g. by providing the credentials needed in the RSP protocol.

The procedure for delivery of K_access can be adopted in case the implementation, or realization, of the identification module <NUM> is incapable of handling long messages. For example, the steps <NUM> to <NUM> could be broken up into smaller parts.

<FIG> schematically illustrates, in terms of a number of functional units, the components of a network entity <NUM> according to an embodiment. Processing circuitry <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210a (as in <FIG>), e.g. in the form of a storage medium <NUM>. The processing circuitry <NUM> may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry <NUM> is configured to cause the network entity <NUM> to perform a set of operations, or steps, as disclosed above. For example, the storage medium <NUM> may store the set of operations, and the processing circuitry <NUM> may be configured to retrieve the set of operations from the storage medium <NUM> to cause the network entity <NUM> to perform the set of operations. Thus the processing circuitry <NUM> is thereby arranged to execute methods as herein disclosed.

The network entity <NUM> may further comprise a communications interface <NUM> for communications with other entities, functions, nodes, modules, and devices. As such the communications interface <NUM> may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry <NUM> controls the general operation of the network entity <NUM> e.g. by sending data and control signals to the communications interface <NUM> and the storage medium <NUM>, by receiving data and reports from the communications interface <NUM>, and by retrieving data and instructions from the storage medium <NUM>. Other components, as well as the related functionality, of the network entity <NUM> are omitted in order not to obscure the concepts presented herein.

<FIG> schematically illustrates, in terms of a number of functional modules, the components of a network entity <NUM> according to an embodiment. The network entity <NUM> of <FIG> comprises a number of functional modules; a provide module 210b configured to perform step S204, an obtain module 210c configured to perform step S206, a provide module 210d configured to perform step S208, an obtain module 210e configured to perform step S210 and an authenticate module 210f configured to perform step S112. The network entity <NUM> of <FIG> may further comprise a number of optional functional modules, such as any of an obtain module 210a configured to perform step S102 and a provide module <NUM> configured to perform step S114. In general terms, each functional module 210a-<NUM> may be implemented in hardware or in software. Preferably, one or more or all functional modules 210a-<NUM> may be implemented by the processing circuitry <NUM>, possibly in cooperation with the communications interface <NUM> and the storage medium <NUM>. The processing circuitry <NUM> may thus be arranged to from the storage medium <NUM> fetch instructions as provided by a functional module 210a-<NUM> and to execute these instructions, thereby performing any steps of the network entity <NUM> as disclosed herein.

<FIG> schematically illustrates, in terms of a number of functional units, the components of an identification module <NUM> according to an embodiment. Processing circuitry <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210b (as in <FIG>), e.g. in the form of a storage medium <NUM>. The processing circuitry <NUM> may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry <NUM> is configured to cause the identification module <NUM> to perform a set of operations, or steps, as disclosed above. For example, the storage medium <NUM> may store the set of operations, and the processing circuitry <NUM> may be configured to retrieve the set of operations from the storage medium <NUM> to cause the identification module <NUM> to perform the set of operations. Thus the processing circuitry <NUM> is thereby arranged to execute methods as herein disclosed.

The identification module <NUM> may further comprise a communications interface <NUM> for communications with other modules, entities, functions, nodes, and devices. As such the communications interface <NUM> may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry <NUM> controls the general operation of the identification module <NUM> e.g. by sending data and control signals to the communications interface <NUM> and the storage medium <NUM>, by receiving data and reports from the communications interface <NUM>, and by retrieving data and instructions from the storage medium <NUM>. Other components, as well as the related functionality, of the identification module <NUM> are omitted in order not to obscure the concepts presented herein.

<FIG> schematically illustrates, in terms of a number of functional modules, the components of an identification module <NUM> according to an embodiment. The identification module <NUM> of <FIG> comprises a number of functional modules; an obtain module 310a configured to perform step S202 and a provide module 310b configured to perform step S204. The identification module <NUM> of <FIG> may further comprise a number of optional functional modules, such as an obtain module 310c configured to perform step S206. In general terms, each functional module 310a-310c may be implemented in hardware or in software. Preferably, one or more or all functional modules 310a-310c may be implemented by the processing circuitry <NUM>, possibly in cooperation with the communications interface <NUM> and the storage medium <NUM>. The processing circuitry <NUM> may thus be arranged to from the storage medium <NUM> fetch instructions as provided by a functional module 310a-310c and to execute these instructions, thereby performing any steps of the identification module <NUM> as disclosed herein.

<FIG> schematically illustrates, in terms of a number of functional units, the components of an OEM entity <NUM> according to an embodiment. Processing circuitry <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210c (as in <FIG>), e.g. in the form of a storage medium <NUM>. The processing circuitry <NUM> may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry <NUM> is configured to cause the OEM entity <NUM> to perform a set of operations, or steps, as disclosed above. For example, the storage medium <NUM> may store the set of operations, and the processing circuitry <NUM> may be configured to retrieve the set of operations from the storage medium <NUM> to cause the OEM entity <NUM> to perform the set of operations. Thus the processing circuitry <NUM> is thereby arranged to execute methods as herein disclosed.

The OEM entity <NUM> may further comprise a communications interface <NUM> for communications with other entities, functions, nodes, and devices. As such the communications interface <NUM> may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry <NUM> controls the general operation of the OEM entity <NUM> e.g. by sending data and control signals to the communications interface <NUM> and the storage medium <NUM>, by receiving data and reports from the communications interface <NUM>, and by retrieving data and instructions from the storage medium <NUM>. Other components, as well as the related functionality, of the OEM entity <NUM> are omitted in order not to obscure the concepts presented herein.

<FIG> schematically illustrates, in terms of a number of functional modules, the components of an OEM entity <NUM> according to an embodiment. The OEM entity <NUM> of <FIG> comprises a number of functional modules; an obtain module 410a configured to perform step S302 and a provide module 410b configured to perform step S304. The OEM entity <NUM> of <FIG> may further comprise a number of optional functional modules. In general terms, each functional module 410a-410b may be implemented in hardware or in software. Preferably, one or more or all functional modules 410a-410b may be implemented by the processing circuitry <NUM>, possibly in cooperation with the communications interface <NUM> and the storage medium <NUM>. The processing circuitry <NUM> may thus be arranged to from the storage medium <NUM> fetch instructions as provided by a functional module 410a-410b and to execute these instructions, thereby performing any steps of the OEM entity <NUM> as disclosed herein.

The network entity <NUM>, identification module <NUM>, and/or OEM entity <NUM> may be provided as standalone devices or as a part of at least one further device. Alternatively, functionality of the network entity <NUM>, identification module <NUM>, and/or OEM entity <NUM> may be distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part or may be spread between at least two such network parts. Thus, a first portion of the instructions performed by the network entity <NUM>, identification module <NUM>, and/or OEM entity <NUM> may be executed in a first device, and a second portion of the of the instructions performed by the network entity <NUM>, identification module <NUM>, and/or OEM entity <NUM> may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the network entity <NUM>, identification module <NUM>, and/or OEM entity <NUM> may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a network entity <NUM>, identification module <NUM>, and/or OEM entity <NUM> residing in a cloud computational environment. Therefore, although a single processing circuitry <NUM>, <NUM>, <NUM> is illustrated in <FIG> <FIG> the processing circuitry <NUM>, <NUM>, <NUM> may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 210a-<NUM>, 310a-310c, 410a-410b of <FIG> and <FIG>, and the computer programs 1220a, 1220b of <FIG>.

<FIG> shows one example of a computer program product 1210a, 1210b, 1210c comprising computer readable means <NUM>. On this computer readable means <NUM>, a computer program 1220a can be stored, which computer program 1220a can cause the processing circuitry <NUM> and thereto operatively coupled entities and devices, such as the communications interface <NUM> and the storage medium <NUM>, to execute methods according to embodiments described herein. The computer program 1220a and/or computer program product 1210a may thus provide means for performing any steps of the network entity <NUM> as herein disclosed. On this computer readable means <NUM>, a computer program 1220b can be stored, which computer program 1220b can cause the processing circuitry <NUM> and thereto operatively coupled entities and devices, such as the communications interface <NUM> and the storage medium <NUM>, to execute methods according to embodiments described herein. The computer program 1220b and/or computer program product 1210b may thus provide means for performing any steps of the identification module <NUM> as herein disclosed. On this computer readable means <NUM>, a computer program 1220c can be stored, which computer program 1220c can cause the processing circuitry <NUM> and thereto operatively coupled entities and devices, such as the communications interface <NUM> and the storage medium <NUM>, to execute methods according to embodiments described herein. The computer program 1220c and/or computer program product 1210c may thus provide means for performing any steps of the OEM entity <NUM> as herein disclosed.

In the example of <FIG>, the computer program product 1210a, 1210b, 1210c is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1210a, 1210b, 1210c could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1220a, 1220b, 1220c is here schematically shown as a track on the depicted optical disk, the computer program 1220a, 1220b, 1220c can be stored in any way which is suitable for the computer program product 1210a, 1210b, 1210c.

Claim 1:
A method for authenticating an Original Equipment Manufacturer, OEM, entity (<NUM>) as manufacturer of a communication device (<NUM>) comprising an identification module (<NUM>), the method being performed by a network entity (<NUM>), the method comprising:
providing (S104), towards the identification module (<NUM>), a challenge of a challenge-response authentication procedure;
obtaining (S106), from the identification module (<NUM>), a first response of the challenge-response authentication procedure;
providing (S108), towards the OEM entity (<NUM>) and upon having obtained the response, the challenge;
obtaining (S110), from the OEM entity (<NUM>), a second response of the challenge-response authentication procedure; and
authenticating (S112) the OEM entity (<NUM>) as the manufacturer of the communication device (<NUM>) only when the second response matches the first response.