DE102017115756A1 - Set up a connection between network elements - Google Patents

Abstract

A method for establishing a connection between a first network element and a second network element is proposed, the method comprising: (i) setting up a first connection between the first network element and a server, wherein the first network element logs on to the server; (ii) providing a first key from the server to the first network element; (iii) establishing a second connection between the second network element and the server, the second network element indicating that it requests a connection with the first network element; (iv) providing a second key from the server to the second network element; and (v) establishing one of the connections between the first network element and the second network element by using the first key and the second key. Also, a corresponding system is provided.

Description

BACKGROUND OF THE INVENTION

Embodiments of the present invention relate to improved security for two network elements to be interconnected via the Internet.

SUMMARY

• - Aufsetzen einer ersten Verbindung zwischen dem ersten Netzwerkelement und einem Server, wobei sich das erste Netzwerkelement bei dem Server anmeldet;
• - Liefern eines ersten Schlüssels von dem Server an das erste Netzwerkelement;
• - Aufsetzen einer zweiten Verbindung zwischen dem zweiten Netzwerkelement und dem Server, wobei das zweite Netzwerkelement anzeigt, dass es eine Verbindung mit dem ersten Netzwerkelement anfordert;
• - Liefern eines zweiten Schlüssels von dem Server an das zweite Netzwerkelement;
• - Aufsetzen einer der Verbindung zwischen dem ersten Netzwerkelement und dem zweiten Netzwerkelement durch Verwenden des ersten Schlüssels und des zweiten Schlüssels.

A first embodiment relates to a method for establishing a connection between a first network element and a second network element, comprising:

• Setting up a first connection between the first network element and a server, wherein the first network element logs on to the server;
• Providing a first key from the server to the first network element;
• Establishing a second connection between the second network element and the server, the second network element indicating that it requests a connection to the first network element;
• Providing a second key from the server to the second network element;
• Setting up one of the connections between the first network element and the second network element by using the first key and the second key.

• - ein erstes Netzwerkelement;
• - ein zweites Netzwerkelement;
• - einen Server;
• - wobei das erste Netzwerkelement dafür ausgelegt ist, sich bei dem Server anzumelden;
• - wobei der Server dafür ausgelegt ist, einen ersten Schlüssel an das erste Netzwerkelement zu liefern, nachdem das erste Netzwerkelement sich bei dem Server angemeldet hat;
• - wobei das zweite Netzwerkelement dafür ausgelegt ist, eine Anforderung für eine Verbindung mit dem ersten Netzwerkelement an den Server zu senden;
• - wobei der Server dafür ausgelegt ist, einen zweiten Schlüssel an das zweite Netzwerkelement zu liefern, nachdem er die Anforderung von dem zweiten Netzwerkelement empfangen hat;
• - wobei das erste Netzwerkelement und das zweite Netzwerkelement dafür ausgelegt sind, eine die Verbindung untereinander durch Verwenden des ersten Schlüssels und des zweiten Schlüssels aufzusetzen.

A second embodiment relates to a system for setting up a connection, comprising:

• a first network element;
• a second network element;
• a server;
• - wherein the first network element is adapted to log in to the server;
• - wherein the server is adapted to deliver a first key to the first network element after the first network element has logged on to the server;
• - wherein the second network element is adapted to send a request for connection to the first network element to the server;
• - wherein the server is adapted to deliver a second key to the second network element after receiving the request from the second network element;
• - wherein the first network element and the second network element are adapted to establish a connection with each other by using the first key and the second key.

list of figures

• 1 zeigt ein beispielhaftes Szenarium, umfassend eine DPU (Distribution Point Unit), welche über das Internet mittels einer TCP/IP-Verbindung mit einem PMA (Persistent Management Agent) 103 verbunden ist;
• 2 zeigt ein beispielhaftes Szenarium, das einen MITM-Angriff visualisiert, basierend auf dem in 1 gezeigten Diagramm, wobei eine MITM-Angriffseinheit innerhalb der Verbindung zwischen der DPU und dem PMA platziert ist;
• 3 zeigt ein beispielhaftes Diagramm, umfassend eine DPU, einen PMA und einen Ladungsserver, welche über das Internet verbunden oder verbindbar sind;
• 4 zeigt ein beispielhaftes Nachrichtendiagramm zwischen der DPU und dem Ladungsserver zum Liefern eines Schlüssels an die DPU;
• 5 zeigt ein beispielhaftes Nachrichtendiagramm zwischen dem PMA und dem Ladungsserver zum Liefern eines Schlüssels an den PMA;
• 6 zeigt ein beispielhaftes Nachrichtendiagramm der sich mit dem PMA unter Verwendung der durch den Ladungsserver gelieferten Schlüssel verbindenden DPU.
• 7 zeigt ein beispielhaftes Diagramm, basierend auf 3, wobei sowohl der PMA als auch der Ladungsserver einen Verwürfeier umfassen, der symmetrische Verschlüsselungsfähigkeiten liefert.

Embodiments are illustrated and illustrated with reference to the drawings. The drawings serve to illustrate the basic principle so that only aspects necessary for understanding the fundamental principle are illustrated. The drawings are not to scale. In the drawings, the same reference characters denote like features.

• 1 shows an exemplary scenario comprising a Distribution Point Unit (DPU) connected to a PMA (Persistent Management Agent) 103 via the Internet via a TCP / IP connection;
• 2 shows an exemplary scenario visualizing a MITM attack based on the in 1 with a MITM attack unit placed within the connection between the DPU and the PMA;
• 3 FIG. 12 is an exemplary diagram including a DPU, a PMA, and a charge server connected or connectable via the Internet; FIG.
• 4 shows an exemplary message diagram between the DPU and the load server for providing a key to the DPU;
• 5 shows an exemplary message diagram between the PMA and the load server for providing a key to the PMA;
• 6 Figure 4 shows an exemplary message diagram of the DPU connecting to the PMA using the key provided by the load server.
• 7 shows an exemplary diagram based on 3 wherein both the PMA and the load server comprise a deferred eggs providing symmetric encryption capabilities.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

It is not intended that the order in which the process is described be considered as a limitation, and any number of the described process blocks may be combined in any order to implement the process or alternative processes. In addition, individual blocks may be removed from the process without departing from the spirit and scope of the subject matter described herein. Furthermore, the process may be implemented in any suitable materials or combinations thereof without departing from the scope of the subject matter described herein.

Specifically, examples described herein relate to mechanisms for increasing a level of security between network components, particularly for protecting a connection between a first network component, such as a server, and a second network component, such as a client, from a successful man-in-the-middle attack or MITM attack).

A connection between two devices over an unsecured medium, such as the Internet, could be secured by public key cryptography, such as Secure Shell / Transport Layer Security (SSH). However, such a concept is vulnerable to MITM attacks.

1 FIG. 12 shows an example scenario including a DPU (Distribution Point Unit) 101 over the Internet 102 via a TCP / IP connection 104 with a PMA (Persistent Management Agent) 103 connected is.

The DPU 101 may be a device of a communication network that has firmware. The firmware version of the DPU 101 can also be called a charge. The DPU 101 can by the PMA 103 be remotely managed and / or controlled. The PMA 103 may be a device or a cloud-based application that runs in particular on a device, a virtual machine, on a server farm or the like. In this regard, the PMA 103 a software instance, or it may include multiple such software instances.

Such a remotely controlled / controlled architecture suffers from the disadvantage that the entire Internet between the PMA 103 and the DPU 101 which carries a significant risk for potential MITM attacks.

2 shows an exemplary scenario that visualizes a MITM attack: Based on 1 can the TCP / IP connection 104 within the internet 102 through a unit 201 be redirected, which facilitates the MITM attack. The unit 201 has a TCP / IP connection 202 with the DPU 101 and another TCP / IP connection 203 with the PMA 103 on.

Public key encryption, e.g. B. SSH, may be on the connection 104 between the DPU 101 and the PMA 103 be used. If such an encrypted connection has been successfully established, it is immune to MITM attacks. However, the weakness of such a connection is the exchange of the public key before the encrypted connection is set up. If such exchange public keys over the unit 201 is done, the MITM attack already finds itself before an encrypted connection between the DPU 101 and the PMA 103 instead: in such a case, the encrypted connection appears as in operation, whereas the DPU 101 actually a secure line with the unit 201 has manufactured and the unit 201 a secure line with the PMA 103 has produced. Thus, the MITM attacker, ie the unit 201 , opposite the DPU 101 successful a PMA entity and against the PMA 103 simulate a DPU entity.

Once an attacker becomes aware of any private key, all communications can be corrupted. This is especially risk-laden, given the PMA 103 can be a cloud application, ie a piece of software that can be easily accessed, e.g. By hacking or reverse engineering.

According to one example of the solution described herein, a key exchange instance may be provided or an already existing instance may be used for this purpose of key exchange. This instance can be a controlled instance, e.g. For example, a company-controlled entity that provides some level of trust. The instance for a key exchange is also referred to herein as a key exchange server or a load server.

The cargo server may be a network device that includes, in particular, different firmware versions for the devices used, and their firmware versions or cloud-based applications may be referred to as loads.

3 shows an exemplary diagram comprising a DPU 301 , a PMA 303 and a cargo server 304 which over the internet 302 connected or connectable.

The PMA 303 may be a device or a cloud-based application that runs in particular on a device, a virtual machine, on a server farm or the like.

The DPU 301 is with the PMA 303 via an SSH connection 305 connected, the DPU is with the server load 304 via an SSH connection 306 connected and the PMA 303 is with the cargo server 304 via an SSH connection 307 connected. It should be noted that SSH is an example of an encrypted connection; other types of encrypted connections can be used accordingly.

In this scenario, the DPU sets 301 the SSH connection 305 to the PMA 303 not right on. Instead, the DPU puts 301 the SSH connection 306 to the cargo server 304 ago. Accordingly, the PMA 303 the SSH connection 307 to the cargo server 304 ago. With both SSH connections 306 and 307 made, the charge server sends 304 a key (for example, a private key) to the PMA 303 and another key (a public key) to the DPU 301 ,

This approach significantly increases security and degrades the chances of a successful MITM attack. It is also an advantage of this approach that upgrade mechanisms and initial configurations of a remote access node are improved.

As mentioned above, try the DPU 301 and the PMA 303 initially not to be connected. Instead, try the DPU 301 and the PMA 303 initially, a connection to the cargo server 304 manufacture.

This is useful because the cargo server 304 can be a solid entity with a known address, which even in the firmware of the DPU 301 and / or the PMA 303 can be preconfigured. It should be noted that either the DPU 301 or the PMA 303 first with the cargo server 304 combines.

4 shows an exemplary message diagram between the DPU 301 and the cargo server 304 ,

The DPU 301 sets the SSH connection 306 (Session) with the cargo server 304 on. Because the destination address of the load server 304 is fixed (ie it can be assigned a fixed URL or IP address), the load server can 304 directly through the DPU 301 be addressed.

There is an option to use fixed keys in the DPU 301 are configured or to calculate and use (dynamic) keys. Using fixed keys can be an option as the DPU 301 a device that can be difficult to reverse engineer (to get the solid key) and the cargo server 304 may be located at the registered office of the company offering the service, which may be considered sufficiently secure.

Once the SSH connection 306 is attached, sends the DPU 301 a message 401 to the cargo server 304 , The message 401 includes a serial number and a current charge name (the DPU 301 ).

The cargo server 304 checks (see step 403 ), whether there is already a registered PMA, which this DPU 301 want to configure. If there is a pending request from the PMA 303 gives the charge server calculates 304 a checksum (a hash value from a software image of the load name, which software on the DPU 301 runs) and transmits a message 402 to the DPU 301 , These news 402 includes the checksum, a public key of the PMA 303 and a destination IP address of the PMA 303 ,

The checksum can be made using a message-digest algorithm 5 (MD5).

If there is no available request from a PMA, with the DPU 301 the cargo server ignores 304 the message 401 and send the message 402 not to the DPU 301 ,

If the DPU 301 the message 402 receives, checks them in one step 404 whether the checksum is correct (this can be done by calculating the hash value from the software image of the load name and comparing it with the one in the message 402 transmitted hash value).

If the checksum check is correct, the DPU tries 301 , the SSH connection 305 with the PMA 303 using the public key of the PMA 303 and the IP address of the PMA 303 both from the message 402 obtained, see step 405 ).

If the checksum check is incorrect, the DPU will try 301 not, the SSH connection 305 to the PMA 303 manufacture.

If the message 402 not within a predefined period of time after the message 401 is sent, the DPU repeats sending the message 401 (see step 406 ).

If the DPU 301 and the cargo server 304 be supplied by a trust body, z. B. from a company providing both units, there is the option of communication (or part of the communication) between the DPU 301 and the cargo server 304 to encrypt. It is in particular an option that the destination IP address of the cargo server 304 is encrypted and the cargo server 304 Decrypts this destination IP address and compares it with its own IP address to make sure it's between the DPU 301 and the cargo server 304 There is no MITM attack.

5 shows an exemplary message diagram between the PMA 303 and the cargo server 304 ,

The PMA 303 tried the cargo server 304 to reach and the SSH connection 307 to the cargo server 304 build.

About the message 501 the PMA answers 303 even at the cargo server 304 and urges the DPU 301 to configure. The serial number of the DPU 301 is in this message 501 provided.

As an option, a running software name (from one on the PMA 303 running software), for example a checksum of the software image of the remote device, in the message 501 for which a checksum (hash value) is determined and for verification to the PMA 303 is sent back.

In an exemplary scenario, the DPU would like to 301 with the PMA 303 connect and the DPU 301 already has the public key of the PMA 303 receive. The DPU 301 Encrypts your public key using the public key of the PMA 303 and send it to the PMA via a message 303 , The PMA 303 decrypts this message with his private key. This causes the PMA 303 from the public key of the DPU 301 experiences.

In another scenario, the public key of the DPU must be 301 possibly via the cargo server 304 to the PMA 303 to be delivered. In this scenario, the DPU 301 encrypt your own public key and send it by message to the PMA 303 send. The PMA 303 can then get the decrypted public key from the DPU 301 Use and additionally, the PMA 303 the decrypted public key of the DPU 301 with the one he already has from the cargo server 304 received, verify.

In one step 507 has become the DPU 301 successful at the load server 304 logged in (see above 4 ).

5 shows two different scenarios, a scenario 502 with the PMA 303 as the master of the keys and another scenario 503 with the cargo server 304 as the master of the keys. The scenario 503 may be advantageous in terms of safety.

In the scenario 502 is the PMA 303 the master of the key pair, ie that of the PMA 303 its key pair (including the public key and the private key) and only the public key of this key pair to the load server 304 transfers. The cargo server 304 then transmits this public key to the DPU 301 , The PMA 303 can then (in one step 505 ) on the application of the DPU 301 waiting.

In the scenario 503 is the cargo server 304 the master of the keys. Thus, the charge server calculates 304 the key pair and transmits the private key to the PMA 303 and the public key to the DPU 301 , The PMA 303 can then (in one step 505 ) on the application of the DPU 301 waiting.

Depending on the key mechanism to be used (see the notes on cryptography below), for example, the connection may be made using the exchanged data (ie, the one from the PMA 303 to the DPU 301 transferred public key) are constructed.

The scenarios 502 and 503 are mainly scenarios between the PMA 303 and the cargo server 304 , Both the unit PMA 303 as well as the cargo server 304 may in particular be unaware of how the key pair of the DPU 301 was created. This can be true even if the cargo server 304 the master of the keys to the PMA 303 is (ie that this does not necessarily mean that the cargo server 304 also the master of the keys for DPU 301 is).

6 shows an exemplary message diagram associated with the PMA 303 connecting DPU 301 ,

According to the communications described above 4 and 5 have both sides, ie the DPU 301 and the PMA 303 who receive secret keys.

It is also an option that the cargo server 304 not the public key to the DPU 301 and not the private key (according to the scenario 503 ) to the PMA 303 transfers; instead, the cargo server can 304 a session key for symmetric Encryption and recalculate this session key to the PMA 303 and the DPU 301 transfer.

By means of a message 601 sends the DPU 301 using the from the cargo server 304 received key an encrypted message to the PMA 303 (in the message 402 , as in 4 is shown).

In a message 602 from the PMA 303 to the DPU 301 accepted the PMA 303 the by means of the message 601 transferred application.

In a message 603 from the PMA 303 to the DPU 301 configured the PMA 303 the DPU 301 , From then on, the communication between the DPU 301 and the PMA 303 the PMA 303 enable them to obtain statistics and other information as if they were the DPU 301 and the PMA 303 directly connected (by the double arrow 604 displayed).

In an exemplary scenario, the connection may be 307 between the PMA 303 and the cargo server 304 be the weakest link in terms of security. However, an attacker gets even if a MITM attack within the connection 307 In a worst-case scenario, only one key would be placed, which can only be exploited if the same attacker also uses the connection at the same time 305 between the DPU 301 and the PMA 303 successfully infiltrated. However, this is unlikely as the links 305 and 307 located within the vast sphere of the internet and thus difficult to find and select. By having separate connections 305 . 306 and 307 instead of a single connection between the DPU 301 and the PMA 303 MITM attack is made significantly more difficult because it is no longer sufficient for an attacker to successfully attack only a single connection.

7 shows an exemplary diagram based on 3 where both the PMA 303 as well as the cargo server 304 a scrambler 701 . 702 for symmetric encryption over the connection 307 includes.

The scrambler 701 . 702 Each is a functionality (hardware and / or software) that includes symmetric encryption. Thus, the communication between the cargo server 304 and the PMA 303 about the connection 307 also encrypted using a common passphrase.

This increases the security level. In an exemplary scenario, the PMA 303 deployed on a server farm that can host about 1 million PMA instances, each of which PMA instances encrypted to the cargo server 304 can use.

Symmetric key encryption can share a shared medium, such as sharing a symmetric key encrypted line for many users (here many PMA instances 303 ). This reduces the required actual point-to-point connections. In such a scenario, a server farm or part of the server farm may have at least one scrambler 702 to operate a one-to-one connection to the cargo server 304 use. Advantageously, all traffic between the PMA 303 (be it a single PMA or a plurality of PMA instances) and the load server 304 scrambled and encrypted using a symmetric key. Also, key exchange for the SSH connection can use this symmetric encryption.

Notes on cryptography:

A public key mechanism can use asymmetric encryption. In such a case, both devices, such as the DPU and the PMA, have their own public and private key pairs. In this example, the DPU and the PMA are exemplary entities that use asymmetric encryption. However, applying such encryption is not limited to these entities.

The DPU encrypts an initial message using the public key of the PMA. The PMA decrypts this message using its own private key. The response from the PMA to the DPU is encrypted using the public key of the DPU and this response can be decrypted by the DPU with its private key.

1. (1) Nur der öffentliche Schlüssel eines Servers ist bekannt:
   • Beispielsweise kann die DPU den öffentlichen Schlüssel des PMA kennen. Die DPU verschlüsselt eine Nachricht unter Verwendung dieses öffentlichen Schlüssels des PMA, wobei der öffentliche Schlüssel der DPU in dieser verschlüsselten Nachricht enthalten ist. Die Nachricht wird von der DPU an den PMA gesendet. Der PMA ist in der Lage, die Nachricht zu entschlüsseln und somit den öffentlichen Schlüssel der DPU aus dieser Nachricht zu erhalten.
   • Allerdings kann es eine Schwierigkeit dabei geben, den öffentlichen Schlüssel des PMA anfänglich für die DPU verfügbar zu machen. Mit anderen Worten: Wie wird der öffentliche Schlüssel des Servers (hier der PMA) für den Client (hier die DPU) verfügbar gemacht? Eine Lösung besteht darin, dass der öffentliche Schlüssel des Servers in den Client compiliert wird. Dieser öffentliche Schlüssel kann fest sein. Dies kann zu dem Faktum führen, dass auch der private Schlüssel fest ist, was für manche Anwendungen schädlich sein kann. Eine andere Lösung besteht darin, dass der Client den öffentlichen Schlüssel dynamisch erhält, beispielsweise pro Sitzung, über eine Drittpartei (beispielsweise eine Vertrauensentität). In einem solchen Szenarium kann das Schlüsselpaar variieren und ein neues Schlüsselpaar könnte pro Sitzung oder gemäß einem vorbestimmten (z. B. Zeit-) Muster ausgegeben werden.
2. (2) Der Server liefert den öffentlichen Schlüssel auf Abruf:
   • Der Server kann einen Mechanismus zum Liefern des öffentlichen Schlüssels in Klartext unterstützen, beispielsweise auf eine Anforderung von dem Client.
   • In diesem Beispiel kann die DPU den öffentlichen Schlüssel in Klartext erhalten, nachdem er von dem PMA angefordert wurde. Danach ist der gleiche Mechanismus wie unter (1) beschrieben anwendbar.
3. (3) Server und Client kennen bereits die öffentlichen Schlüssel von der jeweiligen anderen Einheit:
   • In einem solchen Fall muss kein öffentlicher Schlüssel an irgendeine der Einheiten, beispielsweise den PMA und die DPU übertragen werden, und die verschlüsselte Kommunikation kann wie beschrieben vorgenommen werden.
4. (4) Server und Client verwenden dasselbe öffentliche/private Schlüsselpaar:
   • Dies kann ein Ansatz mit einem verringerten Sicherheitsniveau sein. Andererseits ist dies eine Option zum Verwenden desselben Schlüsselpaars auf der Server- und der Client-Seite für eine asymmetrische Verschlüsselung. Das Schlüsselpaar kann in den Einheiten implementiert sein oder es kann auf Anfrage erhalten werden.

However, there are some ways to get a public key from a counterparty unit:

1. (1) Only the public key of a server is known:
   • For example, the DPU may know the public key of the PMA. The DPU encrypts a message using this public key of the PMA with the public key of the DPU included in this encrypted message. The message is sent from the DPU to the PMA. The PMA is able to decrypt the message and thus obtain the public key of the DPU from this message.
   • However, there may be some difficulty in making the public key of the PMA initially available to the DPU. In other words, how is the public key of the server (here the PMA) made available to the client (here the DPU)? One solution is to compile the public key of the server into the client. This public key can be fixed. This can lead to the fact that the private key is also fixed, which can be harmful for some applications. Another solution is that the client receives the public key dynamically, for example, per session, through a third party (for example, a trust entity). In such a scenario, the key pair may vary and a new key pair may be issued per session or according to a predetermined (eg, time) pattern.
2. (2) The server delivers the public key on demand:
   • The server may support a mechanism for providing the public key in plain text, for example, at the request of the client.
   • In this example, the DPU may receive the public key in plain text after being requested by the PMA. Thereafter, the same mechanism as described in (1) is applicable.
3. (3) Server and client already know the public keys from the other unit:
   • In such a case, no public key needs to be transmitted to any of the units, such as the PMA and the DPU, and the encrypted communication can be made as described.
4. (4) Server and client use the same public / private key pair:
   • This can be an approach with a reduced level of security. On the other hand, this is an option to use the same key pair on the server side and the client side for asymmetric encryption. The key pair can be implemented in the units or it can be obtained on request.

1. (a) Kommunikation zwischen Server und Client unter Verwendung von asymmetrischer Verschlüsselung:
   • Die wie oben erläutert aufgesetzte asymmetrische Verschlüsselung kann für jegliche Kommunikation (vollständige oder ein Teil der Kommunikation) zwischen dem Client und dem Server verwendet werden.
2. (b) Kommunikation zwischen Server und Client unter Verwendung von symmetrischer Verschlüsselung:
   • Nach der Initialisierungsphase unter Verwendung von asymmetrischer Verschlüsselung kann unter Verwendung dieser asymmetrischen Verschlüsselung ein Sitzungsschlüssel zwischen Server und Client verteilt werden und dieser Sitzungsschlüssel wird als ein symmetrischer Schlüssel zum Verschlüsseln der Kommunikation (oder mindestens eines Teils der Kommunikation) zwischen dem Server und dem Client verwendet.
   • Somit kann die asymmetrische Verschlüsselung nur verwendet werden zum Herstellen eines verschlüsselten Kommunikationskanals zwischen der DPU und dem PMA. Die DPU oder der PMA kann einen neuen (symmetrischen) Schlüssel bestimmen (z. B. berechnen), welcher mittels der Verschlüsselung mit asymmetrischem öffentlichen Schlüssel an die Gegenpartei übermittelt wird. Danach sind beide Seiten, d. h. der PMA und die DPU, in der Lage, diesen symmetrischen Schlüssel für Verschlüsselungs- und Entschlüsselungszwecke zu verwenden.

However, the server and client have established a secure connection after the initialization phase. Then one of the following options can be used:

1. (a) Communication between server and client using asymmetric encryption:
   • The asymmetric encryption set up as described above may be used for any communication (complete or part of the communication) between the client and the server.
2. (b) Communication between server and client using symmetric encryption:
   • After the initialization phase using asymmetric encryption, using this asymmetric encryption, a session key may be distributed between server and client, and this session key is used as a symmetric key for encrypting the communication (or at least part of the communication) between the server and the client.
   • Thus, asymmetric encryption can only be used to establish an encrypted communication channel between the DPU and the PMA. The DPU or PMA may determine (eg, compute) a new (symmetric) key which is transmitted to the counterparty using asymmetric public key encryption. After that, both sides, ie the PMA and the DPU, are able to use this symmetric key for encryption and decryption purposes.

In particular, the examples proposed herein may be based on at least one of the following solutions. In particular, combinations of the following features could be used to achieve a desired result. The features of the method could be combined with any one or more features of the device, device, or system, or vice versa.

• - Aufsetzen einer ersten Verbindung zwischen dem ersten Netzwerkelement und einem Server, wobei sich das erste Netzwerkelement bei dem Server anmeldet;
• - Liefern eines ersten Schlüssels von dem Server an das erste Netzwerkelement;
• - Aufsetzen einer zweiten Verbindung zwischen dem zweiten Netzwerkelement und dem Server, wobei das zweite Netzwerkelement anzeigt, dass es eine Verbindung mit dem ersten Netzwerkelement anfordert;
• - Liefern eines zweiten Schlüssels von dem Server an das zweite Netzwerkelement;
• - Aufsetzen einer der Verbindung zwischen dem ersten Netzwerkelement und dem zweiten Netzwerkelement durch Verwenden des ersten Schlüssels und des zweiten Schlüssels.

A method for establishing a connection between a first network element and a second network element is provided, comprising:

• Setting up a first connection between the first network element and a server, wherein the first network element logs on to the server;
• Providing a first key from the server to the first network element;
• Establishing a second connection between the second network element and the server, wherein the second network element indicates that it requests a connection with the first network element;
• Providing a second key from the server to the second network element;
• Setting up one of the connections between the first network element and the second network element by using the first key and the second key.

In one example, the first network element may be a DPU and the second network element may be a PMA. The server can be a key exchange server. The DPU and the key exchange server may be implemented substantially as separate hardware units, where the PMA may be implemented as software or hardware.

In one embodiment, the first network element is a DPU.

In one embodiment, the second network element is a PMA.

In one embodiment, the first network element registers with the server by providing identification of the first network element.

This identification of the first network element may be a serial number and / or software information (for example, a version or any type of charge information). Thus, the registration of the first network element at the server can be made based on the identification of the first network element.

In one embodiment, the server does not deliver the first key to the first network element when a request from the second network element to connect to the first network element is pending.

In one embodiment, the server provides the first key to the first network element when no request from a network element to connect to the first network element is pending.

• - nach Anmeldung des ersten Netzwerkelements bestimmt der Server eine Prüfsumme auf Grundlage von durch das erste Netzwerkelement bereitgestellten Informationen und überträgt die Prüfsumme mit dem ersten Schlüssel an das erste Netzwerkelement;
• - das erste Netzwerkelement prüft die Prüfsumme, um zu bestimmen, dass es der Ursprung der Anmeldungsanforderung war.

In one embodiment:

• after the first network element has been registered, the server determines a checksum based on information provided by the first network element and transmits the checksum with the first key to the first network element;
• The first network element examines the checksum to determine that it was the origin of the login request.

• - der Server liefert den ersten Schlüssel und eine Adresse des zweiten Netzwerkelements an das erste Netzwerkelement;
• - die Verbindung zwischen dem ersten Netzwerkelement und dem zweiten Netzwerkelement wird durch Verwenden des ersten Schlüssels, des zweiten Schlüssels und der Adresse des zweiten Netzwerkelements aufgesetzt.

In one embodiment:

• - The server delivers the first key and an address of the second network element to the first network element;
• the connection between the first network element and the second network element is established by using the first key, the second key and the address of the second network element.

In one embodiment, the first network element again attempts to set up the first connection between the first network element and the server if it does not receive the first key within a predetermined time period.

Thus, by the first network element, a timer (time out) can be used to log on to the server if no response or, in particular, no first key is received.

In one embodiment, the server provides the second key to the second network element when or after the first network element successfully logs on to the server.

In one embodiment, symmetric encryption is added to the first connection and / or the second connection.

This can be achieved by adding a scrambler capable of symmetric encryption to the first network element and / or the second network element as well as to the server.

In one embodiment, each connection may use public-key cryptography.

For example, each of the three connections between the first network element, the second network element and the server may comprise an SSH connection.

• - Konfigurieren des ersten Netzwerkelements durch das zweite Netzwerkelement;
• - Liefern einer Statistik von dem ersten Netzwerkelement an das zweite Netzwerkelement.

In one embodiment, the connection between the first network element and the second network element is used for at least one of the following:

• - configuring the first network element by the second network element;
• Providing statistics from the first network element to the second network element.

One option in particular is that the connection between the network elements is used for management, control and monitoring purposes. Another option is to use the connection to transfer commands or instructions from one network element to the other. As an example, in a case where a corrupted device has been detected, a fire or clear command may be issued. Another option is to disable a device due to some command.

Another option for using the connection is an automatic software upgrade or downgrade. For example, if devices of a certain area are running the same software version, that link could be used to update (downgrade) a device even before the counterparty is available. This facilitates integration of new devices into an existing network.

In one embodiment, the request of the second network element comprises an identification of the second network element.

• - nachdem das zweite Netzwerkelement die Anforderung an den Server übertragen hat, bestimmt der Server eine Prüfsumme auf Grundlage von durch das zweite Netzwerkelement bereitgestellten Informationen und überträgt die Prüfsumme mit dem zweiten Schlüssel an das zweite Netzwerkelement;
• - das zweite Netzwerkelement prüft die Prüfsumme, um zu bestimmen, dass es der Ursprung der Anforderung, mit dem ersten Netzwerkelement verbunden zu werden, war.

In one embodiment:

• after the second network element has transmitted the request to the server, the server determines a checksum based on information provided by the second network element and transmits the checksum with the second key to the second network element;
• the second network element examines the checksum to determine that it was the origin of the request to connect to the first network element.

In one embodiment, each connection is made across the Internet.

Thus, the first network element, the second network element and the server are connected to the Internet and the connection between these components is transmitted over the Internet or, in other words, as an Internet connection using e.g. B. an Internet Protocol made.

• - ein erstes Netzwerkelement;
• - ein zweites Netzwerkelement;
• - einen Server;
• - wobei das erste Netzwerkelement dafür ausgelegt ist, sich bei dem Server anzumelden;
• - wobei der Server dafür ausgelegt ist, einen ersten Schlüssel an das erste Netzwerkelement zu liefern, nachdem das erste Netzwerkelement sich bei dem Server angemeldet hat;
• - wobei das zweite Netzwerkelement dafür ausgelegt ist, eine Anforderung für eine Verbindung mit dem ersten Netzwerkelement an den Server zu senden;
• - wobei der Server dafür ausgelegt ist, einen zweiten Schlüssel an das zweite Netzwerkelement zu liefern, nachdem er die Anforderung von dem zweiten Netzwerkelement empfangen hat;
• - wobei das erste Netzwerkelement und das zweite Netzwerkelement dafür ausgelegt sind, eine die Verbindung untereinander durch Verwenden des ersten Schlüssels und des zweiten Schlüssels aufzusetzen.

Also proposed is a system for setting up a connection, comprising

• a first network element;
• a second network element;
• a server;
• - wherein the first network element is adapted to log in to the server;
• - wherein the server is adapted to deliver a first key to the first network element after the first network element has logged on to the server;
• - wherein the second network element is adapted to send a request for connection to the first network element to the server;
• - wherein the server is adapted to deliver a second key to the second network element after receiving the request from the second network element;
• - wherein the first network element and the second network element are adapted to establish a connection with each other by using the first key and the second key.

Although various embodiments of the invention have been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the invention without departing from the spirit and scope of the invention. It will be apparent to those of ordinary skill in the art that other components performing the same functions may be appropriately substituted. It should be noted that features explained with reference to a specific figure can be combined even in cases with features of other figures in which this has not been explicitly mentioned. Further, the methods of the invention can be achieved either in pure software implementations using the appropriate processor instructions or in hybrid implementations that utilize a combination of hardware logic and software logic to achieve the same results. It is intended that such modifications to the inventive concept be covered by the appended claims.

Claims (17)

A method of establishing a connection between a first network element and a second network element, comprising: establishing a first connection between the first network element and a server, wherein the first network element logs on to the server; - Providing a first key from the server to the first network element; Establishing a second connection between the second network element and the server, the second network element indicating that it requests a connection to the first network element; Providing a second key from the server to the second network element; Setting up one of the connections between the first network element and the second network element by using the first key and the second key. Method according to Claim 1 in which the first network element is a DPU. Method according to one of the preceding claims, in which the second network element is a PMA. Method according to one of the preceding claims, wherein the first network element logs on to the server by providing an identification of the first network element. The method of any one of the preceding claims, wherein the server provides the first key to the first network element if a request from the second network element to be connected to the first network element is pending. Method according to Claim 5 in that the server does not deliver the first key to the first network element when no request from a network element to connect to the first network element is pending. Method according to one of the preceding claims, in which, after the first network element has been registered, the server determines a checksum based on information provided by the first network element and transmits the checksum with the first key to the first network element; in which the first network element checks the checksum to determine that it was the origin of the login request. Method according to one of the preceding claims, - wherein the server provides the first key and an address of the second network element to the first network element; - In which the connection between the first network element and the second network element by using the first key, the second key and the address of the second network element is set up. The method of any preceding claim, wherein the first network element retries to set up the first connection between the first network element and the server if it does not receive the first key within a predetermined time period. Method according to one of the preceding claims, in which the server delivers the second key to the second network element if or after the first network element has successfully logged on to the server. Method according to one of the preceding claims, in which a symmetric encryption is added to the first connection and / or the second connection. A method according to any one of the preceding claims, wherein each connection can use public-key cryptography. Method according to one of the preceding claims, in which the connection between the first network element and the second network element is used for at least one of the following: - configuring the first network element by the second network element; Providing statistics from the first network element to the second network element. Method according to one of the preceding claims, wherein the request of the second network element comprises an identification of the second network element. Method according to one of the preceding claims, in which, after the second network element has transmitted the request to the server, the server determines a checksum based on information provided by the second network element and transmits the checksum with the second key to the second network element; in which the second network element checks the checksum to determine that it originated the request to connect to the first network element. A method according to any one of the preceding claims, wherein each of the connections is made via the Internet. A system for establishing a connection, comprising: - a first network element; - a second network element; a server; - wherein the first network element is configured to log in to the server; - wherein the server is arranged to deliver a first key to the first network element after the first network element has logged on to the server; - wherein the second network element is configured to send a request for connection to the first network element to the server; - wherein the server is arranged to deliver a second key to the second network element after receiving the request from the second network element; - wherein the first network element and the second network element are arranged to establish a connection with each other by using the first key and the second key.

Images