WO2018197590A1

WO2018197590A1 - Encryption and link bringup for low power devices

Info

Publication number: WO2018197590A1
Application number: PCT/EP2018/060646
Authority: WO
Inventors: Sigve TJORA; Jorgen TEGDAN
Original assignee: Disruptive Technologies Research As
Priority date: 2017-04-25
Filing date: 2018-04-25
Publication date: 2018-11-01
Also published as: WO2018197590A9; GB201916942D0; GB2576845B; DE112018002161T5; GB2576845A

Abstract

Systems and methods for link bring-up between a node and the cloud entail the This disclosure provides a new method for securing mutual authenticity and at the same time establishing encryption keys, i.e. establishing a trusted link. The benefit of the new method is that it only uses established encryption algorithms (i.e. AES) and no special software for certification. The advantage of this is that encryption algorithms are already present in the code since they will be used for encryption and that many embedded microcontrollers have support for this in hardware.

Description

ENCRYPTION AND LINK BRINGUP FOR LOW POWER DEVICES

TECHNICAL FIELD

[0001] The present disclosure is related generally to low power electronic devices and, more particularly, to power efficiency in limited power devices.

BACKGROUND

[0002] Embedded and battery operated devices such as mobile devices often have limited resources in terms of energy and memory for storing program code and data. However, many network activities currently require a relatively large amount of electrical power to execute.

[0003] Before proceeding to the remainder of this disclosure, it should be appreciated that the disclosure may address some of the shortcomings listed or implicit in this Background section. However, any such benefit is not a limitation on the scope of the disclosed principles, or of the attached claims, except to the extent expressly noted in the claims.

[0004] Additionally, the discussion of technology in this Background section is reflective of the inventors' own observations, considerations, and thoughts, and is in no way intended to be, to accurately catalog, or to comprehensively summarize any prior art reference or practice. As such, the inventors expressly disclaim this section as admitted or assumed prior art. Moreover, the identification or implication herein of one or more desirable courses of action reflects the inventors' own observations and ideas, and should not be assumed to indicate an art-recognized desirability. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0005] While the appended claims set forth the features of the present techniques with particularity, these techniques, together with their objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawing:

[0006] Figure 1 is a flowchart showing a method of link bring-up in accordance with an embodiment of the described principles; and

[0007] Figure 2 is a table summary of the link bring-up sequence in accordance with an embodiment of the described principles.

DETAILED DESCRIPTION

[0008] Before presenting a detailed recitation of embodiments of the disclosed principles in claim form, an overview of embodiments is given to aid the reader in understanding the later discussion. As noted above, Embedded and battery operated devices such as mobile devices often have limited resources in terms of energy and memory for storing program code and data. However, many network activities currently require a relatively large amount of electrical power to execute. This can have a negative impact on device battery life and device operation.

[0009] Using them for certification requires very little additional memory compared to other algorithms needed to verify a typical digital certificate. Combining a series of specific encryption steps using specific encryption keys for each step allows us to build a complete link bring -up sequence using only these low-cost and efficient calculations.

[0010] To explain the method, we first need to explain the encryption keys that are in use. The communication protocol SDS (SecureDataShot) uses a number of keys for certifying the authenticity of the other party, for establishing secure channels, encrypting messages and verifying the integrity of each message. This section lists the keys that are in use. "node" and "cloud" are the two parties communicating.

Legend : p - public s - secret

K - Key n - node c - cloud x - node specific m - for multiple nodes.

0 - initial key for key establishment

1 - backup key for key establishment

P - key for programming new firmware B - key for link bring-up S - session key

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

[0012] Key pairs generated and programmed in production [0013] The node generates its own keys and transmits the public parts to the cloud during production. Similarly, the cloud generates its keys and programs the public parts into the node during production.

[0014] Node and cloud has 3 pairs of public-private keys each. Pair 0 is used for regular link bring-up

Keys: sKnOx - pKnOx sKcOx - pKcOx [0015] Pair 1 keys: backup for pair 0 Keys: sKnlx - pKnlx sKclx - pKclx

[0016] Pair P is used for programming new firmware to the node. Keys: sKnPx - pKnPx sKcPx - pKcPx

[0017] A large number of nodes share the same key pair for exchanging node ID during link bring-up. For this there is only one pair where the cloud holds the private part and multiple nodes sharing the same key pair hold the public part. Keys: sKcBm - pKcBm

[0018] Key pairs generated during link bring -up: Both cloud and node generate new keys for each link bring up. These are called session keys and bring up keys.

Keys: sKnSx - pKnSx sKcSx - pKcSx sKnBx - pKnBx

[0019] Figure 1 is a flowchart showing a method of link bring-up in accordance with an embodiment of the described principles. At stage 101 of the process 100, the node generates a new link bring-up key pair, sKnBx - pKnBx. These should be random and unpredictable. The public part of this (pKnBx) is sent to the cloud. This is encrypted and signed with a MIC using a common AES key K0 for all nodes and used for this purpose only. This does not provide security, but it allows the same functions for sending and receiving messages to be used. Included in the message is also the version number for the link bring up scheme and the key ID for the common link bring-up key used by this node.

[0020] At stage 103, the secret part of this key (sKnBx) is combined with the common public key from the cloud for link bring-up (pKcBm) to form a shared key using Curve25519 Elliptic curve Diffie-Hellman (ECDH) key agreement scheme. This key is called Kl . The same shared key (Kl) is generated in the cloud using the public part of the node session key (pKnBx) and the secret part of the link bring-up key (sKcBm). [0021] At stage 105, the node sends its node ID and the link version number to use for the bring up to the cloud. This is encrypted with AES using this shared key Kl . The node generates a new session key pair sKnSx - pKnSx and sends the public part (pKnSx) to the cloud using Kl for encryption.

[0022] At stage 107, the cloud uses the node ID to find the node specific initial key pairs, where the cloud has 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.

[0023] At stage 109 the node combines its secret session key, sKnSx with the cloud's initial public key, pKcOx using ECDH for form the new shared key K2. The node decrypts the message received and verifies the MIC. Since K2 is dependent on the cloud's initial secret key, a correct MIC verifies for the node that the cloud is authentic because it has access to sKcOx. If we believe that the cloud having the secret part of the common bring-up key sKcBm is sufficient proof of authenticity of the cloud, this step can be skipped.

[0024] The node then needs to prove its authenticity at stage 111 by showing that it has the node specific initial secret key, sKnOx. The cloud the combine the node's public initial key (pKnOx) with the cloud's secret session key (sKcSx) at stage 1 13 to form K3. 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 The cloud will know the node is authentic when it receives a message with correct MIC using K3, since this is based on the node having access to sKnOx.

[0025] From this point the node and cloud can communicate securely using the session key. After a given time (or given number of transmissions), the session key K4 will be replaced. The same procedure is used for establishing a new session key. [0026] Figure 2 is a table summary of the link bring-up sequence in accordance with an embodiment of the described principles.

[0027] It will be appreciated that the process steps executed herein may be executed via the computerized execution of computer-readable instructions from a non-transitory memory. It will also be appreciated that various systems and processes have been disclosed herein. However, in view of the many possible embodiments to which the principles of the present disclosure may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the claims. Therefore, the techniques as described herein contemplate all such embodiments as may come within the scope of the following claims and equivalents thereof.

Claims

CLAIMS We claim:

1. A method for link bring -up between a node and the cloud comprising:

node generates a new link bring-up key pair, sKnBx - pKnBx;

a secret part of this key (sKnBx) is combined with the common public key from the cloud for link bring-up (pKcBm) to form a shared key, Kl;

the same shared key (Kl) is generated in the cloud using the public part of the node session key (pKnBx) and the secret part of the link bring-up key (sKcBm);

the node sends its node ID and the link version number to use for the bring up to the cloud, encrypted with AES using shared key Kl;

the node generates a new session key pair sKnSx - pKnSx and sends the public part (pKnSx) to the cloud using Kl for encryption;

the cloud uses the node ID to find the node specific initial key pairs, where the cloud has 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;

the node combines its secret session key, sKnSx with the cloud's initial public key, pKcOx using ECDH for form the new shared key K2;

the node decrypts the message received and verifies the MIC;

node proves its authenticity by showing that it has the node specific initial secret key, sKnOx;

cloud combines the node's public initial key (pKnOx) with the cloud's secret session key (sKcSx) to form K3;

same secret key (K3) formed by node by combining public session key from the cloud (pKcSx) with the secret initial key (sKnOx); and

cloud determines node is authentic when it receives a message with correct MIC using K3, as this is based on the node having access to sKnOx.