In any technology based on data exchange, security is a crucial property, where cryptography plays a key role. Let's see how this field developed in the past and try to look into the near future.

Look back

Machine cryptography, since its inception in the twentieth century, relied on the use of specialized encryption devices - initially mechanical, and then electromechanical encryption machines. General-purpose computing computers appeared much later. An example of such machines is the well-known German encryption machine Enigma, the decryption of which by cryptanalysts from Great Britain greatly influenced the outcome of the World War II.

With the development of information theory, started by Claude Shannon in 1948, and the advent of general-purpose computing machines, the development of cryptography has reached a new level. At that time and until the end of the 20th century, two main goals were set for applied encryption:

· The cipher must have sufficient resilience so that an attacker, possessing significant computing resources, could not decrypt the message without knowing the secret key within a reasonable time;

· One key should be able to encrypt as much data as possible.

It should be noted that the tasks set at the end of the 20th century were generally solved. However, new challenges arose related to the advent of the Internet of Things and the threat of quantum computers.

Challenges and Requirements

The Internet of Things (IoT) is an industry based on data exchange, and the protection of this data is integral. The security of Low Power Wide Area Network (LPWAN) class devices, which have limited computational capabilities and work with small data packets, is especially important. The requirements for cryptography for such devices are as follows:

· Working with small data packets. Devices send small data packets via a radio channel with infrequent communication sessions. The cryptographic algorithm must be able to encrypt and decrypt these small data packets effectively. It is preferable to use algorithms with variable block lengths to adapt to different data packet sizes.

· Minimal overhead on traffic. Bandwidth and data transmission costs are limited. The cryptographic algorithm should minimize traffic overhead, not significantly increasing the size of data packets. This will help reduce data transmission costs and extend the device's lifespan.

· Computational efficiency. Devices have limited computational resources. Therefore, the cryptographic algorithm must be computationally simple to work on low-power chips. Such an algorithm will allow devices to efficiently perform encryption and decryption operations without significantly increasing the load on their processors.

· No permanent communication channel. Devices communicate through infrequent communication sessions, usually once an hour or once a day. The cryptographic algorithm should be designed to work without the need to maintain a constantly active connection. This will allow devices to save energy and extend battery life.

As IoT develops and the number of devices connected to the network increases, new challenges for cryptography emerge. One such challenge is the threat of quantum computing, which could compromise the resilience of existing cryptographic algorithms. Consequently, cryptography for IoT should take into account the potential emergence of quantum computing and provide data protection resilient to such threats.

Developing cryptography for the Internet of Things, especially for LPWAN class devices, presents a complex task. It requires considering specific requirements such as working with small data packets, minimizing traffic overhead, computational efficiency, and operation without a constantly active communication channel. Additionally, cryptographic solutions must be ready for new challenges, such as threats from quantum computing, and ensure data security in the rapidly developing and spreading IoT landscape.

Quantum Computing-Based Attack

Quantum computers pose a threat to existing cryptographic systems. Currently, ciphers can be divided into two categories: symmetric and asymmetric. To understand the threat that quantum computers present, it is necessary to consider their impact on each of these categories.

In symmetric ciphers, all parties use the same key for encrypting and decrypting messages. However, the problem of secure distribution of this key among participants arises. This can be solved physically, for example, using special couriers, or automatically using key generation distribution algorithms, including quantum key distribution.

In the case of asymmetric ciphers, each party has two keys: a secret and a public one. The secret key is known only to the user, and the public key is available to everyone. The public key of the recipient is used for encryption, and decryption is done using his secret key. The sender can also apply his secret key to create a digital signature, which guarantees the authorship and integrity of the message.

Now we have refreshed in memory what distinguishes symmetric and asymmetric ciphers. It turns out that almost all modern asymmetric ciphers and the cryptographic algorithms that underpin them are vulnerable to a quantum computer, often referring to Shor's algorithm. However, it is also necessary to clarify what kind of quantum computer is needed - because quantum computers exist, while asymmetric ciphers are successfully used (for example, RSA).

However, as already mentioned, symmetric cryptographic schemes require key distribution among participants: this can be either distributed key generation (QKD, Diffie-Hellman), or their physical delivery (couriers). Obviously, courier delivery is a "technology" of the last century. QKD is expensive and has physical distance limitations. Diffie-Hellman is not quantum-resistant and requires replacement. To solve the problem of quantum cracking, NIST in 2016 launched a program to develop quantum-resistant (or post-quantum) algorithms and in 2022 selected candidatesfor the federal standard from them. The algorithms turned out to be quite resource-intensive for execution, and therefore, they are not always suitable for IoT applications. However, within the scope of another NIST competition focusing on lightweight cryptography, algorithmstailored for IoT were presented. Nevertheless, none of these algorithms possess quantum resistance.

From the above, it is clear that symmetric algorithms are the best candidates for the Internet of Things in the post-quantum era, with key distribution being the main hurdle. Modern asymmetric ciphers and cryptographic algorithms used in them are vulnerable to the threat of quantum computers, particularly Shor's algorithm. However, it's important to note that the requirement of a quantum computer to break asymmetric ciphers depends on their specific implementation. For example, asymmetric ciphers such as RSA are still secure, despite the existence of quantum computers. On the other hand, symmetric ciphers turn out to be more resistant to quantum attacks. For instance, the well-known Grover's quantum algorithm provides a quadratic speedup when guessing a key in the AES cipher, but this can be compensated for by increasing the key length.

Quantum-resistant algorithms and protocols offer new methods of encryption and key distribution that are resistant to quantum computer attacks. They are based on mathematical principles that cannot be easily resolved by quantum computations. However, transitioning to quantum-resistant algorithms is not a straightforward process. It requires upgrading and replacing existing systems and infrastructure, which may demand significant effort and resources. Furthermore, the implementation of quantum-resistant algorithms needs to be agreed upon and coordinated at an international level to ensure compatibility and secure communication.

Quantum supremacy threatens the security of modern encryption algorithms. In fact, quantum computers of the necessary capacity will soon be able to decrypt any communication protected by asymmetric cryptographic algorithms. Unfortunately, a fully quantum-resistant solution is not yet available, and the existing quantum key distribution schemes are not suitable for large-scale implementation. This article proposes a simple and affordable approach to the problem based on a one-time symmetric key.

Development Road

If we fix the level of resistance for cryptanalysis, which is usually determined by business requirements, there is a relationship between the frequency of key change and the complexity of the cipher: the more often the key is changed, the simpler the cipher can be. A simpler cipher means less demanding on computational resources. The extreme point on this scale is Vernam cipher, where XOR is used as a function for data transformation on the key, i.e., a simple bitwise addition of the message and the key. This cipher consumes keys in the amount equal to the volume of the message; the volume of the message itself does not change. It is proven that Vernam cipher has absolute cryptographic strength, i.e., it cannot be hacked by any means if two conditions are met: each key is truly random and used only once. By the way, this cipher has a rich history - it was used by spies in the pre-computer era. For this purpose, the spy received a set of keys (one-time pad) in the form of a cipher notebook.

Vernam cipher may seem ideal, but its main drawback - a huge key consumption - makes it unacceptable for everyday use: for example, 1 hour of video conference consumes from 0.5 to 7.2 GB of traffic depending on the resolution. This would mean that all parties must have the same volume of keys, delivered in a secure way. However, this method is used in some diplomatic communication channels, where convenience and cost issues give way to confidentiality requirements.

Examples and Estimates

Let's evaluate how realistic the application of Vernam cipher in real scenarios is.

Scenario 1. Temperature and humidity sensor. Suppose we need to transmit sensor readings of temperature and humidity from an agricultural field. Let it measure temperature from 0 to +50°C with a step of 0.5°C and humidity from 0 to 99% with a step of 1%. In total, 100 values or 7 bits each. Let's reserve 1 byte for redundancy (for example, parity check), we get 2 bytes of useful data for one measurement. Suppose measurements are made every hour for 10 years: 2B x 24h x 365d x 10 years = 175,200 B, i.e., <200kB for the entire service life of the device. We remember that for the application of this cipher we need the same volume of keys.

Scenario 2. Water meter. Measurement of water consumption from 0 to 10,000 m³ with an accuracy of 1% - 1,000,000 values, 20 bits + redundancy = 3B. Daily measurements for 16 years: 3B x 365d x 16 years = 17,520 B, an order of magnitude less than the previous case.

We deliberately do not consider scenarios of such connected devices as smartphones, electricity meters, surveillance cameras, or cars. These are devices with significant energy resources and a productive processor, which puts them in a different class. The only limitation that humanity may face with the growth of such devices is the spectrum deficit, but that's another story.

These are just estimates, which, however, give an understanding of the magnitudes of data and keys. So, it can be seen that Vernam cipher in the world of IoT may have a right to exist, but it requires a solution to the task of safe storage of keys, and on both sides - in the cloud platform and in the device itself.

Implementation Details

Safe key storage is required both on the cloud platform and on the device for the implementation of such an approach.

For a long time, HSM (hardware security module) has been used as an infrastructure element for working with cryptography (keys, encryption operations). They have matured and it is unlikely that anything can be significantly improved here. On endpoint devices, it is a good practice to use a security module (secure element), which in cellular devices is a SIM card (including variants eSIM, iSIM, etc.). In turn, the SIM card is the UICC chip with specific software (applets), which is also used in bank payment cards with a different set of applets. The UICC can be represented not only as a replaceable card but also as a soldered chip (eUICC) or as an IP block for placement on another chip (iUICC).

The widespread use, proven safety, and cheapness of the UICC chip make it candidate No. 1 for the role of a security module in Internet of Things devices. This is also supported by the GSMA IoT SAFE concept (IoT SIM Applet For Secure End-2-End Communication), which puts the SIM card in the role of the root of trust in devices. At the same time, the key material can be stored not only on the UICC itself, but also on an external storage in a crypto-container, to which only the security module will have access. If it is necessary to update the key material, a mature Key Wrap technology can be used, which has long been used for key synchronization in HSM.

Thus, all components of this approach are already on the market, tested in the industry, produced in large quantities, so they have an extremely low price. It is also important that the technologies used are familiar to modern engineers, and they can immediately start developing solutions based on them.

So, this approach with the use of one-time symmetric keys paves the way for simple lightweight cryptography for the Internet of Things - with a small overhead, ready for execution even on a SIM card and completely indifferent to the appearance of a powerful quantum computer.

Today, the concept of "Economy of Things" (EoT) is gaining momentum. Advocates of this concept predict a massive shift of connected devices towards this mode of interaction and, consequently, a colossal market.

Let's explore what the new wonderful world holds for us, both from the user's perspective (use cases) and from the developer's perspective (technological stack). Device Twins may have a special place in this concept.

The Core Concept

The idea behind the concept is as simple as it is bold: to empower things (devices, objects) with the freedom to make decisions to achieve economic goals. In other words, to grant things the authority and means to act on their own discretion (within certain constraints, of course).

Such an approach is a specific case of multi-agent systems, the theory of which has been developed since the end of the last century. Now, the technological readiness has come for the practical implementation of this concept.

The agents must meet the following criteria:

Autonomy: Agents are independent, at least partially.

Limited Representation: No agent has knowledge about the entire system, or the system is too complex for any agent to have practical knowledge about it.

Decentralization: There are no agents controlling the entire system.

Let's take a look at how a mundane action like turning on the lights in a hallway using a remote control will change. In the traditional "analog" scenario, you press the button on the remote control, it emits a radio packet that transmits the command to the relay of the lamp to turn it on.

Now, let's consider how it will work in the EoT concept. Suppose there can be more than one lamp at each location in the hallway. Each lamp is represented on a cloud platform (either shared or separate) by its twin (Device Twin - details below). The remote control also has a similar twin. The remote control has pre-established contracts with the lamps. When you press the button on the remote control, it sends a command to its twin about illuminating the hallway. The twin checks the conditions based on the established contracts and selects the best course of action (criteria for selection can be diverse). Additionally, the remote control has the freedom to enter into and terminate contracts with the lamps.

The market

In February 2022, Vodafone announced the launch of the Digital Asset Broker (DAB) platform in partnership with Mastercard and Energy Web. In May 2023, they released a joint report with STL Partners' titled "The Economy of Things: Unlocking the true value of IoT data."

The report provides a forecast of the market for this technology, broken down by different use case scenarios. The forecast is given in terms of the number of devices, not monetary values, but the projected annual growth of 68% is likely to excite many enthusiasts.

In 2015, IBM presented its vision of the Economy of Things, and Bosch has also expressed its interest and involvement in this direction. It is evident that we can expect news of alliances being formed in the near future to further develop and promote the EoT concept.

Scenarios of Use

Shared Economy

All scenarios involving shared usage or short-term rentals fit perfectly into EoT paradigm. Let's take car-sharing as an example. Users will no longer need to be concerned about which specific service owns the car. The mobile application will connect the user to their digital twin on the platform, and it will find the desired car. By making cars active agents on the platform, they can promote themselves in various ways. For instance, a group of cars parked in a remote location can collaborate to provide location-targeted advertisements and increase demand. Simultaneously, a car can function as an advertising medium and sell advertising space.

Energy Management

Currently, any energy system is a complex organism, comprising numerous electricity consumers, producers (including microgeneration), and transmission networks. Implementing the Smart grid approach based on EoT principles adds flexibility and removes barriers for integrating new participants, helping to balance the energy grid effectively.

Logistics

Cargo transportation is also a challenging task today. In the EoT concept, individual units of cargo, such as containers, can act as autonomous agents, aiming to be delivered from point A to point B with minimal costs and within a limited timeframe. In the case of multimodal transportation, a container can establish contracts with all participants in the supply chain and monitor compliance with conditions.

Smart Homes

A smart home can independently enter into and pay contracts for utility services while generating income from microgeneration of electricity and other opportunities, such as advertising placements or parking.

Connected Cars

As independent agents, connected cars can enter into contracts for their maintenance, charging or refueling, as well as offer themselves for rental. This became the first use case for Vodafone's DAB - enabling payment for electric vehicle charging without human intervention.

The list of scenarios mentioned above is far from exhaustive, but it illustrates the new qualities of EoT concept. Devices, based on priorities and constraints set by their owners, autonomously seek to achieve their goals. In such a system, devices act as proactive economic agents, interacting with each other and making decisions to optimize their operations and outcomes.

Technology: what's under the hood

EoT relies on two essential environments: the environment for agent operations and the environment for their interactions, including contract formation.

Environment for Agent Operations

Agents in the EoT are software or hardware entities closely tied to their respective devices. In some cases, such as smart homes or smart cars, the devices themselves may contain all the necessary resources (e.g., electrical power, computational capacity, constant connectivity) to support agent operations. However, for devices utilizing LPWAN (Low Power Wide Area Network), where resources are limited and battery life is critical, Device Twins come to the rescue. Device Twins serve as digital replicas of the physical devices and allow agents to execute either entirely on the device or partially on the device and partially on the platform.

Authentication of devices and execution of sensitive operations, like cryptographic functions, are crucial in such a setup. These sensitive operations are often performed within a Trusted Execution Environment (TEE). A secure element, typically utilized within the device, helps create such an environment. Vodafone DAB, for instance, utilizes the SIM card, enhancing its functionality through software to serve as a secure element. This aligns with the GSMA IoT SAFE strategy, which uses SIM cards not only for mobile network registration but also for other security tasks.

Environment for Interactions

The environment for interactions between economic agents allows them to become aware of each other's existence and needs, as well as facilitates contract formation (acting as a marketplace). Even if agents do not trust each other, they must trust the environment (similar to two individuals trusting a notary during a contract agreement). The source of this trust can be either the environment owner or certain properties of the environment.

Blockchain technology (along with Distributed Ledger Technology - DLT) is one of the most suitable technologies for such environments. In blockchain-based systems, the source of trust depends on the type of blockchain - private (trust originates from the owner) or public (trust comes from the algorithm).

Certain types of blockchains enable the execution of specific applications, such as smart contracts. Once executed, smart contracts are immutable until they are fulfilled or the environment ceases to exist. The concept of smart contracts first appeared in the Ethereum blockchain.

Vodafone DAB has chosen a similar path and developed its own blockchain, proudly referred to as "the blockchain of blockchains." Until the technology details are fully disclosed, it is open to speculation. It could potentially be a platform that not only enables the implementation of smart contracts but also facilitates communication between smart contracts across different blockchains (similar to how it is done in Hyperledger Fabric). For example, a car could have contracts with a service center for maintenance and repair and an insurance company for comprehensive coverage (KASKO). In the event of an accident, these contracts would need to interact with each other.

The role of Device Twins

The role of Device Twins in the Economy of Things is critical, especially when dealing with low-power devices. In such scenarios where device resources are limited, Device Twins become a crucial component to ensure the functioning and decision-making capabilities of agents. Let's look at the roles of Device Twins in this context:

1. Decentralization: Device Twins enable distributed execution of agents between devices and the cloud platform. This allows agents to be lightweight and flexible as some computations and decision-making can be offloaded to more powerful cloud servers while some tasks can be performed on the device itself.
2. Security: Device Twins provide secure isolation of agents from each other and other system components. Data protection and access control become critical in the context of the Economy of Things, and Device Twins play an essential role in ensuring security.
3. Mobility: Device Twins must be able to follow their devices across a distributed infrastructure, including edge computing. This ensures continuous communication and interaction between agents and the platform, even if devices move or operate in remote locations.
4. Accessibility: Device Twins must always be accessible from both the platform's side and the device's side. This ensures constant interaction and data exchange between agents and the platform.
5. Cloud Native: Device Twins align well with Cloud Native principles used in modern IoT cloud platforms. The Cloud Native approach allows for building scalable, flexible, and reliable systems, which is particularly important when dealing with a massive number of devices and agents.

Device Twins play a significant role in the Economy of Things, ensuring the functioning and interactions of agents on devices with limited resources. IoT 5G operators represent the most suitable environment for implementing such solutions as they already possess the infrastructure and experience of working with a large number of devices and agents in the network, and the Cloud Native approach aligns with the requirements of EoT.

Conclusion

The Economy of Things (EoT) holds tremendous market prospects, given its well-developed concept of multi-agent systems and the complete technological readiness for its implementation. This can lead to entirely new economic forms and elevate process optimization to a new level.

Security concerns are highly sensitive in such solutions, which is why all significant transactions must be securely (=cryptographically) confirmed, for which blockchain and distributed ledgers (DLT) are applied, and secrets are stored in secure elements.

Low-power devices already represent the most massive segment of the IoT, and this trend will continue to strengthen. Such devices cannot handle the entire load independently, and a significant part of it, in the form of Device Twins, needs to be delegated to the cloud. The optimal place for hosting the environment for their execution is within the infrastructure of LPWAN operators, particularly 5G.

With the advancement of next-generation networks and the growth of cloud computing, Network Function Virtualization (NFV) and Edge Computing have become integral components of modern infrastructure. However, as the significance of these technologies increases, new security challenges emerge. To ensure data confidentiality and integrity in such environments, AMD has developed the AMD Secure Encrypted Virtualization (SEV) technology, which effectively enhances the security of NFV, Edge Computing (including Multi-Access Edge Computing or MEC), built on a microservices architecture.

AMD SEV

AMD SEV is an advanced technology developed by AMD to enhance the security of virtualized environments. It provides a robust level of protection for virtual machines and containers by encrypting their memory and isolating them from each other and the host system. Each VM or container is assigned a unique encryption key, ensuring the security and confidentiality of data, even in shared computing environments. Learn more

Microservices Architecture

Microservices architecture is an approach where applications are broken down into small, independent, and interacting services. Also known as Cloud Native, this architecture offers flexibility and scalability in application development and deployment.

AMD SEV for Microservices Architecture:

• Security in Use: AMD SEV ensures isolation and security between individual microservices, even in the event of physical access to the server. Data encryption and access management mechanisms prevent unauthorized access and protect against attacks on integrity and confidentiality.
• Security in Motion: Microservices can move across infrastructures, between different servers and data centers. With memory encryption, the container housing the microservice (or one of its replicas) remains encrypted, similar to securely transporting goods in a sealed container.
• Security at Rest: Instant container snapshots are commonly used to save states and enable rollbacks. With memory encryption, the container snapshots are also encrypted using the same key, ensuring data security.

Network Function Virtualization

Network Function Virtualization involves separating the software used in network functions from the physical infrastructure, providing flexibility and scalability in deploying network services. However, the dynamic nature of NFV introduces vulnerabilities that require effective security measures. As network functions typically exist as virtual machines or containers, the same considerations for microservices apply to NFV.

AMD SEV for NFV Security:

• Isolation between microservices: AMD SEV ensures isolation and encryption between virtual machines in the NFV environment, preventing unauthorized access and data interception between different network functions.
• Protection of data at rest and in transit: SEV provides encryption of data in the memory of virtual machines, safeguarding against information leaks during storage and transmission over the network.

Edge Computing

Edge Computing is an architecture that enables data processing closer to the source or endpoints. Multi-Access Edge Computing (MEC) is the approach that places computing resources and services closer to users at network base stations. The deployment of containers with network functions on edge devices enables MEC capabilities.

AMD SEV for Edge Computing and MEC Security:

• Security in edge deployment: AMD SEV ensures security when deploying computations at the edge, protecting data from physical attacks and malicious software that may occur in unreliable edge environments, as edge devices may not be owned by the cloud or network provider.
• Protection between services in MEC: SEV guarantees protection between different services in Multi-Access Edge Computing, preventing unauthorized access and ensuring data confidentiality during transmission and processing at the network edge, especially in scenarios where the edge device executes microservices belonging to different owners.

Conclusion

AMD SEV is a reliable technology for enhancing the security of Network Function Virtualization (NFV), Edge Computing (including MEC) based on a microservices architecture. Implementing AMD SEV in these domains ensures protection against security threats such as unauthorized access, attacks on inter-domain communication, and data leakage. Data encryption at all stages of the microservice lifecycle allows for trusted computations on untrusted hardware and transmission over untrusted communication channels, while leveraging the flexibility of Cloud Native architectures.

At first glance, what could possibly be common between such disparate things: levers, bearings, hubs, and a virtual entity in the cloud? Let's investigate.

The car wheel is the main element connecting it to the physical reality around it (we will exclude accidents and traffic police from our consideration). Likewise, Internet of Things (IoT) devices connect the digital realm to the physical world, which is why such systems are sometimes called cyber-physical. Just as a cantilever of an atomic force microscope scans the nanoworld, a car wheel scans the road landscape. What does the suspension do in this case? It helps the wheel do its job as effectively as possible.

The automotive industry is continually striving to reduce the unsprung weight: everything that oscillates with the wheel should be as light as possible. That way, it's easier for the wheel to cope with roughness, the engine/brake to accelerate/decelerate, and the steering mechanism to change direction. The weight of what's attached to the body is not so important. All of this is the suspension, which connects the wheel to the rest of the car.

This is analogous to the pursuit in the IoT realm, and especially in LPWAN, to "lighten" the device, transferring much of the data processing and management to the platform or server. This is done to conserve the device's resources, increase its energy efficiency, and extend its battery life. This is where Device Twins come into play (more about this approach here, here and here).

Now let's look at this issue from another angle: how Device Twins can be used in suspension. If multiple vibration sensors are installed on the wheel and suspension elements, a wealth of data can be gathered. A suspension Device Twin could monitor parameters like shock absorber wear, the condition of springs, stabilizers, bearings, and other suspension elements. The incoming signals must be processed to identify dangerous vibrations. All of this can be done by a suspension Device Twin working on the car's onboard computer. This information can then be used for predictive maintenance, forecasting, and preventing potential issues. These data can further be integrated into the car's Digital Twin for a more comprehensive and accurate view of its current state and maintenance needs.

A frequently asked question is "Why do we need these Device Twins, isn't it just creating more entities?". Now there's an answer: "Do you have suspension on your car? Why do you need it? You should rigidly attach the wheels to the body, as there's always something breaking in the suspension."

In recent years, in the context of the Internet of Things (IoT), the terms Digital Twins and Device Twins are increasingly encountered, which describe the creation of virtual models of physical objects or processes, but they have different areas of application. Due to their superficial similarity, confusion often arises. Let's try to understand what these concepts are in the IoT industry.

Digital Twins

A digital twin is a comprehensive virtual model of a physical object, process, system, or service. This can include buildings, machines, production lines, logistics systems, and more.

The goal is to simulate and analyze the behavior of the object in a virtual environment, allowing for the optimization of production processes, prediction of malfunctions, improvement of products and services, and much more.

Digital twins are often used in industries such as manufacturing, automotive, construction, healthcare, and others.

Use cases

Industrial Manufacturing: In production facilities, digital twins can be used to model and optimize the entire manufacturing process. They collect data from various machines and equipment on the production line, allowing for the identification of bottlenecks, prediction of malfunctions, and optimization of efficiency.

Smart Cities: Digital twins can be used to model a city's infrastructure, including road networks, water supply systems, and power supply. This helps city planners make more informed decisions and optimize urban services.

Healthcare: In medicine, digital twins of patients can be created using their medical data, allowing doctors to better understand their health status, simulate the impact of medications, and develop personalized treatment plans.

Device Twins

Device Twins are often a specialized subset of the Digital Twins concept that is focused on IoT devices.

This term usually refers to a virtual model of a specific IoT device that is synchronized with the real device. This allows for monitoring the current state of the device, its configurations, and other metadata.

Device Twins are used for the management, monitoring, and diagnostics of IoT devices remotely. It’s worth noting that the application of Device Twins with LPWAN (Low Power Wide Area Network) devices is particularly valuable. LPWAN technologies, such as LoRaWAN or NB-IoT, allow devices to operate over long distances with very low power consumption. Using Device Twins in conjunction with LPWAN devices enables the optimization of data transmission, thereby saving radio spectrum and extending the battery life of devices.

Device Twins store the current state of the device and can synchronize changes only when necessary, instead of constantly transmitting data. This means that LPWAN devices can transmit data less frequently, which reduces their power consumption and load on radio frequencies, without losing the quality of the data received. This approach increases the efficiency of network resource utilization and can be critically important for agriculture scenarios where devices may be scattered over a large area and have limited power capabilities.

Use cases

Smart Home: In smart home systems, each device, such as a thermostat, lighting, or security sensor, may have its own Device Twin. This allows users to control and monitor the state of devices remotely through a mobile application.

Agriculture: In modern agriculture, IoT devices such as humidity sensors and automatic irrigation systems can have Device Twins. This allows farmers to monitor and optimize the growing conditions of plants by controlling devices in the field remotely.

Industrial Robots: Robots used on production lines can have their Device Twins, allowing operators to monitor the state and performance of robots, as well as update their configuration remotely.

Differences

Digital Twins have a broader scope of application and can involve modeling entire systems or processes, whereas Device Twins are more specific and focus on individual IoT devices.

Device Twins are most often used for managing and monitoring devices, whereas Digital Twins are frequently employed for optimizing and analyzing production processes and systems.

Common Ground

Both concepts involve creating virtual models of physical objects.

They are used for simulation, monitoring, analysis, and management of real objects or processes.

Both Digital Twins and Device Twins typically utilize data from IoT devices.

Standards

Standardization is important for technology compatibility, the ability to transfer objects from one environment to another, reuse, etc.

In Digital Twins, the most widespread organization is the Digital Twin Consortium. It develops and promotes the Digital Twins ideas, and unites the efforts of other organizations involved in this field: oneM2M, ETSI, 3GPP, etc. More about Digital Twins standards can be found in this book.

With Device Twins, the situation is different as of now: they are used by major IoT providers - AWS and MS Azure, but in a proprietary, albeit very similar form.

Examples of Combined Use

Modern Data Center

The data center is an object that is easily understood by people in the IT field. It is digitized and automated, so let’s take it as an example to explore the joint operation of Digital Twins and Device Twins. For a data center, the use of Digital Twins and Device Twins can be especially useful for monitoring, managing, and optimizing the operation of equipment and infrastructure. Here is how this can work in practice:

Step 1: Creating Device Twins

For each physical device in the data center, such as servers, storage, network switches, and air conditioning systems, a Device Twin is created.

For example, for a server, the Device Twin can monitor current CPU load, memory usage, temperature, fan status, and other information.

For an air conditioning system, the Device Twin can monitor temperature, humidity, and cooling efficiency.

Step 2: Aggregating Data from Device Twins

Data is collected from all Device Twins in the data center and sent to a central management system.

Step 3: Creating a Data Center Digital Twin

Using data from all Device Twins, a Digital Twin of the entire data center is created. This Digital Twin models all aspects of data center operations, including:

• Resource allocation among servers
• Optimization of energy consumption
• Modeling airflow for cooling optimization
• Predicting the need for equipment maintenance

Step 4: Analysis and Optimization

Using the Digital Twin, data center operators can analyze the operation of infrastructure in real-time and conduct simulations for optimizing performance and efficiency.

For example, if the Digital Twin shows that a certain area of the data center is overheating, operators can decide to redistribute the load or adjust the cooling systems for that area.

Step 5: Implementing Changes

Based on analysis and optimization using the Digital Twin, the real equipment in the data center can be configured or adjusted accordingly to improve performance and efficiency.

Using Device Twins and Digital Twin in conjunction allows not only monitoring the status of individual devices in the data center but also analyzing and optimizing the operation of the entire data center as a unified system.

Connected Car

Each device inside a modern car (for example, the engine, transmission, sensors, control systems) can have its own Device Twin, which tracks the state and parameters of that particular device. However, when we connect all these Device Twins together and model how they interact with each other within the whole car, we are essentially creating a Digital Twin of the car.

In this case, the Digital Twin of the car can be used not only for monitoring and managing the state of individual components but also for simulating and analyzing the behavior of the entire car under various conditions. This can be useful for optimizing performance, increasing fuel efficiency, predicting maintenance needs, and much more.

At the same time, everything depends on the goals. If a Digital Twin of a car is needed for crash test modeling, data from Device Twins alone will not be sufficient - physical properties of the body frame, glass, airbags, etc., are needed.

For example:

1. Performance Optimization: By creating a Digital Twin of the car, manufacturers can run simulations under various driving conditions and analyze how different components perform. This data can be used to make tweaks and adjustments to the car’s design for optimal performance.
2. Predictive Maintenance: The Digital Twin can predict when parts of the car will need service. By analyzing data from the Device Twins (such as engine performance, tire wear, etc.), the Digital Twin can provide advanced warnings to the driver or fleet manager to schedule maintenance before a component fails.
3. Safety Enhancements: By simulating crash tests using the Digital Twin, manufacturers can understand how different materials and designs impact the car's safety. This information can be used to make design changes that improve the car's safety features.
4. Customization and Personalization: The Digital Twin can also help in customizing the car for individual users. By analyzing driving patterns and preferences, the system can make adjustments to various settings (seat position, climate control, etc.) based on the preferences of the individual driver.
5. Real-time Monitoring and Diagnostics: The Digital Twin, coupled with the data from the Device Twins, can provide real-time monitoring and diagnostics of the car’s systems. This can be particularly useful for fleet management, where real-time information about the vehicle's health can be crucial for operations.
6. Energy Efficiency: For electric cars, managing battery life and energy efficiency is crucial. The Digital Twin can simulate different driving conditions and energy consumption patterns to optimize battery life and driving range.

The combined use of Device Twins and a Digital Twin in connected cars allows for a more comprehensive understanding and management of the vehicle's performance, maintenance, safety, and user experience.

Agriculture

In agriculture, Device Twins and Digital Twin technologies can be used together to optimize yields, manage resources, and increase the efficiency of farming operations. Here's an example:

Imagine a farm that employs various IoT devices such as soil moisture sensors, temperature sensors, automatic irrigation systems, and drones for monitoring the condition of fields.

Step 1: Creating Device Twins

For each IoT device on the farm, a Device Twin is created. For instance, a soil moisture sensor has its Device Twin that keeps track of current soil moisture readings. The automatic irrigation system also has its Device Twin which allows for control and monitoring of its operations.

Step 2: Aggregating Data from Device Twins

Data collected from Device Twins is directed to a centralized management system, where it can be analyzed and used for decision-making.

Step 3: Creating a Digital Twin of the Farm

Using data from all Device Twins, a Digital Twin of the entire farm is created. The Digital Twin is a virtual model of the farm that encompasses all fields, devices, weather conditions, and other factors that might affect the yield.

Step 4: Analysis and Optimization

Using the Digital Twin of the farm, farmers can run simulations and analyze how various factors such as weather, soil moisture, and irrigation levels affect the crops. This enables the optimization of resource use, predicting potential issues, and making informed decisions.

For example, if the Digital Twin shows that the moisture level in a particular field is too low, the farmer can use the Device Twin of the irrigation system to automatically increase the irrigation in that area.

Step 5: Implementing Changes

Based on the analysis and optimization conducted using the Digital Twin, the actual devices on the farm can be configured or adjusted accordingly to improve yield and the efficiency of resource usage.

The combined use of Device Twins and Digital Twin allows not only to monitor and control individual devices on the farm but also to analyze and optimize the operation of the entire farm as a single system. This can lead to cost reductions, increased yields, and enhanced overall efficiency of agricultural operations.

Conclusion

Device Twins and Digital Twins can complement each other. Having Device Twins in the system significantly eases and supports the process of creating Digital Twins, especially in complex systems where multiple devices interact with each other. Device Twins provide detailed information about the status, configuration, and behavior of individual devices. This data can be integrated into a Digital Twin for modeling larger systems or processes.

Thus, Device Twins serve as an important building block for creating Digital Twins by providing the necessary data and interconnections at the device level, which can be scaled up to the system or process level.

Convergence of 5G and IoT Platforms

As mobile communication and Internet of Things (IoT) technologies continue to evolve, the potential of their combined use becomes increasingly apparent. 5G offers excellent speed, low latency, and high reliability, making it ideal for connecting IoT devices. IoT, on the other hand, encompasses billions of connected devices that can transmit data in real-time, on a schedule, or on-demand, which are essential for improving efficiency, automation, and personalization of services.

In addition to the obvious complementarity between 5G and IoT, there is a common architectural approach in the development of platforms for these technologies - Cloud Native. This creates conditions for deeper integration between them. It seems attractive to make some functions of the IoT platform standard functions of the 5G architecture.

Cloud Native and Its Role in Modern Networks

Cloud Native is an approach to application development and operations that leverages the advantages of cloud computing. This includes the use of containers, microservices, and continuous integration/continuous deployment (CI/CD) for rapid scaling and high resilience of applications. In the context of 5G and IoT, Cloud Native plays a key role in providing the flexibility, scalability, and efficiency required to handle the massive volume of data generated by IoT devices and to support the high-quality communication demands in 5G networks. This has already led to an interesting development: leading cloud providers - AWS, Azure, and Google Cloud offer ready-made infrastructures for launching 5G networks. This is particularly natural for the Open RAN approach to building mobile networks, which is rapidly gaining popularity.

Purpose of the Article

The purpose of this article is to explore the possibility of convergence between 5G and IoT platforms based on Cloud Native. The focus is on integrating Device Twins into the standard 5G architecture and projecting this solution onto Edge Computing. We will examine the advantages and risks of this approach.

5G Technologies

Evolution from 4G to 5G

5G technology represents the fifth generation of mobile networks and is a significant evolution compared to its predecessor, 4G. It is designed for more efficient, faster, and versatile communication compared to 4G, with primary goals of high data transfer speeds, reduced latencies, energy savings, reduced costs, increased system capacity, and enabling massive device connectivity.

Architecture and Key Components of 5G

The 5G architecture includes several key components such as New Radio (NR) access technology, Next Generation Core (NG Core), and Network Slicing technology. These elements are designed to work together to provide versatile and efficient communication across various applications and industries.

Regarding IoT, the following components should be highlighted:

1. Network Exposure Function (NEF). NEF is a component in the 5G architecture that facilitates interaction between external systems and services with the 5G network. NEF provides standardized APIs for access to network functions and data while ensuring security and control over how external applications interact with the network.
2. Network Data Analytics Function (NWDAF). NWDAF is a function in the 5G network architecture that analyzes network data and statistics to support network optimization and provide information to other network functions. This may include analyzing traffic, performance, network congestion, and other aspects.
3. User Plane Function (UPF). UPF relates to the user plane in 5G and is responsible for the processing and routing of user traffic in the network. UPF plays a key role in ensuring high-speed and low-latency data transmission and is a central part of the user plane in the 5G architecture.
4. Application Function (AF). AF in the 5G architecture enables the interaction of network capabilities with external applications. AF can use NEF to access network functions and participate in session management, Quality of Service (QoS), and traffic management to support specific application requirements.

Open RAN

Open RAN (Open Radio Access Network) is a radio access network architecture that allows mobile operators to use network equipment and software from various vendors, instead of being reliant on a single supplier for the entire solution. This approach provides flexibility, cost reduction, and stimulates innovation.

Within the context of 5G, Open RAN enables the deployment of networks with high bandwidth, lower latency, and next-generation network capabilities through a modular and open architecture.

Key vendors:

Altiostar: A company that provides software solutions for RAN virtualization and promotes the development of Open RAN through contributions to the O-RAN Alliance.

Mavenir: As one of the leaders in the Open RAN solutions area, Mavenir is actively involved in developing software solutions for the virtualization and automation of 4G and 5G networks.

Parallel Wireless: This company is engaged in developing solutions for unifying 2G, 3G, 4G, and 5G mobile networks through an open RAN architecture.

Nokia: Although Nokia is known as a traditional telecommunications equipment manufacturer, the company is actively involved in Open RAN, providing solutions and technologies for 5G networks.

Samsung: The company implements Open RAN solutions, combining its innovations in 5G with an open architecture to provide operators with flexible and scalable network solutions.

Rakuten: The company is one of the key players in the Open RAN field. Rakuten Mobile, a subsidiary of the Japanese company Rakuten Group, is the world's first operator to have built its mobile network entirely based on Open RAN.

Open RAN continues to gain popularity as a means of enabling more flexible, reliable, and efficient deployment of 5G networks. Key vendors and standards, such as the O-RAN Alliance, play an important role in promoting this architecture.

IoT Technologies

The Internet of Things refers to a network of physical devices equipped with sensors, software, and other technologies that allow them to connect and exchange data through the Internet. This enables the creation of smart environments and systems, ranging from small household appliances to large industrial machines.

Architecture and Key Components

The IoT architecture typically includes four layers: the sensor layer, network layer, management layer, and application layer. The architecture can vary depending on the specific use case and requirements. Key components include sensors, actuators, communication means, data processing, and user interface.

As IoT platforms deal with a large number of devices and need to ensure flexibility and resilience, almost all of them are Cloud Native.

Use Cases and Applications

IoT technology has a wide range of applications in various industries such as agriculture, healthcare, retail, transportation, and many more. It provides solutions such as smart homes, industrial automation, wearable devices, smart agriculture, and health monitoring systems.

Interaction between 5G and IoT

The combination of 5G and IoT technologies can create a synergistic effect. Currently, IoT platforms exist separately from 5G and use it as transport. The migration of some IoT functions into the 5G architecture and subsequent promises looks promising: this convergence has the potential to radically transform industries by providing more efficient and complex IoT applications and services.

More About Cloud Native

Cloud Native is an approach to application development and deployment that utilizes cloud technologies to ensure scalability, flexibility, and rapid time-to-market. Applications built using the Cloud Native approach are typically structured as a set of small, independent, and distributed services, known as microservices.

Microservices

Microservices are a key component of Cloud Native architecture. They involve breaking down an application into multiple small and independent services, each of which performs a specific function. These services can be deployed, scaled, and managed independently of each other, which increases the flexibility and reliability of the system as a whole.

Containerization and Orchestration

The Cloud Native approach is also closely associated with the use of containers for packaging and isolating applications and their dependencies. Docker is one of the most popular tools for containerization. For managing containers on large-scale deployments, orchestration systems like Kubernetes are used.

Advantages

Cloud Native architecture offers a range of benefits such as improved scalability, increased resilience to failures, reduced time-to-market, and optimized resource utilization. This makes Cloud Native an attractive choice for modern applications, including in IoT and 5G networks.

Device Twins in IoT

Device Twins are digital duplicates of physical IoT devices that provide a virtual representation of the state and metadata associated with physical devices. Device Twins are used to synchronize the state between physical IoT devices and a cloud platform. This allows developers to track changes in device state in real-time, as well as implement complex scenarios such as managing groups of devices, creating automation scripts, and handling events based on state changes.

Components of Device Twins

Device Twins consist of three main components: device state information, metadata, and device properties. Device state information provides information on the current state of the device, metadata can include information such as firmware version or location, and device properties allow for the control of the device’s configuration and settings.

Providers and Platforms

Several major IoT platforms, such as Microsoft Azure IoT Hub, AWS IoT, and Google Cloud IoT, offer Device Twins capabilities as part of their solutions for managing IoT devices.

Learn more about Device Twins here.

Integration of Device Twins into 5G

Choice of 5G Component for Integrating

As mentioned above, four standard components of the 5G architecture can be candidates for implementing Device Twins in them: NEF, NWDAF, UPF, AF. The choice of the most suitable one should be based on several criteria. Firstly, it is distribution - the ability to work on resources in a data center as well as at the network edge. Secondly, it is the ability to terminate NIDD traffic, native to LPWAN networks. And, thirdly, the presence of security features both for isolating Device Twins form each other and from external attacks.

Below is a comparison table:

From the comparison, it is clear that the most suitable candidates are NEF and AF. NEF is more suitable for lightweight and typical Device Twins, while AF is suitable for heavier ones with special demands on computational and network resources. If you remember that LPWAN devices are typically lightweight and that NEF can offer advanced security options, the winner becomes clear.

Integration of NEF and Device Twins

Conceptual Model

The integration of Network Exposure Function (NEF) in 5G networks with Device Twins in IoT platforms opens new opportunities for optimizing and managing communication between IoT devices and 5G network services. In this context, NEF will serve as an execution environment for Device Twins, which are implemented as microservices, with a significant part of NEF functions possibly being executed by the Device Twins.

Microservices

Architecture and NEF In modern trends of 5G network development, NEF can (and should) be implemented using microservices architecture. This allows NEF to be flexible and scalable. Device Twins, in turn, can be embedded in NEF as microservices, allowing them to perform specific NEF functions such as data processing and network resource management.

Distributed Architecture and Mobile Agents

NEF has a distributed architecture, which enhances its ability to scale and handle a large number of devices. Device Twins can act as mobile agents within NEF, moving through the network following their devices. This can be especially beneficial for resource optimization and performance enhancement in mobile scenarios such as autonomous vehicles or mobile robots.

Benefits and Challenges

Using Device Twins as NEF agents can bring several benefits including increased flexibility, resource optimization, and improved quality of service. It also allows for more efficient use of NIDD: this protocol has a customizable packet size. Knowing what the payload will be, NIDD can be set up very precisely and overhead avoided due to a mismatch between them.

However, this approach also presents certain challenges, including security, data management, and coordination between various agents and devices. Regarding security, additional container isolation measures will be needed, for example, such as AMD SEV.

Use Cases and Prospects

While the integration of NEF and Device Twins is a new direction, it offers interesting prospects for future collaboration between IoT and 5G technologies. For example, in smart city scenarios, connected cars, or industrial IoT, where devices often can be mobile, the use of mobile agents can improve the quality of services and optimize resource usage.

Application in Edge Computing

Edge Computing is a concept where computing resources and data processing are placed closer to the location where they are needed, which reduces latency and improves performance. This is especially relevant for IoT, where devices may generate large amounts of data that need to be processed in real-time.

Device Twins as NEF Agents

By distributing NEF up to edge devices, Device Twins, acting as its agents, can be executed there. In the context of Edge Computing, this allows for more efficient use of network resources, reduced latency, and higher throughput. Importantly, it creates a universal approach to working with IoT devices and adds flexibility to the mobile network infrastructure.

Use Case Scenarios and Examples

Using Device Twins as NEF agents in an Edge Computing environment can be particularly useful in scenarios where high performance and low latency are important. Examples of such scenarios include autonomous vehicles, industrial IoT, smart cities, and real-time telemedicine.

Challenges and Opportunities

Although using Device Twins as NEF agents in Edge Computing offers many opportunities, there are also several challenges, such as ensuring security, data management, consistency, and service continuity in mobile scenarios.

The first issue to address is ensuring code portability from the cloud to the edge device - as servers and base stations and routers are typically implemented on hardware of different architectures.

The second issue is how to ensure continuous and equally strong security context for Device Twins during their migration between nodes and when operating on untrusted equipment (e.g., on a user's network router).

Development Prospects

Considering the growth of IoT and the ongoing deployment of 5G networks, the prospects for integrating Device Twins and NEF in an Edge Computing environment look promising. This can become a key factor in the development of intelligent networks, autonomous systems, and other advanced technologies requiring high bandwidth and low latency.

Conclusion

Key Takeaways

In this article, the intersection and interpenetration of 5G and IoT technologies in the context of Cloud Native architecture were discussed. The main focus is the integration of Network Exposure Function with Device Twins, which allows for the creation of a more flexible and scalable environment. Device Twins, acting as agents of NEF, can provide a high degree of mobility and adaptability, which is extremely important in dynamic network scenarios, especially considering the development of Edge Computing. Importantly, this can be done now without altering the standard 5G architecture, allowing operators to launch value-added services based on this, and consumers to lower the barrier for launching IoT projects.

What's Next

The concept presented in the article opens up a promising direction; however, additional research and innovation are needed to realize the full potential of this integration. Security issues, data consistency, integration with existing solutions, and resource optimization require in-depth analysis and development. Industry professionals, researchers, and developers are encouraged to actively participate in this process, contributing to the evolution of network technologies and creating new opportunities for IoT and 5G in the age of Cloud Native and Edge Computing. An optimal solution in future-generation mobile networks would be to implement a component optimized for Device Twins, meeting portability and security requirements.

In today's world, cloud services are integrally involved in many aspects of business and daily life. Along with the convenience and flexibility they provide, there comes an increase in risks in the area of information security. Data breaches, cyberattacks, and privacy violations are problems that cannot be ignored. Security in cloud services is not only a measure for protecting information but also a key element in strengthening trust and loyalty of users.

Now, all cloud platforms that are built on the Cloud Native principle use virtualization and containerization to implement microservice architecture. Therefore, here onwards, we will be talking about the security of virtual machines (VMs), understanding them to encompass full virtualization, paravirtualization, and containers (such as Docker). The ideal scenario for a cloud user would be to achieve the same (or nearly the same) security for their remote virtual machines as they would have when operating locally. How can this be achieved?

The discussion will proceed with technologies that are available now, but whose application still needs to find its niche.

State of the Art

The user can prepare a virtual machine (VM) or the entire architecture on their computers, encrypt it, and transfer it to the cloud for further operation. However, once the container starts working, it uses RAM, where data is processed in plain text and can be copied or altered. A particular risk is presented by "snapshots," which are widely used to capture the state of the container and consist of a copy of the RAM and CPU registers associated with that VM. When restoring (rolling back) the container to this state, the reverse process occurs – data from the file is loaded into RAM and registers.

This was the case until recently when AMD brought to market the SEV (Secure Encrypted Virtualization) technology, which allowed for encrypting data on the fly as it is transferred between the CPU and RAM and vice versa. This enables the creation of a seamless security context for the container – data is never in plain text. Leading vendors and virtualization communities, including VMware, Openstack, Kata (IBM), Qemu, and others, have supported this technology. A strategic partnership was concluded between Google and AMD to build secure trusted cloud services. Services like AWS and Azure are offered based on this technology. The list is more than authoritative.

The downsides of the technology stem from its implementation: a symmetric AES 128 cipher is used, and the encryption key is generated and stored in the CPU (in its special Secure Processor area). Difficulties begin to arise when the VM needs to be moved to another physical server. In VMware terms, these are:

• System Management Mode
• vMotion
• Powered-on snapshots (however, no-memory snapshots are supported)
• Hot add or remove of CPU or memory
• Suspend/resume
• VMware Fault Tolerance
• Clones and instant clones
• Guest Integrity
• UEFI Secure Boot

And these are the functions that we loved virtualization for: flexible automated DevOps, fault tolerance and disaster recovery due to VM migration to other servers and data centers, energy saving by concentrating working VMs on certain servers and turning off the rest, etc. Thus, increased security has led to real, not imaginary, constraints.

Along with the limitations in convenience, it is essential to remember the maximum load on the key – the volume of information encrypted with a single key (a large volume of data encrypted with one key can give an advantage to an attacker in brute-forcing the key). The CPU exchanges very significant volumes of data with RAM. Thus, it is necessary to change the key periodically and quite often. Is it possible to have it all at once?

Key Distribution and Security with Comfort

If the user of the VM – the owner of the data in it – could provide the CPU with the encryption key for the VM's memory, this would remove all the restrictions: when moving the VM to another CPU (server or data center), the user would again provide the necessary key and the VM could continue its work in the new location.

Migration steps:

1. Creation of the VM state on the 1st server and recording it in shared storage (accessible to both servers).
2. Starting the VM on the 2nd server with the state data from shared storage.
3. Synchronization of the states of the two VMs over the network.
4. Handing over control and data flow to the 2nd VM.
5. Stopping the 1st VM.
6. Post-procedures - deleting unnecessary files.

In this case, the VM state is transferred in encrypted form, as it was processed before, which provides a seamless security context without re-encryption and, consequently, the highest level of confidentiality and integrity. A similar process occurs when changing the encryption key, only then everything happens within one server and CPU. It is especially pleasing that now one does not have to worry too much about the security of backups, which for many years occupied “prize” places as a channel for the leakage of sensitive data: the backup will contain the encrypted state of the VM.

Key distribution is a classic task in symmetric encryption schemes (we remember that SEV uses AES - symmetric encryption). In the era of anticipating quantum supremacy, there is an additional requirement for quantum resistance - a property of an algorithm that does not give a significant advantage to a quantum computer over a traditional one. By the method of implementation, quantum-resistant algorithms are divided into quantum (laws and phenomena of physics are used) and post-quantum (mathematical operations are used). The former has a significant advantage - they have proven resistance, which will not change from the appearance of new computers or even scientific discoveries. The technology readiness is very high, and equipment is available on the market. The advantage of the latter is the simplicity of application; it is only necessary to change the key distribution algorithm. However, there is no ready-made product here yet - national standards or industry standards, only recently NIST selected candidates for this role in the US.

Quantum Key Distribution

Let's not delve into the principles of QKD here, for our task it will be sufficient to represent the QKD system as a distributed generator of truly random numbers: a random number is generated at point A and exactly the same number is generated at point B, points A and B are connected by a quantum channel.

Thus, the key can simultaneously be obtained by the user and on the server where the VM is created, and used for encryption. However, a scheme with the following algorithm is more preferable:

1. The server receives a command from the user to create a VM.
2. The CPU generates key (1) and creates a VM, encrypting the allocated RAM with this key.
3. Simultaneously with step 2, the QKD procedure starts, as a result of which the user and the CPU will have identical secret keys (2).
4. The CPU then performs an XOR operation (addition modulo 2) of keys (1) and (2) and sends the result to the user over any open channel.

In this sequence, the VM startup time can be slightly reduced - you do not need to wait for the QKD system to distribute the keys.

Another scenario is possible when the user prepares a VM locally, encrypts it, and then transfers it to the data center, where there is already a corresponding key transferred using QKD. This option seems to be more advantageous in terms of security: the data inside the VM does not appear in the open anywhere, that is, the principle of a seamless security context (end-to-end) is implemented.

In other cases (migration, backup and recovery, etc.), similar sequences will be implemented with their specifics. At the same time, the key registry is only with the user - the owner of the data, and temporarily inside the protected area of the CPU, which is reset when the voltage is turned off or the server is rebooted. Therefore, for each operation, the key will be requested from the user, and the operation becomes possible only after it is provided.

This solution also has its weaknesses:

1. QKD uses the laws of physics and has physical limitations - about 100 km is the length of the quantum channel. There were statements about 1000 km, but commercial implementations are not available to date. It is expected that for a long time, the consumers of such secure services will be corporations that usually have their own service premises near data centers for physical access and maintenance of their equipment. So this will not be a significant limitation for them.
2. QKD is expensive. Until recently, this was indeed the case with a price of around €100k per set. However, in our scenario, a system is needed that operates at short distances, which reduces the requirements for the level of equipment and, accordingly, the price. In addition to this, technologies are developing and IP circulation is increasing, which also leads to a price reduction. Therefore, in the very near future, a price of around €2-3k per server can be expected.
3. The not-so-robust AES 128 cipher is used. This creates risks of key selection. As of today, this risk can be mitigated by changing keys more frequently; in the future, it is expected that AMD and other chipmakers will switch to more robust ciphers.

Despite the identified weaknesses of this solution, it is still a much higher level of security for virtual infrastructure with a high market readiness of the necessary components.

Assessment of Trends

Here it is important to clarify two questions: how far ahead of their time are the technologies described above, and where are they necessary.

During the preparation of the article, the authors' opinions ranged from “implement everywhere” to “why force it”.

As of today, SEV is a fairly niche technology and is unlikely to be needed by everyone. It has narrow areas of application, but clouds have been living without it for a long time and quite successfully. Implementing SEV everywhere would require reworking not only the functionality but also the properties offered by clouds, inventing a lot of “workarounds”, which would make everything complex and poorly maintainable. For example, machine migration, recovery from backups/snapshots (especially if the host machine has "bitten the dust"), hot redundancy, replication - all of this will be to varying degrees limited or impossible without going beyond the SEV concept. Not to mention the trivial vendor lock-in, as the technology is only available on AMD EPYC processors.

It is important to note that SEV technology will provide a different perspective on Edge computing and various “thick” embedded solutions (cars, for example). For operating hardware in an untrusted environment, this is a suitable technology. Unfortunately, the technology is not very ready for such applications, as it was initially positioned for server solutions and data centers. We hope that development will go in the right direction, and soon it will be possible to see it in these niches.

As for QKD, for now, the technology is an expensive extravagant toy. It has incredible characteristics and cool physics with mathematics inside, but there are limitations that are unlikely to allow its use for cloud technologies everywhere.

Realistic Scenarios

We have considered the integration of two top-notch (and therefore rare) technologies, which can be called the maximum achievable level of security in the cloud. Are there realistic scenarios when this is really necessary?

Open RAN. This is a concept of mobile operator infrastructure that has emerged from the combination of NFV, Cloud Native, and full openness of interfaces as an attempt to move away from proprietary mono-vendor solutions. There is a component here that manages NFV - MANO (Management and Orchestration), the compromise of which would mean the operator losing control over its network. This can also include components (VNFs) that implement security functions.

SoftHSM. A technology that virtualizes the Holy Grail of cryptography - HSM (Hardware Security Module). Today, HSM is a key component (in both literal and figurative senses) in the identification of a SIM card in a mobile operator's network and a plastic card in an ATM. It goes without saying that it is necessary to protect it “as much as possible”.

Compliance. There are situations when compliance with regulatory requirements is the highest priority, and when penalties for non-compliance can exceed the cost of the business or mean criminal prosecution. The richest company can go bankrupt from non-compliance with GDPR standards and subsequent personal data leaks.

Summary

AMD SEV technology significantly increases the level of security of virtual cloud infrastructure, bringing it closer to the case of local computing. The limitations that arise in this can be lifted by the application of Quantum Key Distribution (QKD).

The main alternative to QKD remains the application of post-quantum key distribution algorithms when they are standardized. It is important to remember that the resistance of quantum key distribution is mathematically proven, while post-quantum is not. For the latter, there is always a risk that in the future some algorithm or computation will be invented that will make it vulnerable.

Equipment implementing AMD SEV and QKD is already on the market, and its price will reach an acceptable level in the near future. Such a solution is applicable in cloud platforms, NFV, Open RAN - in any Cloud Native infrastructure.

The architecture of IoT cloud platforms is becoming increasingly complex. For further development, it is necessary to introduce standardized principles and approaches, which we are already seeing: Cloud Native, Edge Computing, OpenAPI, etc. Another such approach is the concept of Device Twins (DT), which we will discuss today.

Imagine a situation: You need to travel to another country for business, the language and customs of which you are not familiar with. It would be good in such a situation to have a local resident as a friend, who also speaks your language. He knows who to contact for various matters, and can also make a call via local connection (cheap, without roaming) and even arrange a meeting (for metadata exchange).

Something similar happens with an IoT device when it starts interacting with a platform. Several contradictions arise:

• data consumers of devices want to work with structured metadata, while devices cannot send them due to traffic constraints and differences in structure;
• device owners want to seamlessly connect them to various platforms;
• some services sometimes need to urgently obtain the status of the device or the latest state, and the device communicates periodically according to a schedule (at least here you can assume when this will happen) or by event (here there is complete unpredictability);
• the same thing, but in the other direction - from the platform to the device, this is especially true for firmware updates;
• you want to endow the device with new properties, for example, delegate decision-making, but it is not physically capable of doing this;
• the device moves through distributed infrastructure, connecting to its different edge points: transit traffic within the platform is growing, there is a need for autonomous operation when disconnected from the rest of the cloud.

In such scenarios, Device Twins can act as an intermediary that understands the language and capabilities of both the IoT device and the platform. It can store metadata, manage communication schedules, and even make autonomous decisions based on pre-defined algorithms.

When a device is mobile and connects to different edge points, the Device Twin can ensure seamless communication and management across the distributed infrastructure. For this, the Device Twin can be implemented in a hybrid manner - a simplified part residing in the Network Exposure Function (NEF) for low latency operations, and a more complex, intellectual part in the Application Function (AF) for data processing and decision-making in 5G or into the Service Capability Exposure Function (SCEF) in 4G.

This approach could solve many of the contradictions mentioned, while also adding the benefits of scalability, data consistency, and distributed resilience. However, challenges such as integration complexity, data synchronization between the Device Twin parts, and increased management costs should also be considered.

For effective implementation, it’s crucial to follow the standardized principles and approaches like Cloud Native for scalable microservices, Edge Computing for distributed processing, and OpenAPI for interoperable communication.

The development of standardized approaches and the adoption of Device Twins can lead to more efficient, scalable, and resilient IoT systems, opening new opportunities for innovation and addressing the challenges of complex IoT ecosystems.

Cloud Services Architecture

Typically, the lower-level architecture (specific to devices) of cloud services is represented as follows:

Separate layers are services necessary for interaction with devices: data acquisition, command sending, maintenance, etc. At the same time, each such layer performs standard functions for all devices or a certain group. In other words, we have functional separation of services.

Pros of this solution:

• each layer can be optimized for the function it performs, meaning that the most suitable technology stack can be selected;
• logically understandable separation for developers and engineers, the ability to decompose development and support tasks by functions.

Cons:

• each layer turns out to be monolithic - it is difficult to scale horizontally;
• all development is carried out by the platform vendor, device manufacturers do not participate in this in any way;
• IoT devices possess strong diversity, so technical solutions in each layer cannot be optimal for all classes of devices.

To address these challenges, the architecture can be rethought to involve more modular approaches such as microservices, which allow for better scalability and flexibility. Adopting Cloud Native principles can aid in optimizing for diverse device classes by allowing customization at each layer.

Moreover, involving device manufacturers in the development process can lead to more informed decisions and optimizations for particular device classes. An open, collaborative development process can contribute to creating a more adaptable and effective architecture.

This evolved architecture must also consider security, as IoT devices are often vulnerable to cyber attacks. By incorporating security at every layer and ensuring strong encryption and authentication mechanisms, the cloud services can become more robust and reliable.

In conclusion, while the traditional lower-level architecture offers logical separation and optimization possibilities, embracing modern approaches such as microservices, Cloud Native principles, and collaborative development can significantly enhance the scalability, flexibility, and security of cloud services for IoT devices.

Device Twins

To resolve existing contradictions and ensure further flexible development of IoT platforms, Device Twins of devices can come into play:

Device Twins will be those "smart" representatives of devices on the platform, having the same or a larger set of constants and variables (state) as their devices, synchronizing them when possible.

Drawing another analogy, Device Twins can be called a smart device driver on the platform: just as we now buy a component for a PC with a set of drivers for the main operating systems, so in the future we will be able to connect IoT devices to well-known platforms.

Leading IoT platform providers have adopted the Device Twin approach, including AWS Device Shadow and MS Azure Device Twins. Currently, JSON is used for this, which is a lightweight and platform-independent construct, but does not provide sufficient isolation. A more promising solution appears to be based on WASM (Web Assembly), which is an ultra-lightweight virtual machine that can run microservices (or more precisely, nanoservices).

It's also worth noting that this approach will have its own overhead, as identical services for similar devices must run in the cloud in a large number of copies. This, on one hand, appears to be a problem, but it is solvable. The fact is that the image of the Device Twin can be one for many similar devices, and the difference is only in the context (state, secrets, data). This approach can be compared to deduplication in data storage. It is possible to work efficiently with this – it is not necessary to constantly keep the context in memory. And it is important to note that cloud resources are relatively cheap, and they can be scaled almost infinitely, which is not the case with device resources.

Another interesting effect is that the launched Device Twin can be provided with the maximum level of protection, especially if it does not have to go for secrets to external sources, and the memory area is securely encrypted.

Integrating Device Twins into IoT platforms allows for a much more dynamic and flexible interaction model. It can ensure that device states are always available for applications and services even when the devices themselves are not reachable. Furthermore, it enables devices to utilize the processing power of the cloud for more complex analytics and decision-making processes that might not be feasible on the device itself due to resource constraints.

However, with these advantages, there are also challenges such as managing the overheads, ensuring security, and keeping the twins synchronized with the physical devices.

In conclusion, integrating Device Twins in IoT platforms presents an innovative way to enhance device management and functionality. It allows for more robust and flexible device interactions, better security, and can pave the way for new opportunities and use cases in the IoT ecosystem.

Projection on NB-IoT Architecture

Mobile operators were among the first to offer connectivity for IoT through NB-IoT (Narrow Band IoT), which is a narrowband communication protocol. This protocol is a part of the LPWAN (Low Power Wide Area Network) class, which aims to use device resources economically. For communicating with devices, the NIDD (Non-IP Data Delivery) transport protocol is used since using the IP stack is too cumbersome for LPWAN scenarios. This required the implementation of a new component to maintain the convenience of communicating with devices over the network – SCEF (Service Capability Exposure Function), a kind of API for device interaction. One of the most important changes in the interaction scheme of AS (Application Servers) with devices when working through SCEF is the emergence of a universal identifier. Now, instead of a phone number (MSISDN) or IP address, as it was in the classic 2G/3G/LTE network, the device identifier for the application server becomes an "external ID". It is defined by the standard in the format familiar to application developers as “<Local Identifier>@<Domain Identifier>”.

SCEF performs the following functions:

• Binding the SIM card identifier (IMSI) to an external ID
• Transmission of non-IP traffic (Non-IP Data Delivery, NIDD)
• Group operations, using an external group ID
• Support for acknowledged data transfer mode
• Data buffering
• Authentication and authorization of devices and application servers
• Simultaneous use of data from one UE (User Equipment) by several AS
• Support for special UE state control functions (MONTE - Monitoring Events)
• Triggering of devices
• Support for non-IP data roaming

All of this makes SCEF an ideal place for implementing Device Twins. In this case, some of the standard and typical functions will transition from the IoT platform to the operator in the form of additional services (VAS - Value Added Services).

In summary, the integration of Device Twins within the NB-IoT architecture through SCEF enables efficient, scalable, and flexible communication with IoT devices. By utilizing the non-IP data transmission and unique identifiers, it’s possible to ensure streamlined communication with the IoT devices without burdening them with complex IP stacks. Moreover, the SCEF can serve as the central point for implementing Device Twins, thus enabling more advanced functionalities such as monitoring, triggering, and state control. This approach enhances the IoT network by facilitating better control, scalability, and resource management for the IoT devices operating on LPWAN networks.

What Device Twins offer today?

1. Interoperability: The owner of the device can easily transfer it from one platform to another, which eliminates the lock-in to specific vendor ecosystems (Vendor-lock).
2. Binary Protocol: A fast, simple protocol with low overhead is used to communicate with the device, while enriched data (structured, corrected, normalized) is provided for the platform.
3. Engagement in Platform Integration: By involving device developers in the integration with platforms through the development of Device Twins, this process can be significantly accelerated.
4. Microservices Architecture Compatibility: Device Twins are inherently compatible with microservices architecture, allowing for distributed, scalable, and independent deployment of services.
5. Granular Security: Issues with one device do not affect the operation of others. Device Twins allow for isolated security, ensuring that a compromise or failure in one does not cascade to others.
6. Instant Device Inventory: Device Twins allow for real-time inventory management of devices. The state and properties of each device can be known and managed instantaneously through their Device Twin.

By incorporating Device Twins into IoT architectures, businesses and developers can achieve higher levels of flexibility, efficiency, and security in managing IoT devices. This is particularly beneficial in environments where there is a need to efficiently manage a large number of devices, ensure interoperability, and maintain high levels of security.

What Device Twins are ready to offer in the future?

Edge Computing: Making Device Twins mobile across infrastructure allows them to operate closer to their corresponding physical devices. This has several benefits including lower latency, elimination of transit traffic, and, most importantly, the ability to operate on edge nodes such as routers, base stations, and even smartphones. This is important both for autonomous operation in case of connection loss to the cloud, and for confidentiality reasons as not all clients may want to send their primary data to an external cloud. An example of this is the KubeEdge project, which allows containers to move through infrastructure (similar to VMware vMotion). Furthermore, this flexibility allows for the implementation of new scenarios where a device is dynamically assigned the role of Edge.

Example 1: Self-organization of a group of sea buoys. Drifting sea weather buoys can appoint one of them to act as a gateway for the others, choosing the one with the highest battery charge as a criterion. This role can later be reassigned to another buoy.

Example 2: Managing a smart home using a smartphone. In the event of an emergency power outage, devices with autonomous power sources remain active. These include smartphones and some smart home devices. In this case, Device Twins can operate directly on a smartphone, maintain connectivity with devices, and provide minimum smart home functions.

The utilization of Device Twins in conjunction with Edge Computing can revolutionize how IoT ecosystems are managed and operated. By enabling more localized and dynamic interactions between devices and their digital counterparts, there is potential for more efficient, resilient, and secure IoT environments. This is especially relevant in scenarios where latency is critical, or where there is a need for autonomy and data confidentiality. Through Edge Computing, Device Twins can facilitate innovative solutions to complex problems in the IoT space.

Resource-Intensive Tasks and AI: Device Twins can be loaded with resource-intensive tasks such as forecasting and decision-making with fuzzy logic, etc. The physical device remains unchanged; it does not need to be replaced or even have its firmware updated.

Example: IoT on the Blockchain. There are solutions where devices interact with each other and people through blockchain technology and can enter into smart contracts as independent actors (such as on the Vodafone Economy of Things platform). In this case, the blockchain client will run on the Device Twin without burdening the physical device itself.

Composite Device Twins: Device Twins can be assembled into digital replicas of more complex systems or products.

Example 1: Connected car. If each electronic component of a car has a Device Twin, it will be easy to create a Device Twin (or Digital Twin) of the entire car.

Example 2: Smart agriculture. Device Twins can exist not only for devices but also for services, such as a weather forecasting service. Imagine creating a composite Device Twin from the Device Twins of a temperature and humidity sensor and a weather forecast service, which makes decisions about irrigation. Taking weather forecasts into account will allow for more precise maintenance of target humidity levels while saving water. This decision would be made by the composite Device Twin, which could operate directly on the LPWAN base station serving the field.

Standards: Standardizing the Device Twin subsystem in 3GPP will allow it to become a common component of 5G or 6G and reduce the go-to-market time for device and platform manufacturers almost to zero. This can be achieved by standardizing the internal architecture of SCEF, defining the runtime environment, and the API of Device Twins up to application servers. This will allow MNO/MVNO to launch VAS, and device and platform manufacturers to eliminate integration barriers. This approach aligns completely with the Open RAN concept.

By incorporating resource-intensive tasks, AI, and compositing, Device Twins can become an extremely powerful tool for managing complex systems. This, coupled with standardization, could lead to a significant breakthrough in how IoT systems are deployed and managed, making them more efficient, agile, and capable of handling advanced tasks that were previously not feasible.

Conclusion

In this article, it has been demonstrated that the application of the Device Twins  concept can address current challenges in IoT and also provide flexible and adaptive development over several years. The DT approach aligns with modern technological trends and does not require a radical modification of the existing infrastructure of mobile operators, cloud services, or other IoT service providers.

Implementing DT within the context of SCEF (Service Capability Exposure Function) provides operators with the opportunity to offer additional value-added services (VAS) in addition to standard SCEF subscriptions. For users and developers, this means simplifying processes, optimizing interactions with devices, and creating more complex and adaptive systems based on IoT.

The use of DTs contributes to increased interoperability, allows for efficient integration of devices with various platforms, and addresses more complex tasks such as edge computing, artificial intelligence, and blockchain technologies.

In the long term, the standardization and widespread adoption of the DT concept can become key factors in the development of the Internet of Things, providing flexibility, scalability, and the ability to implement new, innovative scenarios for device and service interactions.

We've made a new blog within our website to accumulate all the materials we're going to publish very soon. SIBlink blog - is a place for the posts/articles to share SIBlink ideas and concepts. You can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is published!