DE112018002161T5 - Encryption and connection establishment for low-performance devices - Google Patents

Abstract

Systems and methods for establishing a connection between a node and the cloud entail that the present disclosure provide a new method for securing mutual authenticity and at the same time for generating encryption keys, i.e. the establishment of a trustworthy connection. The advantage of the new method is that it only uses existing encryption algorithms (i.e. AES) and no proprietary software for certification. The advantage here is that the encryption algorithms are already present in the code, since they are used for encryption, and that many embedded microcontrollers support this in the hardware.

Description

Technical field

The present disclosure relates generally to low power electronic devices and, more particularly, to power efficiency in limited power devices.

background

Embedded and battery powered devices, such as mobile devices, often have limited energy and storage resources for storing program code and data. However, many network activities currently require a relatively large amount of electrical energy to run them.

Before going into the remainder of the present disclosure, it should be understood that the disclosure may address some of the disadvantages listed or implied in this background section. Such benefit, however, is not limited to the scope of the principles disclosed or the appended claims, except to the extent expressly stated in the claims.

In addition, the discussion of technology in this background section reflects the inventor's own observations, considerations, and thoughts and is in no way intended to accurately catalog or comprehensively summarize a prior art document or practice. Therefore, the inventors expressly reject that this section is admitted or accepted prior art. In addition, the identification or implication of one or more desirable actions given here reflects the inventor's own observations and ideas and should not be considered a desirable action recognized in the art.

list of figures

• 1 ist ein Fließdiagramm, das ein Verfahren eines Verbindungsaufbaus gemäß einer Ausführungsform der beschriebenen Prinzipien darstellt; und
• 2 ist eine tabellarische Zusammenfassung der Verbindungsaufbausequenz gemäß einer Ausführungsform der beschriebenen Prinzipien.

While the appended claims accurately state the features of the present techniques, these techniques, together with their objectives and advantages, can best be understood from the following detailed description when taken in conjunction with the accompanying drawings.

• 1 FIG. 14 is a flow diagram illustrating a method of establishing a connection in accordance with an embodiment of the principles described; and
• 2 FIG. 4 is a tabular summary of the connection setup sequence according to one embodiment of the principles described.

Detailed description

Before presenting a detailed list of embodiments of the disclosed principles in claim form, an overview of embodiments is provided to assist the reader in understanding the later discussion. As mentioned above, embedded and battery powered devices, such as mobile devices, often have limited energy and storage resources for storing program code and data. However, many network activities currently require a relatively large amount of electrical energy to run them. This can have a negative impact on the life of the device battery (battery) and the operation of the device.

Using them for certification takes up very little additional space compared to algorithms used to validate a typical digital certificate. Combining a number of specific encryption steps using specific encryption keys for each step enables us to establish a complete connection establishment sequence using only these inexpensive and efficient calculations.

To explain the procedure, we must first explain the encryption keys that are in use. The SDS (SecureDataShot) communication protocol uses a number of keys to certify the authenticity of the other party, to establish secure channels, to encrypt messages and to check the integrity of each message. This section lists the keys that are in use. "Node" and "Cloud" are the two communicating parties.

Legend:

• p - public
• s - secret
• K - key
• n - node
• c - cloud
• x - node specific
• m - for multiple nodes
• 0 - initial key to key setup
• 1 - Backup key for key setup
• P - key for programming new firmware
• B - key to establish connection
• S - session key

For example, pKcOx is the cloud's initial public key for node x. A "K" without a "p" or "s" prefix indicates a common key for symmetric encryption using AES. The public and private key pairs use 256-bit keys, while AES keys are 128 bits.

Key pairs generated and programmed in production

The node generates its own keys and transfers the public parts to the cloud during production. Similarly, the cloud generates its keys and programs the public parts in the nodes during production.

The node and the cloud each have three pairs of public-private keys. Pair 0 is used for regular connection establishment.

• sKnOx - pKnOx
• sKcOx - pKcOx

Key:

• sKnOx - pKnOx
• sKcOx - pKcOx

Key pair 1: backup for pair 0

• sKn1 x - pKn1x
• sKc1 x - pKc1x

Key:

• sKn1 x - pKn1x
• sKc1 x - pKc1x

Pair P is used to program new firmware for the node.

• sKnPx - pKnPx
• sKcPx - pKcPx

Key:

• sKnPx - pKnPx
• sKcPx - pKcPx

A large number of nodes share the same key pair for exchanging node ID during connection establishment. There is only one pair for this, while the cloud has the private part and several nodes that share the same key pair have the public part.

• sKcBm - pKcBm

Key:

• sKcBm - pKcBm

Key pairs generated during connection establishment: Both the cloud and nodes generate new keys for each connection establishment. These are called session keys and connection establishment keys.

• sKnSx - pKnSx
• sKcSx - pKcSx
• sKnBx - pKnBx

Key:

• sKnSx - pKnSx
• sKcSx - pKcSx
• sKnBx - pKnBx

1 FIG. 14 is a flow diagram illustrating a method of establishing a connection in accordance with an embodiment of the principles described. At step 101 of the process 100 the node generates a new key pair for establishing the connection, sKnBx - pKnBx. These should be random and unpredictable. The public part of it (pKnBx) is sent to the cloud. This is encrypted and is signed with a MIC using a common AES key K0 for all nodes and is only used for this purpose. This does not provide security, but does allow the same functions to be used to send and receive messages. The message also contains the version number for the connection establishment procedure and the key ID for the common connection establishment key used by this node.

At step 103 the secret part of this key (sKnBx) is combined with the shared public key from the cloud for connection establishment (pKcBm) to form a shared key using the Curve25519 Elliptic Curve Diffie-Hellmann (ECDH) key agreement process. This key is called K1 designated. The same shared key ( K1 ) is generated using the public part of the node session key (pKnBx) and the secret part of the connection establishment key (sKcBm) in the cloud.

At step 105 the node sends its node ID and connection version number to the cloud for use to connect. This is done with AES using this shared key K1 encrypted. The node generates a new session key pair sKnSx - pKnSx and sends the public part (pKnSx) to the cloud using K1 for encryption.

At step 107 the cloud uses the node ID to find the node-specific initial key pair, the cloud having pKnOx and sKcOx. The cloud combines the received public session key pKnSx with its own private initial key sKcOx to form a new shared key K2 , The cloud generates a new session key pair pKcSx and sKcSx. The public part pKcSx is sent to the node using K2 for encryption.

At step 109 the node combines its secret session key, sKnSx, with the cloud's initial public key, pKcOx, using ECDH to form the new shared key K2 , The node decrypts the received message and checks the MIC. There K2 depending on the cloud's initial secret key, a correct MIC for the node verifies that the cloud is authentic because it has access to sKcOx. If we believe that the cloud, which has the secret part of the sKcBm shared connection key, is sufficient evidence of the authenticity of the cloud, this step can be skipped.

The knot then has to step 111 prove its own authenticity by showing that it has the node-specific initial secret key sKnOx. The cloud then combines the node's initial public key (pKnOx) with the cloud's secret session key (sKcSx) at step 113 , around K3 to build. The same secret key ( K3 ) can be formed by the node by combining the public session key from the cloud (pKcSx) with the secret initial key (sKnOx). The cloud knows that the node is authentic when using a correct MIC message K3 receives because it is based on the node with access to sKnOx.

From this point on, the node and cloud can communicate securely using the session key. After a certain time (or a certain number of transmissions) the session key K4 replaced. The same procedure is used to set up a new session key.

2 FIG. 4 is a tabular summary of the connection setup sequence according to one embodiment of the principles described.

It will be understood that the process steps carried out here can be carried out via computer-aided execution of computer-readable instructions from a non-transitory memory. It will also be understood that various systems and processes have been disclosed here. However, given the many possible embodiments to which the principles of the present disclosure can be applied, it should be recognized that the embodiments described herein with reference to the drawing figures are only illustrative in nature and are not to be construed as limiting the scope of the claims. Therefore, all of the techniques described herein include all such embodiments that may fall within the scope of the following claims and equivalents thereof.

Claims (1)

A method of establishing a connection between a node and the cloud, comprising: node generates a new connection establishment key pair, sKnBx - pKnBx; a secret part of this key (sKnBx) is combined with the shared public key from the cloud for connection establishment (pKcBm) to form a shared key, K1; the same shared key (K1) is generated in the cloud using the public part of the node session key (pKnBx) and the secret part of the connection establishment key (sKcBm); the node sends its node ID and connection version number to the cloud for use to connect, encrypted with AES using shared key, K1; the node generates a new session key pair sKnSx - pKnSx and sends the public part (pKnSx) to the cloud using K1 for encryption; the cloud uses the node ID to find the node-specific initial key pair, the cloud having pKnOx and sKcOx. The cloud combines the received public session key pKnSx with its own private initial key sKcOx to form a new shared key K2; the cloud generates a new pair of session keys pKcSx and sKcSx; the public part, pKcSx, is sent to the node using K2 for encryption; the node combines its secret session key sKnSx with the initial public key pKcOx of the cloud using ECDH to form the new shared key K2; the node decrypts the received message and checks the MIC; Node proves its authenticity by showing that it has the node-specific initial secret key sKnOx; Cloud combines the node's initial public key (pKnOx) with its own cloud secret session key (sKcSx) to form K3; the same secret key (K3) is formed for the node by combining the public session key from the cloud (pKcSx) with the secret initial key (sKnOx); and the cloud determines that the node is authentic when it receives a correct MIC message using K3 because it is based on the node with access to sKnOx.

Images