WO2010063308A1

WO2010063308A1 - Scalable message authentication framework

Info

Publication number: WO2010063308A1
Application number: PCT/EP2008/066541
Authority: WO
Inventors: Michel Rene Gustave Ghislain Gillet; Elena Reshetova
Original assignee: Nokia Corporation
Priority date: 2008-12-01
Filing date: 2008-12-01
Publication date: 2010-06-10

Abstract

There is provided a scalable message authentication framework. An apparatus comprises thereof a plurality of ports each being configured to be connectable to one network node, a key storage being configured to store one authentication key for each network node connected via one of said plurality of ports, an authenticator being configured to authenticate a message between said apparatus and a network node connected via one of said plurality of ports using the one authentication key stored for said network node.

Description

Title of the invention

Scalable message authentication framework

Field of the invention

The present invention generally relates to scalable message authentication framework. For example, the present invention relates to scalable message authentication framework, which is suited for, but not limited to networks subject to constraints in terms of hardware resources and complexity.

Background of the invention

In recent years, security issues have attracted an increasing attention in the field of networking. Generally, the field of networking includes many different kinds of networks for example in terms of type (such as for example fixed or mobile communication networks, sensor networks, embedded system networks for example of device components, etc.), in terms of spread (such as for example wide area communication, local area networks, micro area networks, etc.), in terms of protocols (such as for example different communication or configuration protocols) , and in other terms (such as for example power, complexity, hardware resources, etc.) . Despite their partially considerable differences in one or more aspects, such networks have in common that security is an issue for securing operation, configuration, data exchange, user behavior, etc. therein . For example, as one aspect of security issues, message authentication (or data origin authentication) guarantees to the receiver of a message the identity of the sender of the message. It also implicitly provides data integrity, because if a message was modified during transmission, its sender is not the original sender anymore .

Summary of embodiments of the invention

The present invention and its embodiments are made to provide a scalable authentication framework, which is suited for, but not limited to networks subject to constraints in terms of hardware resources and complexity

According to an exemplary first aspect of the present invention, there is provided an apparatus comprising a plurality of ports each being configured to be connectable to one network node, a key storage being configured to store one authentication key for each network node connected via one of said plurality of ports, and an authenticator being configured to authenticate a message between said apparatus and a network node connected via one of said plurality of ports using the one authentication key stored for said network node .

According to further developments or modifications thereof, one or more of the following applies: - the apparatus further comprises a receiver being configured to receive a message from a network node connected via one of said plurality of ports, said authenticator further comprising a signature extractor being configured to extract a signature included in said received message, a reference signature generator being configured to generate a reference signature on the basis of the received message and the one authentication key stored for said network node, and a signature comparator being configured to compare said extracted signature with said generated reference signature,

- the apparatus further comprises a sender being configured to send a message to a network node connected via one of said plurality of ports, said authenticator further comprising a signature generator being configured to generate a signature on the basis of the message to be sent and the one authentication key stored for said network node, and a message generator being configured to include the generated signature into the message to be sent, - said reference signature generator and/or said signature generator is configured to generate a signature on the basis of a message authentication code,

- said reference signature generator and/or said signature generator is configured to generate a signature on the basis of one or more of a network layer header field of said message, a transport layer header field of said message, and a transport layer payload field of said message,

- said network and transport layers are layers of a MIPI and/or UniPro protocol,

- the authentication key is at least one of a symmetrical key and a public key assigned between said apparatus and a network node connected via one of said plurality of ports each, - the apparatus further comprises a destination analyzer being configured to analyze a destination network node of a message and to check whether an authentication key for said destination network node is stored in said key storage, and a router being configured to route said message towards its destination network node on the basis of a routing table, when no authentication key for said destination network node is stored in said key storage,

- the key storage is configured to further store one authentication key each for network nodes not being connected to said apparatus via one of said plurality of ports,

- one or more of network nodes connected via said plurality of ports form a cluster for which said apparatus serves as a configuration module,

- one or more of network nodes connected via said plurality of ports comprise a configuration module of a cluster other than a cluster for which said apparatus serves as a configuration module, - said apparatus is operable as a network switch and/or router, and/or

- said apparatus is operable in accordance with at least one MIPI and/or UniPro specification.

According to an exemplary second aspect of the present invention, there is provided a method comprising connecting to a plurality network nodes, storing one authentication key for each connected network node, and authenticating a message relating to a connected network node using the one authentication key stored for said network node.

According to further developments or modifications thereof, one or more of the following applies: - the method further comprises receiving a message from a connected network node, said authenticating further comprising extracting a signature included in said received message, generating a reference signature on the basis of the received message and the one authentication key stored for said network node, and comparing said extracted signature with said generated reference signature,

- the method further comprises sending a message to a connected network node, said authenticating further comprising generating a signature on the basis of the message to be sent and the one authentication key stored for said network node, and including the generated signature into the message to be sent,

- said reference signature generating and/or said signature generating comprises generating a signature on the basis of a message authentication code,

- said reference signature generating and/or said signature generating comprises generating a signature on the basis of one or more of a network layer header field of said message, a transport layer header field of said message, and a transport layer payload field of said message,

- said network and transport layers are layers of a MIPI and/or UniPro protocol, - the authentication key is at least one of a symmetrical key and a public key assigned with a connected network node,

- the method further comprises analyzing a destination network node of a message and checking whether an authentication key for said destination network node is stored, and routing said message towards its destination network node on the basis of a routing table, when no authentication key for said destination network node is stored, - storing comprises further storing one authentication key each for network nodes not being directly connected,

- said method is operable by a network switch and/or router, and/or

- said method is operable in accordance with at least one MIPI and/or UniPro specification. According to an exemplary third aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the second aspect or any development or modification thereof.

According to an exemplary fourth aspect of the present invention, there is provided an apparatus comprising a port being configured to be connectable to a configuration module, a key storage being configured to store one authentication key for said configuration module connected via said port, and an authenticator being configured to authenticate a message between said apparatus and said configuration module connected via said port using the one authentication key stored for said configuration module.

According to further developments or modifications thereof, one or more of the following applies:

- the apparatus further comprises a sender being configured to send a message to said configuration module, said authenticator further comprising a signature generator being configured to generate a signature on the basis of the message to be sent and the one authentication key stored for said configuration module, and a message generator being configured to include the generated signature into the message to be sent, - the apparatus further comprises a receiver being configured to receive a message from said configuration module, said authenticator further comprising a signature extractor being configured to extract a signature included in said received message, a reference signature generator being configured to generate a reference signature on the basis of the received message and the one authentication key stored for said configuration module, and a signature comparator being configured to compare said extracted signature with said generated reference signature,

- said reference signature generator and/or said signature generator is configured to generate a signature on the basis of a message authentication code,

- said reference signature generator and/or said signature generator is configured to generate a signature on the basis of one or more of said network layer header field of said message, a transport layer header field of a message, and a transport layer payload field of said message, - said network and transport layers are layers of a MIPI and/or UniPro protocol,

- the authentication key is at least one of a symmetrical key and a public key assigned between said apparatus and a network node connected via one of said plurality of ports each, and/or

According to an exemplary fifth aspect of the present invention, there is provided a method comprising connecting to a configuration module, storing one authentication key for said configuration module connected via said port, and authenticating a message relating to said configuration module using the one authentication key stored for said configuration module.

- the method further comprises sending a message to said configuration module, said authenticating further comprising generating a signature on the basis of the message to be sent and the one authentication key stored for said configuration module, and including the generated signature into the message to be sent, - the method further comprises receiving a message from said configuration module, said authenticating further comprising extracting a signature included in said received message, generating a reference signature on the basis of the received message and the one authentication key stored for said configuration module, and comparing said extracted signature with said generated reference signature,

- said reference signature generating and/or said signature generating comprising generating a signature on the basis of a message authentication code,

- said reference signature generating and/or said signature generating comprising generating a signature on the basis of one or more of said network layer header field of said message, a transport layer header field of a message, and a transport layer payload field of said message,

- said method is operable in accordance with at least one MIPI and/or UniPro specification.

According to an exemplary sixth aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the fifth aspect or any development or modification thereof.

According to an exemplary seventh aspect of the present invention, there is provided a system comprising at least one apparatus according to the first aspect or any development or modification thereof, which is operable as configuration module of the system, and at least one apparatus according to the fourth aspect or any development or modification thereof, which is operable as a network node of a security cluster of said configuration module, and is connected to said configuration module

Stated in other terms, the present invention and its embodiments propose a scalable message authentication framework, which is suited for, but not limited to networks subject to constraints in terms of hardware resources and complexity, such as for example embedded system network, sensor networks, and the like.

As an exemplary advantage, embodiments of the present invention may provide for a security mechanism having low requirements in terms of hardware resources, complexity, etc. (often referred to as "large footprint"), thus being applicable, for example, in networks subject to constraints in terms of hardware resources, complexity, etc .

As an exemplary advantage, embodiments of the present invention may provide for a security mechanism the computational or similar requirements of which do not increase (at least not considerably) with the increase in the number of network elements, thus providing a good performance in terms of scalability. As an exemplary advantage, embodiments of the present invention may provide for a security mechanism having a small footprint in terms of power, cost, complexity, amount of buffer needed, number of keys needed, etc.

Brief description of the drawings

In the following, the present invention will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which

Figure 1 shows a schematic block diagram of an exemplary network in which embodiments of the present invention are applicable,

Figure 2 shows a schematic block diagram of an exemplary network in which embodiments of the present invention are applied,

Figure 3 shows a schematic block diagram of a relational graph of a logical overlay network on top of the network shown in Figure 2,

Figure 4 (comprising Figures 4A and 4B) shows a message flow diagram according to embodiments of the present invention,

Figure 5 shows a schematic representation of an exemplary packet format according to embodiments of the present invention,

Figure 6 shows a flow diagram of a method according to embodiments of the present invention, which may be executed by a configuration module apparatus according to embodiments of the present invention,

Figure 7 shows a flow diagram of a method according to embodiments of the present invention, which may be executed by a network node apparatus according to embodiments of the present invention,

Figure 8 shows a schematic block diagram of a configuration module apparatus according to embodiments of the present invention, and

Figure 9 shows a schematic block diagram of a network node apparatus according to embodiments of the present invention.

Detailed description of embodiments of the present invention

The present invention is described herein with reference to particular non-limiting examples. A person skilled in the art will appreciate that the invention is not limited to these examples, and may be more broadly applied.

A first non-limiting example for an applicable use case of present embodiments includes sensor networks, which usually comprise dozens to hundreds of autonomously operating sensor elements interworking with each other (partly even in a self-configuring manner) . Sensors elements are usually battery-operated low-cost low- complexity devices, which are not capable for computationally expensive operations or operations requirement large storage capacity or the like. A second non-limiting example for an applicable use case of present embodiments includes embedded systems (for example embedded networks) in certain devices, which usually comprise a certain number of electronic parts or components interworking with each other. In this regard, MIPI (Mobile Industry Processor Interface) and UniPro (Unified Protocol) may be mentioned as exemplary standardization work in this environment.

The MIPI/UniPRO standardization work is targeted at the creation of a protocol stack for a new low power, highspeed serial link bus designed to be a new kind of generic and modular bus that addresses specific requirements of mobile terminals and multimedia devices. Currently, the MIPI specifications, and notably the complete UniPro protocol stack, was build without taking care of security issues. Accordingly, the whole network (for example, embedded system network of device components) is configured by using a protocol, called Config protocol in the standardization, which does not provide or use any mechanism to secure the configuration process. In other words, any node of the network can, by using the Config protocol, completely reprogram the network and/or any other application using the Config protocol for self configuration.

In view thereof, the present invention and its embodiments are mainly described in relation to an embedded system network used as a non-limiting example for an underlying network. As such, the description of the embodiments given herein specifically refers to terminology which is directly related to MIPI and/or UniPro specifications used as a non-limiting example for a specific use case. In this regard, when referring to specific examples in the context of embedded systems and/or MlPI/UniPro, it is to be noted that any other alternatives of underlying networks and/or applicable use cases for protocols or the like may also be utilized as long as compliant with described features and principles. Such terminology is only used in the context of the presented non-limiting examples, and does not limit the invention in any way.

In the following, embodiments of the present invention are described in generic terms first, and thereafter in more details.

Stated in generic terms, according to embodiments of the present invention, it may be distinguished between (simple) network nodes and centralized network nodes (for the sake of legibility only, referred to as central configuration module) with a specific functionality. According to embodiments of the present invention, there is provided that the number of authentication keys needed for a "simple" network node is known per se, and is independent of the size of the network. That is, preferably only one authentication key is mandated for each "simple" network node. Further, there is provided that the number of authentication keys needed for a central configuration module is mandated to be only one authentication key for each port or each connected network node (whether simple network node or another central configuration module) , respectively. Thus, the total number of keys in a system with N network nodes is equal to N-I (for the N-I simple nodes other than the central CCM) . Accordingly, the framework provided by embodiments of the present invention scales with the size if the network (for example the number of network nodes therein) , and the (hardware or software) implementation of both simples network nodes and central configuration modules (being very simple to highly complex) works regardless of the size of the network.

According to embodiments of the present invention, there is provided (as mentioned above) a special type of network nodes in the network, which is called CCM (Central Configuration Module) . Each other network node in the network has one (symmetric) authentication key between itself and a CCM network node to which it is connected. A CCM network node has the knowledge of the authentication keys of other related (for example, connected) nodes on the network.

For example, if a Node A wants to exchange authenticated packets, data or messages with another node, Node B, Node A sends an authenticated message to its CCM (for example the competent CCM of a security cluster to which Node A belongs) . The message authentication may for example be accomplished by signing the message using a signature based on the symmetric authentication key known by both. When the competent CCM receives the thus signed message and the message has been authenticated by the competent CCM, the competent CCM will forward the message to Node B. The message sent to Node B will in turn be authenticated by the competent Node B, for example using the symmetric authentication key between the CCM and Node B.

Optionally, a CCM network node may be (physically and/or logically) bundled with a switch or router of the network .

While a network according to embodiments of the present invention may comprise a single CCM network node being responsible for all other (simple) network nodes in the network, a network according to embodiments of the present invention may also comprise more than one CCM network node. If so, each CCM network node is responsible for a certain set of (simple) network nodes, which form a security cluster. Each security cluster includes one competent CCM network node, and distinct security clusters interface with each other by a link between the respective competent CCM network nodes thereof.

When there is a single centralized CCM network node in the network, the CCM network node will be a bottleneck in the system, since all communications with authentication data will need to go through a single point in the network. On the other hand, all the knowledge of the authentication keys in the system is localized in one single point, which may bring some advantage from a security point of view, but also some additional threats.

Hence, embodiments of the present invention support several CCM network nodes in the network. This means that every CCM network node is localized and related to a cluster inside the network. Each CCM network node may communicate to at least one other CCM network node, and has the possibility to forward messages to other CCM network nodes, when it does not know the authentication key of the final destination of a message.

Referring to the specific example of a UniPro-based network, the protocol to configure UniPro and some other application running on top of UniPro will be able to authenticate rightful users of the protocol. In the particular case of the Config protocol in UniPro, the configuration of UniPro would then be secured. Thus, by way of exemplary embodiments of the present invention, one or more of the following advantageous effects may be achieved.

- Only one symmetric key is needed per network node on the network. Every (simple) network node thus needs to store only one key. So, when there are N nodes on the network, a total of N-I keys are needed independent of network size.

- The low required number of keys leads to an acceptable cost in terms of hardware resources and the like, since the hardware implementation thereof is acceptable for network such as for example embedded networks, and UniPro.

- No time synchronization in the network is needed, since no need of timestamps exists.

- The knowledge of all authentication keys is not spread in the system, which reduces the overall complexity. The CCM network node/s is/are the root of trust in the system.

- The binding of CCM network nodes and switches/routers may significantly reduce the bottleneck associated to centralizing the keys in the CCM network nodes.

- Having only one symmetric key per network node simplifies the key management in the system.

- Complexity of the storage of authentication keys is removed from all (simple) network nodes. As regards the functionality of so-called simple network nodes, regardless of the above description that it is sufficient that a simple node has a single authentication key assigned between itself and its competent CCM, it is not excluded that a simple node has the knowledge of more than one authentication key. For such a simple node, only one authentication key shall be used to communicate with a CCM, and all other authentication keys shall be used to communicate with other simple nodes directly.

In this regard, it is to be noted that, when a node would store more than one authentication key to communicate to a CCM, this node is actually to be regarded as a CCM instead of a simple node) and thus needs to implement all functionality of a CCM. If so, such a node would be able to act as a "real CCM". However, in order to prevent the risk of an attack in the form of a set-up of a new node acting as a malicious CCM by an attacker, not any arbitrary node shall be able to act as a CCM. The right to act ass a CCM could thus be managed by a network operator, service provider, or the like.

When a simple node A needs to send a message to node B, it must first check if it has a symmetric key between node B and itself. If it does have such a key, it can directly send the authenticated message by using this key. If node A does not have such a symmetric key between node B and itself, it has to send the message to its competent CCM and to authenticate this message by using the symmetric key between the CCM and itself.

As regards the term "key" or "authentication key" used herein, it is noted that any kind of key or code or other symbol suitable for authentication purposes may be used. In general, both public and symmetric key cryptography can be used to authenticate messages between network nodes and/or CCMs. Thus, embodiments of the present invention are not bound to a specific authentication such as for example PKI-based authentication.

Hereinafter, embodiments of the present invention will be described in more detail with reference to the Figures 1 to 9.

Figure 1 shows a schematic block diagram of an exemplary network in which embodiments of the present invention are applicable .

The thus depicted exemplary network serves as a reference network for the further explanations, without limiting the applicability of the present invention thereto.

The network according to Figure 1 comprises three switches/routers denoted as SO, Sl and S2, as well as eight (simple) network nodes denoted as CO to C7. Each switch/router has five ports denoted as PO to P4, respectively, at which other network elements (whether simple nodes or configuration modules) may be connected thereto. In the non-secured network according to Figure 1, any network node may exchange untrusted messages with any network node.

Figure 2 shows a schematic block diagram of an exemplary network, which corresponds to the network according to Figure 1, in which embodiments of the present invention are applied.

The thus depicted exemplary network according to embodiments of the present invention additionally comprises two central configuration modules denoted as CCMO and CCM2. The central configuration modules CCMO and CCM2 enable message authentication between network nodes of the network, as explained below. The central configuration modules CCMO is exemplarily connected to port P4 of switch/router SO, and is responsible for providing security for nodes CO to C3. Stated in other words, nodes CO to C3 form the security cluster of CCMO. The CCM node CCM2 is exemplarily connected to port P4 of switch/router S2, and is responsible for providing security for nodes C4 to C7. Stated in other words, nodes C4 to C7 form the security cluster of CCM2.

As mentioned above, since the goal of having more than one CCM is to reduce the bottleneck created by a centralized security entity, it is efficient to put those (simple) nodes and a CCM into a cluster, which are physically close to each other. A security cluster is this defined by a set of nodes including one CCM. A system providing message authentication using this approach needs at least one security cluster. The level of security is defined per cluster. The communication between security clusters happens between the CCM of the respective clusters.

When a CCM is responsible for a set of nodes, it means that this particular CCM knows about the authentication key of each node it serves.

The logical relation between (simple) network nodes and their competent configuration modules CCM is illustrated by Figure 3.

Figure 3 shows a schematic block diagram of a relational graph of a logical overlay network on top of the network shown in Figure 2. According to Figure 3, the relation between network nodes is defined by a symmetric key shared by two network nodes. According to Figure 3, it is illustrated that security cluster 0 consists of nodes CO to C3 and configuration module CCMO (being logically bundled with switch/router SO) , and that security cluster 2 consists of nodes C4 to C7 and configuration module CCM2 (being logically bundled with switch/router S2) .

Stated in other terms, any authenticated (for example signed) message sent follows the logical secure overlay network .

When receiving an authenticated message, a CCM must either forward the message to the destination node, when it knows the key of that node, or otherwise must route the message to another CCM, which shall know how to handle this message. Every CCM is then also working as a logical switch/router in a message authentication overlay network.

For example, if the node CO wants to send an authenticated message (being authenticated by the symmetric key between CCMO and node CO) to node C6, the message is sent from node CO to its CCM, for example CCMO. Since CCMO does not know the key of node C6 (because node C6 does not belong to the security cluster served by CCMO, for example cluster 0), it will forward the message to CCM2. When CCM2 receives the message, it can see that the destination is node C6, and it knows the key used by node C6, for example the symmetric key between CCM2 and node C6. Thus, CCM2 can then send the correspondingly authenticated message to node C6. It is to be noted that the topology of the (logical) overlay network created by the CCM nodes has an influence on the configuration and security of the whole system. When only one CCM is present in the whole system and when this CCM is compromised, the whole system is compromised. With every additional CCM, the impact of a successful attack on a CCM is decreased.

The exemplary network illustrations of Figures 1 to 3 notwithstanding, it is to be appreciated that these illustrations are only by way of example. That is, neither the number of respective nodes nor their numerical relationship is restricted to what is exemplarily illustrated. It is noted that configuration modules according to embodiments of the present invention may be (logically and/or physically) linked to switches/routers (as depicted in Figure 2), may be (logically and/or physically) bundled/associated with switches/routers, or may be arranged as interconnecting network node instead of switches/routers.

In the following, details on the actual authentication of messages and the flow of authenticated message exchange will be described by using the above-described network structure as a non-limiting use case of embodiments of the present invention.

In the notation used to explain the actual authentication of messages and the flow of authenticated message exchange, for example to represent the exchanged messages, the following convention is used:

- h_x: the header of a packet/message sent, wherein a different x means a different header; in the exemplary case of the UniPro protocol, this header includes the L3 (network layer) and L4 (transport layer) headers;

- p: the payload of a packet/message sent; in the exemplary case of the UniPro protocol, this payload includes the L4 (transport layer) payload;

- K_{x, γ}: the symmetric authentication key between X and Y, wherein X can be a simple network node or a CCM, and Y can be also be a simple network node or a CCM;

- RD_x (y,z) : a count value which is monotonously incremented following agreed rules between the sender and the receiver of a packet/message, which could for example be a sequence number, a timestamp, or the like.; in the exemplary case of the UniPro protocol, RD is to be defined, there is no monotonously increasing number already specified in UniPro; X is the simple network node or CCM which stores the current value of the RD, y to z shows the direction of the flow of signed packets/messages between the simple network ode or CCM y and simple network node or CCM z; - MsgX: the message sent; in the exemplary case of the UniPro protocol, this message may actually be a L4 (transport layer) segment, including L3 and L4 headers; and

- MAC K_x,_y (hi, p, RD_a (b, c) ) : the message authentication code computed based on the symmetric authentication key

K_x,_y, wherein x and y define the two owners of this key, and RD is the monotonously increasing number described beforehand.

As a non-limiting example of use with reference to

Figures 2 and 3 above, a simple node CO wants to send an authenticated message to simple node Cl. According to embodiments of the present invention, the following procedures will be performed: 1) CO sends to CCMO a message being authenticated by the symmetric key between CO and CCMO, namely

MsgO (hO,p,MAC K_c0, CCMO (hθ, p, RD_CO (CO, CCMO) )),

2) CCMO authenticates the message MsgO, for example verifies the trustworthiness thereof by the symmetric key between CO and CCMO,

3) CCMO sends to Cl a message being authenticated by the symmetric key between CCMO and Cl, namely

Msgl (hi, p, MAC K_CI,_CCMO (hi , p, RD_CCMO (CCMO , Cl) ), and 4) Cl authenticates the message Msgl, for example verifies the trustworthiness thereof by the symmetric key between CCMO and Cl.

As another non-limiting example of use with reference to Figures 2 and 3 above, a simple node CO wants to send an authenticated message to simple node C6. According to embodiments of the present invention, the following procedures will be performed:

1) CO sends to CCMO a message being authenticated by the symmetric key between CO and CCMO, namely

MsgO (h0,p,MAC K_CO,CCMO (h0,p,RD_c0 (CO, CCMO) ) ,

2) CCMO authenticates the message MsgO, for example verifies the trustworthiness thereof by the symmetric key between CO and CCMO, 3) CCMO sends to CCM2 a message being authenticated by the symmetric key between CCMO and CCM2, namely Msgl (hi, p, MAC K_CCM0,_CCM2 (hi, p, RD_CCM0 (CCMO, CCM2) ),

4) CCM2 authenticates the message Msgl, for example verifies the trustworthiness thereof by the symmetric key between CCMO and CCMl,

5) CCM2 sends to C6 a message being authenticated by the symmetric key between CCM2 and C6, namely

Msg2 (h2,p,MAC K_C6,_CCM2 (h2 , p, RD_CCM2 (CCM2 , C6) ) , and 6) C6 authenticates the message Msg2, for example verifies the trustworthiness thereof by the symmetric key between CCMO and CCMl.

Figure 4 (comprising Figures 4A and 4B) shows a message flow diagram according to embodiments of the present invention. Namely, Figure 4 shows details of the above- described example of use of an authenticated message exchange between two simple nodes A and B belonging to the common security cluster of a single CCM.

According to Figure 4, both endpoint nodes A and B are schematically depicted as being composed of two parts, namely a secure protocol part and an actual node part. The addresses of nodes A and B are denoted as NA and NB, respectively.

According to the flow diagram of Figure 4, the procedures begin in an initial situation, in which all of the involved nodes A, B, and CCM are in idle state, and the count numbers between nodes A and CCM (RD_.. (NA, CCM) ) as well as between nodes B and CCM (RD_.. (CCM, NB) ) are held in coincidence with each other in the respective nodes.

When a message transmission request for transferring dataO to a node with address NB is initiated in node A, for example SET . req (NB, dataO) , as outlined above, node A draws on the relevant count value, creates a message to be sent, generates a signature thereof on the basis of the message and the relevant authentication key between nodes A and CCM, authenticates the message by using the thus generated signature, transmits the thus signed message to node CCM and updates the relevant count value. Upon receipt of the message sent by node A, as outlined above, node CCM authenticates the thus received message by extracting a signature thereof (sign) , generating a reference signature (signO) on the basis of the message and the relevant authentication between nodes A and CCM and comparing the extracted signature with the reference signature (authentication confirmed, when sign=signθ hold true), and updates the relevant count value. In the procedure denoted as "Route the authenticated Msg", the node CCM checks whether it knows (for example stores) the relevant authentication key with respect to node B. Details thereof are described below. If not available, the message will be routed to another CCM in the direction of the actual destination node. If available, as assumed in Figure 4, the message will be forwarded to the destination node B. Then, as outlined above, node CCM draws on the relevant count value, creates a message to be sent, generates a signature thereof on the basis of the message and the relevant authentication key between nodes CCM and B, authenticates the message by using the thus generated signature, transmits the thus signed message to node B and updates the relevant count value. Upon receipt of the message sent by node B, as outlined above, node B authenticates the thus received message by extracting a signature thereof (sign) , generating a reference signature (signO) on the basis of the message and the relevant authentication between nodes CCM and B and comparing the extracted signature with the reference signature (authentication confirmed, when sign=signθ hold true), and updates the relevant count value. Finally, a message transmission indication for indicating that dataO have been received by means of an authenticated message from node A is initiated in node B, for example SET . ind (NA, dataO) . That is, such a message transmission indication confirms that the received message was an authenticated (for example signed) message, for example that dataO has been received in an authenticated manner. Regarding the exemplary message flow described above, it is noted that the forwarding/routing of the message received by the CCM is not mandatory, but only due to the assumed example that the destination of the message is not the CCM as such. When the message is destined for the CCM as such, for example for configuration of the CCM, the CCM does not forward/route the message to another node, but processes the message itself. If so, the routing procedure and the procedure of Figure 4B would be omitted.

Although, as mentioned above, the principles features and procedures described therein are universally applicable, the UniPro protocol is referred to hereinafter as a non- limiting example for a practical implementation.

When referring to UniPro, messages (which are L4 segments in UniPro) are to be authenticated, while preferably keeping the costs low. This means that, for providing a low complexity, low silicon/hardware footprint solution, it is sufficient to authenticate the source and integrity of every message. For such a case, one direct target application is to secure the Config protocol of UniPro, where the content of the message can be sent in clear text.

This can be achieved by using a signature based on a message authentication code (MAC) . While there exist many different MACs, the one chosen is irrelevant embodiments of the present invention. Nonetheless, for a given implementation, the MAC should preferably be chosen carefully to find a proper balance between overall performance, level of security, cost, and complexity. Nonetheless, according to exemplary embodiments of the present invention, a signature may cover a complete L3 (network layer) header, a complete L4 (transport layer) header and a carried L4 (transport layer) payload. The reason for this is to mitigate some threats, for example replay attacks, changing of the payload, etc.

In the case of UniPro in accordance with current specifications, an implementation could look like depicted in Figure 5.

Figure 5 shows a schematic representation of an exemplary packet format according to embodiments of the present invention, wherein UniPro is taken as a non-limiting example of an applicable protocol. Most of the packet format is defined in UniPro itself and is given here as an example.

While the individual protocol fields and their meaning are deemed to be known to the skilled reader, a detailed description thereof is omitted for the sake of brevity.

According to Figure 5, it is apparent that the signature is put at the end of the packet. This is to simplify hardware implementation, but also to keep possible a cut- through implementation. As mentioned above, the signature covers the L3 header, the L4 header, and the L4 payload.

Although the above implementation example is detailed with reference to UniPro, the principles (including for example signature coverage, signature position, or the like) are equally applicable to any other protocol being based on a protocol stack in accordance with the basic ideas of the ISO/OSI (International Standards Organization/Open Systems Interconnection) reference model .

Returning to the functionality of a configuration module according to exemplary embodiments of the present invention, further details on the routing procedures are described below with specific non-limiting reference to the UniPro packet format, as illustrated in Figure 5.

As mentioned above, a CCM may be implemented in (physical and/or logical) linkage with or even in switches/routers of the underlying network structure. Such an arrangement may reduce the costs of the proposed authentication mechanism according to present embodiments.

Accordingly, a CCM according to embodiments of the present invention may utilize a so-called "re-routing" mechanism.

If the "re-routing" mechanism is used, as assumed in the packet format according to Figure 4, a CCM/switch may look for the "re-routing" extension field, denoted as "ExtID=ReRouting", in the L3 header. If the "re-routing" extension is found, the CCM/switch knows that something else must be done with the packet/message than the normal forwarding .

When it is found that the "re-routing" extension is present, the CCM/switch may start to analyze further what specific routing must be performed. If the "security protection" extension field, denoted as "ExtID=SecProt", in the L3 header is found, the CCM/switch knows that the authentication mechanism is to be used. At this point, two cases are to be distinguished (which have already been mentioned in connection with the routing procedure of the CCM in the context of Figure 4), namely (i) the CCM/switch knows the key of the destination node of the packet/message, and (ii) the CCM/switch does not know the key of the destination node of the packet/message.

If the CCM/switch knows the key of the destination, it may sign the received packet with the appropriate key and insert again this re-signed packet to the normal routing/forwarding process.

If the CCM/switch does not know the key of the destination, the routing table inherent to the router/switch may be used to route the packet one hop closer to its destination, since the packet is then bound to find the CCM which knows about the key of the destination .

Such a routing operation may be expedited by an appropriate and careful forming and organization of security clusters. Namely, when the security clusters are beneficially defined, all the knowledge needed by the CCM is already included in the routing table of the underlying switch/router.

Above, it is described that a CCM needs to store N keys, when it has N ports, to be a fully generic CCM supporting any network topology for a network of any size. In this case, an authenticated message is to be re-signed at every hop in the network.

Alternatively, to improve performance in terms of message routing, a CCM having N ports may store M keys, with M being larger than N. The additional M-N keys not being assigned to the N directly connected network nodes are assigned for network nodes being more than one hop away. In this case, an authenticated message is not to be resigned at every hop, since a CCM may know the key of either the destination node or the next CCM a few hops ahead, thus virtually skipping the intermediate network nodes.

While in the foregoing the procedures and functionalities have mainly been described from an overall (system) point of view, below reference will be made to the individual entities.

For the below-referenced flow diagrams, it is to be noted that the depicted sequences of procedures are to be understood as non-limiting examples. For example, the respective receive side procedures may be executed independent of the respective transmit side procedures, and the succession of at least some of the procedures is not binding as illustrated, but may be different. Also, for the sake of lucidity, all conceivable procedures are illustrated, while not all of these have necessarily to be executed for complying with the underlying principles of embodiments of the present invention.

Figure 6 shows a flow diagram of a method according to embodiments of the present invention, which may be executed by a configuration module apparatus according to embodiments of the present invention.

As a starting point for the following description, it is assumed that the CCM executing these procedures is connected with N network nodes (which may be either simple nodes or other CCMs) via its N ports, and stores (at least) N authentication key, one for each connected network node. This is illustrated by block S600. In S610, a message is received from a connected network node. In S620, the received message is authenticated by using the relevant symmetric key assigned for the node where the received message has originated. The message authentication in S610 may comprise extracting a signature included in said received message (S621), generating a reference signature on the basis of the received message and the one relevant key stored (S622), and comparing said extracted signature with said generated reference signature (S623) . For signature generation, reference is made to the above. In S630, a count value of a receive side counter (RD between message source and CCM) is updated, for example held in compliance with a respective count value at the source node. Such a counting is an optional procedure in connection with consistent signature generation.

In S640, destination of the received message is analyzed, and on the basis of the thus acquired destination it is checked whether a relevant symmetric key for said destination is locally available (S650) . If so (YES in S650), the message will be directly forwarded to its destination being directly connected to the present CCM executing these procedures (S660a) . If not (NO in S650), the message may be routed to a next hop which is not the final destination thereof (S660b) or, if the message is destined for the CCM itself, it may be locally processed for example for configuring the CCM itself (not shown in the figure) . Such a routing towards its destination node may be based on a routing table being stored at the relevant CCM executing these procedures.

Apart from the different target nodes in the cases of direct forwarding or routing, the following procedures are equivalent to each other. Namely, in S670, the message to be sent is authenticated by using the relevant symmetric key assigned for the node where the message is to be sent to. The message authentication in S670 may comprise generating a signature on the basis of the message to be sent and the one relevant key stored

(S671), and including said generated signature into the message to be sent, for example signing the message (S672) . For signature generation, reference is made to the above. In S680, a count value of a transmit side counter (RD between CCM and message target) is updated, for example held in compliance with a respective count value at the target node. Such a counting is an optional procedure in connection with consistent signature generation. In S690, the thus authenticated message is sent to the target node (for example destination node or intermediate routing hop node) .

Figure 7 shows a flow diagram of a method according to embodiments of the present invention, which may be executed by a (simple) network node apparatus according to embodiments of the present invention.

Since the procedures of a simple node according to Figure 7 are mostly equivalent to those of a CCM, as described in connection with Figure 6 above, reference is made thereto, while only differences are set out below. Like reference numerals are used for like procedures.

As a starting point, it is assumed that the simple node executing these procedures is connected with one CCM (while this does generally not exclude the additional connected with further simple node, as mentioned above) , and stores one authentication key being assigned between itself and the connected CCM. This is illustrated by block S700. Generally, it is to be noted that the receive and transmit sides procedures are decoupled from each other, which means that a simple node may receive a message without forwarding it as well as send a message without having received this message beforehand. This is due to the simple nodes normally representing message endpoints. Thus, no procedures regarding destination analysis or routing are illustrated, but a procedure of terminating a message receipt by initiating a receipt indication (S735) confirming that the received message was an authenticated (for example signed) message, and for starting a message transmission by initiating a transmission request (S765) are illustrated.

Although, in the foregoing, embodiments of the present invention have been described mainly with reference to methods, procedures and functions, corresponding embodiments of the present invention also cover respective apparatuses, network nodes, including both software and/or hardware thereof.

Respective exemplary embodiments of the present invention are described below referring to Figures 8 and 9, while for the sake of brevity reference is made to the detailed description of respective corresponding methods and operations according to Figures 4 to 7, respectively.

In Figures 8 and 9, the solid line blocks are basically configured to perform the respective operations or procedures. The entirety of blocks is basically configured to perform the methods and operations as described above, respectively. With respect to Figures 8 and 9, it is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation- independent, for example may be implemented by means of any kind of hardware or software, respectively. The lines/arrows interconnecting individual blocks are meant to illustrate an operational coupling there-between, which on the one hand is implementation-independent (for example wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional entities not shown. It is noted that not all of the thus depicted functional blocks have to be present at the same time. Further, it is noted that arbitrary functional blocks may be implemented by a common operational unit despite exemplarily being depicted as separate blocks.

Generally, the individual functional blocks depicted in Figures 8 and 9 are to be understood as being configured to implement corresponding operations or procedures being equally denoted, respectively.

Figure 8 shows a schematic block diagram of a configuration module apparatus according to embodiments of the present invention. Such a configuration module apparatus may for example be any one of central configuration modules CCMO and CCM2 according to Figures 2 and 3 above .

Stated in general terms, according to the non-limiting embodiment of Figure 8, the thus depicted apparatus comprises the following functional blocks.

A plurality of ports each represents means for being connectable to one network node (for example simple node or CCM) , a key storage represents means for storing one authentication key for each network node connected via one of said plurality of ports (for example N keys in total) , and an authenticator represents means for authenticating a message between said apparatus and a network node connected via one of said plurality of ports using the one authentication key stored for said network node. A transceiver represents a sender for sending a message to a connected network node and a receiver for receiving a message from a connected network node.

On the receive side, said authenticator comprises a signature extractor representing means for extracting a signature included in a received message being supplied by the transceiver, a reference signature generator representing means for generating a reference signature on the basis of the received message and the one authentication key stored for said network node, and a signature comparator representing means for comparing said extracted signature with said generated reference signature .

On the transmit side, said authenticator comprises a signature generator representing means for generating a signature on the basis of a message to be sent and the one authentication key stored for said network node, and a message generator representing means for including the generated signature into the message to be sent.

The authenticator may also comprise a plurality of counters, one for each port, representing means for holding (and updating) a current count value assigned between said apparatus and a network node connected via said port in compliance with a respective count value held at said network node. Such a counting is an optional procedure in connection with consistent signature generation. The apparatus according to the exemplary embodiment of Figure 8 also comprises a destination analyzer representing means for analyzing a destination network node of a message and for checking whether an authentication key for said destination network node is stored in said key storage, and a router representing means for routing said message towards its destination network node on the basis of a routing table, when no authentication key for said destination network node is stored in said key storage. As another option for the case that no authentication key for said destination network node is stored in said key storage, the thus received message may be locally processed by the apparatus itself, for example by a message or configuration processor or the like.

Figure 9 shows a schematic block diagram of a network node apparatus according to embodiments of the present invention. Such a network node apparatus may for example be any one of nodes CO to C7 according to Figures 2 and 3 above .

Since the functional blocks of a simple node according to Figure 9 are mostly equivalent to those of a CCM, as described in connection with Figure 8 above, reference is made thereto, while only differences are set out below. Insofar, reference is made to the differences between the respective procedures, as described in connection with Figures 6 and 7.

Basically, the apparatus according to Figure 9 comprises a single port which represents means for being connectable to a configuration module, and the key storage represents means for storing a single key for said configuration module connected via said port. Further, for the reasons sat out above, the apparatus according to Figure 9 does not comprise a destination analyzer, a forwarder, a router, and a routing table. Rather, the apparatus according to Figure 9 comprises a receipt indication initiator representing means for initiating a receipt indication after receipt of an authenticated message and authentication thereof, and a transmission request initiator representing means for initiating means for initiating a transmission request prior to authenticating and sending a message.

In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Furthermore, method steps and functions likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language such as for example Java, C++, C, and Assembler. Method steps and/or devices or means likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example. Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to those skilled in the art.

Software in the sense of the present description comprises software code as such comprising code means for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable storage medium having stored thereon a respective data structure or code portions or embodied in a signal or in a chip, potentially during processing thereof.

Generally, for the purpose of the present invention as described herein above, it should be noted that - a network node may be any device, apparatus, unit or means being capable of participating in an underlying network, such as a mobile phone, personal digital assistant PDA, or computer; - devices, apparatuses, units or means can be implemented as individual devices, apparatuses, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, apparatus, unit or means is preserved, - an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;

- a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

There is provided a scalable message authentication framework. An apparatus thereof a plurality of ports each being configured to be connectable to one network node, a key storage being configured to store one authentication key for each network node connected via one of said plurality of ports, an authenticator being configured to authenticate a message between said apparatus and a network node connected via one of said plurality of ports using the one authentication key stored for said network node .

The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

Even though the invention is described above with reference to the examples according to the accompanying drawings, it is to be understood that the invention is not restricted thereto. Rather, it is apparent to those skilled in the art that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.

Claims

1. An apparatus comprising a plurality of ports each being configured to be connectable to one network node, a key storage being configured to store one authentication key for each network node connected via one of said plurality of ports, and an authenticator being configured to authenticate a message between said apparatus and a network node connected via one of said plurality of ports using the one authentication key stored for said network node.

2. The apparatus according to claim 1, further comprising a receiver being configured to receive a message from a network node connected via one of said plurality of ports, said authenticator further comprising a signature extractor being configured to extract a signature included in said received message, a reference signature generator being configured to generate a reference signature on the basis of the received message and the one authentication key stored for said network node, and a signature comparator being configured to compare said extracted signature with said generated reference signature.

3. The apparatus according to claim 1 or 2, further comprising a sender being configured to send a message to a network node connected via one of said plurality of ports, said authenticator further comprising a signature generator being configured to generate a signature on the basis of the message to be sent and the one authentication key stored for said network node, and a message generator being configured to include the generated signature into the message to be sent.

4. The apparatus according to any one of claims 1 to 3, wherein said reference signature generator and/or said signature generator is configured to generate a signature on the basis of a message authentication code, and/or said reference signature generator and/or said signature generator is configured to generate a signature on the basis of one or more of a network layer header field of said message, a transport layer header field of said message, and a transport layer payload field of said message .

5. The apparatus according to claim 4, wherein said network and transport layers are layers of a MIPI and/or UniPro protocol.

6. The apparatus according to any one of claims 1 to 5, wherein the authentication key is at least one of a symmetrical key and a public key assigned between said apparatus and a network node connected via one of said plurality of ports each.

7. The apparatus according to any one of claims 1 to 6, further comprising a destination analyzer being configured to analyze a destination network node of a message and to check whether an authentication key for said destination network node is stored in said key storage, and a router being configured to route said message towards its destination network node on the basis of a routing table, when no authentication key for said destination network node is stored in said key storage.

8. The apparatus according to any one of claims 1 to 7, wherein the key storage is configured to further store one authentication key each for network nodes not being connected to said apparatus via one of said plurality of ports.

9. The apparatus according to any one of claims 1 to 8, wherein one or more of network nodes connected via said plurality of ports form a cluster for which said apparatus serves as a configuration module, and/or one or more of network nodes connected via said plurality of ports comprise a configuration module of a cluster other than a cluster for which said apparatus serves as a configuration module.

10. The apparatus according to any one of claims 1 to 9, wherein said apparatus is operable as a network switch and/or router, and/or said apparatus is operable in accordance with at least one MIPI and/or UniPro specification.

11. A method comprising connecting to a plurality network nodes, storing one authentication key for each connected network node, and authenticating a message relating to a connected network node using the one authentication key stored for said network node.

12. The method according to claim 11, further comprising receiving a message from a connected network node, said authenticating further comprising extracting a signature included in said received message, generating a reference signature on the basis of the received message and the one authentication key stored for said network node, and comparing said extracted signature with said generated reference signature.

13. The method according to claim 11 or 12, further comprising sending a message to a connected network node, said authenticating further comprising generating a signature on the basis of the message to be sent and the one authentication key stored for said network node, and including the generated signature into the message to be sent.

14. The method according to any one of claims 11 to 13, wherein said reference signature generating and/or said signature generating comprises generating a signature on the basis of a message authentication code, and/or said reference signature generating and/or said signature generating comprises generating a signature on the basis of one or more of a network layer header field of said message, a transport layer header field of said message, and a transport layer payload field of said message .

15. The method according to claim 14, wherein said network and transport layers are layers of a MIPI and/or UniPro protocol.

16. The method according to any one of claims 11 to 15, wherein the authentication key is at least one of a symmetrical key and a public key assigned with a connected network node.

17. The method according to any one of claims 11 to 16, further comprising analyzing a destination network node of a message and checking whether an authentication key for said destination network node is stored, and routing said message towards its destination network node on the basis of a routing table, when no authentication key for said destination network node is stored.

18. The method according to any one of claims 11 to 17, wherein storing comprises further storing one authentication key each for network nodes not being directly connected.

19. The method according to any one of claims 11 to 18, wherein said method is operable by a network switch and/or router, and/or said method is operable in accordance with at least one MIPI and/or UniPro specification.

20. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 11 to 19.

21 . An apparatus compri s ing a port being configured to be connectable to a configuration module, a key storage being configured to store one authentication key for said configuration module connected via said port, and an authenticator being configured to authenticate a message between said apparatus and said configuration module connected via said port using the one authentication key stored for said configuration module.

22. The apparatus according to claim 21, further comprising a sender being configured to send a message to said configuration module, said authenticator further comprising a signature generator being configured to generate a signature on the basis of the message to be sent and the one authentication key stored for said configuration module, and a message generator being configured to include the generated signature into the message to be sent.

23. The apparatus according to claim 21 or 22, further comprising a receiver being configured to receive a message from said configuration module, said authenticator further comprising a signature extractor being configured to extract a signature included in said received message, a reference signature generator being configured to generate a reference signature on the basis of the received message and the one authentication key stored for said configuration module, and a signature comparator being configured to compare said extracted signature with said generated reference signature.

24. The apparatus according to any one of claims 21 to 23, wherein said reference signature generator and/or said signature generator is configured to generate a signature on the basis of a message authentication code, and/or said reference signature generator and/or said signature generator is configured to generate a signature on the basis of one or more of said network layer header field of said message, a transport layer header field of a message, and a transport layer payload field of said message .

25. The apparatus according to claim 24, wherein said network and transport layers are layers of a MIPI and/or UniPro protocol.

26. The apparatus according to any one of claims 21 to 25, wherein the authentication key is at least one of a symmetrical key and a public key assigned between said apparatus and a network node connected via one of said plurality of ports each.

27. The apparatus according to any one of claims 21 to 26, wherein said apparatus is operable in accordance with at least one MIPI and/or UniPro specification.

28. A method comprising connecting to a configuration module, storing one authentication key for said configuration module connected via said port, and authenticating a message relating to said configuration module using the one authentication key stored for said configuration module.

29. The method according to claim 28, further comprising sending a message to said configuration module, said authenticating further comprising generating a signature on the basis of the message to be sent and the one authentication key stored for said configuration module, and including the generated signature into the message to be sent.

30. The method according to claim 28 or 29, further comprising receiving a message from said configuration module, said authenticating further comprising extracting a signature included in said received message, generating a reference signature on the basis of the received message and the one authentication key stored for said configuration module, and comparing said extracted signature with said generated reference signature.

31. The method according to any one of claims 28 to 30, wherein said reference signature generating and/or said signature generating comprising generating a signature on the basis of a message authentication code, and/or said reference signature generating and/or said signature generating comprising generating a signature on the basis of one or more of said network layer header field of said message, a transport layer header field of a message, and a transport layer payload field of said message .

32. The method according to claim 31, wherein said network and transport layers are layers of a MIPI and/or UniPro protocol.

33. The method according to any one of claims 28 to 32, wherein the authentication key is at least one of a symmetrical key and a public key assigned between said apparatus and a network node connected via one of said plurality of ports each.

34. The method according to any one of claims 28 to 33, wherein said method is operable in accordance with at least one MIPI and/or UniPro specification.

35. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 28 to 34.

36. A system comprising at least one apparatus according to any one of claims 1 to 10, which is operable as configuration module of the system, and at least one apparatus according to any one of claims 21 to 27, which is operable as a network node of a security cluster of said configuration module, and is connected to said configuration module.