Network devices configured to support cryptographically protected communication in multi-execution environments

Abstract

A network device is provided configured to support cryptographically protected communication in a multi-execution environment. Some embodiments pertain to a first network device configured to perform cryptographically protected communication with a second network device. This cryptographically protected communication includes at least a handshake protocol, a bulk data cryptographic protection protocol, and a recovery protocol. The session processing system obtains a first bulk cryptographic protection key and a recovery key from the handshake protocol. The first cryptographic protection key, rather than the recovery key, is forwarded to the host system.

Description

Technical Field

[0001] The currently disclosed subject matter relates to a first network device configured for cryptographically protected communication with a second network device, a method for cryptographically protected communication between the first network device and the second network device, and a computer-readable medium. Background Technology

[0002] Protected communication between two computerized devices is common on computer networks such as the Internet. For example, data protection can be achieved by encrypting data, authenticating data, or both. A well-known system for protecting communications in computer networks is TLS or DTLS.

[0003] We refer to the initial TLS or DTLS handshake between two endpoints as a full handshake, which utilizes a long-term secret key to establish endpoint authentication, such as authentication of the server endpoint, or alternatively, mutual authentication between the client and server endpoints. Several variations of such endpoint authentication via long-term secret keys have been standardized by the IETF; for example, an asymmetric private key corresponding to the public key from an X.509v3 certificate, an asymmetric private key corresponding to a so-called original public key, or a symmetric pre-shared secret key that has previously been distributed to both endpoints via some out-of-band means. During the full handshake, a certified key-building method is used to cryptographically derive ephemeral key material (e.g., a short-term key), which can then serve as the basis for deriving keys for bulk encryption and for a so-called recovery mechanism that enables a shortened handshake for future TLS or DTLS connections between the same endpoints. The shortened handshake enables performance-related savings, such as reduced network latency due to fewer required handshake messages, and lower computational overhead related to cryptography.

[0004] Several version-specific recovery mechanisms have been standardized by the IETF for the TLS, RFC5246, RFC8446 and DTLS, RFC6347 protocols. For example, session recovery via session ID from RFC 5246 is used in versions <= 1.2, session tickets from RFC5077 are used in versions <= 1.2, and recovery via a pre-shared key is specified for version 1.3. The referenced RFCs are included in this document by reference.

[0005] Known recovery variants effectively utilize a short-lived recovery key, which is then used in place of explicit endpoint authentication via a long-lived secret key derived from the initial full handshake. The term "recovery key" is used here because the TLS RFC does not provide a consistent naming convention for this purpose. Recovery keys are short-lived keys because they are associated with a configurable lifespan that typically will not exceed 24 hours. In the specific case of TLS 1.3, this lifespan also has a hard cap of up to 7 days. The shortened recovery handshake is implicitly authenticated only by the endpoints because it is cryptographically bound to the certified key establishment method from the initial full handshake.

[0006] For example, a common problem encountered on IoT devices is that short-lived keys within the recovery scope offer far less effective defense against attackers compared to long-term secret keys used for endpoint authentication. An attacker gaining access to the recovery key can recover the corresponding TLS (or DTLS) session without actually needing any access to the long-term secret key—which would be necessary for explicit endpoint authentication during the initial full handshake. With a leaked recovery key, the corresponding TLS (or DTLS) session could even potentially be recovered multiple times and from different endpoints. This would typically violate the system's security objectives.

[0007] Furthermore, particularly on the server-side TLS (or DTLS) endpoint, session ticket-based recovery variants utilize a so-called Session Ticket Encryption Key (STEK), which is typically exposed to the host system like all other ephemeral key material. An attacker who gains knowledge of the STEK through some means (such as exploiting information disclosure vulnerabilities on the host system) can effectively decrypt the recovery key material contained in the (STEK-encrypted) session ticket, and these can be collected from previously logged TLS (or DTLS) sessions. Besides enabling the attacker to recover the corresponding session, for TLS versions <1.3, this attack also allows for the decryption of corresponding bulk traffic, effectively negating the security benefits of forward secrecy. Notably, this attack effectively facilitates large-scale surveillance. Summary of the Invention

[0008] Improved communication between the first and second network devices would be advantageous.

[0009] In one embodiment, improved protection of ephemeral key material is provided at runtime. For example, in one embodiment, the only ephemeral key material that might be directly exposed to a host system of a network device is a symmetric key used within a specific scope of bulk protection (e.g., encryption); for example, one embodiment could expose a key_block derived from the ciphertext of the TLS protocol to the host system. Even if an attacker gains access to these keys, he / she will only be able to decrypt or manipulate the corresponding TLS (or DTLS) connection. However, this effectively prevents an attacker from stealing recovery keys and other ephemeral key material, such as key material used for recovery.

[0010] For example, the first network device can be configured to perform cryptographically protected communication with the second network device. Cryptographically protected communication includes at least a handshake protocol, a bulk data cryptographic protection protocol, and a recovery protocol. For example, the first and second network devices can be configured to use TLS or DTLS protocols.

[0011] Interestingly, the first network device is configured to house multiple separate execution environments, including a host system and a session processing system. The protocols involved in cryptographic communication are divided across at least these two execution environments.

[0012] The session processing system can be configured to obtain a password response based on a long-term secret and establish a secure session between a first network device and a second network device. One or more keys obtained in this way for cryptographic protection of bulk data are forwarded to the host system, but other ephemeral key materials, particularly recovery keys, are not.

[0013] Password protection for bulk data can now be performed by the host system, but an attack on the host system does not result in the leakage of another ephemeral key material. Furthermore, the long-term secret key is further removed from the host system; in one embodiment, the long-term secret key is stored in a secure system inaccessible to the host system, and accessed only by the session handler through an interface (e.g., a predefined API).

[0014] In practice, most activities are typically performed on the host system. The host system can also be the execution environment in which user applications run. Therefore, potential attacks on the first network device are more likely to occur on the host system; the host system has a larger attack surface and / or more external network connections. In fact, in one embodiment, the session processing system does not need to have any connection to an external computer; for example, because any communication required, such as that necessary to establish a cryptographic channel, is forwarded by the host system.

[0015] Key materials not needed for providing bulk protection services to user applications running on the host system are not exposed to the host system. Interestingly, the first network is able to recover and therefore conduct cryptographic communication with almost no delay because the session processing system can access the ephemeral keys used for it.

[0016] In one embodiment, the first network device includes a security system configured to store long-term secrets, and a session processing system configured to receive cipher responses from the security system. Preferably, the security system is a hardware protection module configured to store and protect cryptographic keys, such as a security module, a secure cryptographic processor, a so-called Trusted Platform Module (TPM), a dedicated microcontroller, etc.

[0017] In one embodiment, neither the host system execution environment nor the session processing system execution environment can access the long-term secret, and the host system execution environment cannot access the recovery key.

[0018] On the other hand, it is a communication method. Embodiments of this method can be implemented on a computer as a computer-implemented method, or in dedicated hardware, or a combination of both. Executable code for embodiments of the method can be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product includes non-transitory program code stored on a computer-readable medium for executing embodiments of the method when the program product is executed on a computer.

[0019] In one embodiment, the computer program includes computer program code that, when run on a computer, is adapted to perform all or part of the steps of an embodiment of the method. Preferably, the computer program is embodied on a computer-readable medium. Attached Figure Description

[0020] Additional details, aspects, and embodiments will be described by way of example only with reference to the accompanying drawings. Elements in the figures are illustrated for simplicity and clarity and are not necessarily drawn to scale. In the figures, elements corresponding to those already described may have the same reference numerals. In the drawings,

[0021] Figure 1a An example of an embodiment of a first network device configured for cryptographically protected communication is illustrated schematically.

[0022] Figure 1b An example of an embodiment of the second network device is illustrated schematically.

[0023] Figure 1c An example of an embodiment of a communication system is illustrated schematically.

[0024] Figure 2 An example of an embodiment of a first network device configured for cryptographically protected communication is illustrated schematically.

[0025] Figure 3 An example of an embodiment of a method for cryptographically protected communication is illustrated schematically.

[0026] Figure 4a A computer-readable medium having a writable portion including a computer program is illustrated schematically according to one embodiment.

[0027] Figure 4b A representation of a processor system according to one embodiment is illustrated schematically.

[0028] Reference Symbol List

[0029] The following list of references and abbreviations corresponds to Figure 1a-2 4a and 4b are provided to facilitate the interpretation of the drawings and should not be construed as limiting the claims.

[0030] 100 and 101 communication systems

[0031] 110 First Network Equipment

[0032] 130 processor system

[0033] 140 storage devices

[0034] 150 communication interface

[0035] Second network devices 160, 160.1, and 160.2

[0036] 170 processor system

[0037] 180 storage devices

[0038] 190 communication interface

[0039] 172 Computer Networks

[0040] 200 First Network Equipment

[0041] 211 Cryptographically Protected Communication

[0042] 210 host system

[0043] 220 Session Processing System

[0044] 230 Security System

[0045] 231 cryptographic interface

[0046] 221 First Communication Channel

[0047] 222 Second Communication Channel

[0048] 1000 computer-readable media

[0049] 1010 writable portion

[0050] 1020 computer program

[0051] 1110 (one or more) integrated circuits

[0052] 1120 processing unit

[0053] 1122 memory

[0054] 1124 Application-Specific Integrated Circuit

[0055] 1126 communication components

[0056] 1130 Interconnect

[0057] 1140 processor system Detailed Implementation

[0058] While the subject matter disclosed herein allows for many different embodiments, one or more specific embodiments are shown in the accompanying drawings and will be described in detail herein. It should be understood that this disclosure is to be considered as an illustration of the principles of the subject matter disclosed herein and is not intended to limit it to the specific embodiments shown and described.

[0059] In the following description, for the sake of understanding, the elements of the embodiments are described in operation. However, it will be clear that the various elements are arranged to perform the functions described to be performed by them. Furthermore, the subject matter disclosed herein is not limited to the embodiments, but also includes every other combination of features described herein or recited in mutually different dependent claims.

[0060] Typically, network devices such as IoT devices, desktop devices, and servers utilize the TLS (or DTLS) protocol to enable a cryptographically protected end-to-end secure tunnel between TCP-enabled (or UDP-enabled) software running on the device and the corresponding service running on the device's backend. Cryptographically protected data is used in all types of digital communication, such as sending or receiving digital data, including sensor data, computer commands, and media.

[0061] In many TLS (or DTLS) deployments, ephemeral key material (e.g., key material used for recovery, in particular) is far less protected than long-term secret keys. For convenience, key material is equivalent to the key derived from it.

[0062] For example, asymmetric long-term secret keys are typically protected within dedicated security systems designed specifically to protect this secret key material from being "static" when the device is powered off and from being leaked "while running." These types of security systems are often readily available as Hardware Security Modules (HSMs), Trusted Platform Modules (TPMs), PKCS#11-based security systems, or other types of specialized cryptographic subsystems. These subsystems typically expose only APIs for general cryptographic schemes (e.g., APIs for creating ECDSA signatures, RSA-based encryption and signing, etc.). However, such security systems do not provide APIs specifically tailored for TLS (or DTLS) handshakes. To store ephemeral key material (e.g., the so-called master secret, which also corresponds to the recovery key in TLS versions <1.3, etc.) within the security system, APIs specifically tailored for TLS (or DTLS) handshakes will be required. In the following text, we will continue to use the term "security system" as a general term encompassing these types of specialized off-the-shelf cryptographic subsystems. Security systems are typically part of network devices.

[0063] The actual encryption and authentication of bulk traffic is typically performed directly on the host system. This approach has the advantage of saving latency because the bulk data does not have to circulate through the secure system. Typically, the short-lived key material within recovery range is therefore often directly exposed to the host system, where defenses against leakage are much weaker than those for long-term keys within the secure system.

[0064] The embodiments described herein can be applied with all current versions of TLS and DTLS protocols, such as those standardized by the IETF. For example, in one embodiment, an additional subsystem—a session processing system—is integrated between the host system and the security system. This session processing system can be selected to provide more robust protection guarantees than the host system at runtime; for example, the session processing system can have more robust separation provided by a Type 1 hypervisor or a variant of a trusted execution environment. For example, the session processing system can be configured to run TLS (or DTLS) handshakes, alerts, and the change_cipher_spec subprotocol, and keep ephemeral key material (e.g., recovery keys, STEKs in server-side endpoint cases, etc.) protected. Derived keys (e.g., key_block) used for bulk protection (e.g., bulk encryption) are provided to the host system that processes all bulk encryption (e.g., application_data records within the TLS (or DTLS) protocol scope).

[0065] TLS, RFC5246, RFC8446, and DTLS, RFC6347 are IETF-standardized cryptographic protocols widely used to provide cryptographically protected end-to-end secure tunnels between software on IoT devices and services at the IoT backend; these are included in this document by reference. The TLS handshake has also been applied to the more recent QUIC protocol RFC9001, which is included in this document by reference.

[0066] The IETF standardization mechanisms for recovery, RFC5246, RFC8446, and RFC5077, enable performance-related benefits such as reduced network latency overhead and lower computational overhead related to cryptography; these are incorporated herein by reference. However, all these recovery methods have potentially serious security flaws without adequate runtime protection for ephemeral key materials within this scope (e.g., recovery keys, STEKs in the case of server-side TLS / DTLS endpoints). The method described in detail herein reduces the risk of attackers leaking ephemeral key materials from the device. Implementations can be combined with existing off-the-shelf security systems, particularly those that do not provide TLS (or DTLS)-specific APIs. This method can be applied to both client-side and server-side TLS (or DTLS) endpoints. Furthermore, depending on session-specific requirements and specific use cases, integration with security systems for endpoint authentication during the full handshake is applicable to both client-side and server-side endpoint authentication.

[0067] The IETF-standardized versions of TLS and DTLS allow for a variety of endpoint authentication and key exchange methods, some of which are also tied to specific protocol versions. The cryptographic schemes and conventions used to derive ephemeral key material (e.g., the key actually used in a recovery mechanism) can also be entirely different.

[0068] For example, operations within the scope of the `application_data` record can be handled by the host system, such as bulk encryption, while other sub-protocols (e.g., handshakes, alerts, and `change_cipher_spec`) are delegated to the session processing system. The session processing system can have control, even exclusive control, over all ephemeral key material, including recovery keys, STEKs in server-side TLS / DTLS endpoint scenarios, etc. Transitions between `application_data` and other record types can be handled through an explicit transfer of state and control between the host system and the TLS / DTLS session processing system.

[0069] Figure 1a An example of an embodiment of the first network device 110 is illustrated schematically. Figure 1bAn example of an embodiment of the second network device 160 is illustrated schematically. The first network device 110 and the second network device 160 may be part of the communication system 100.

[0070] The first network device 110 is configured to send and / or receive password-protected communications to / from the second network device 160.

[0071] The second network device 160 is also configured to receive and / or send password-protected communications to / from the first network device 110. The relationship between the first and second network devices does not need to be one-to-one. For example, the first network device 110 can be configured to perform password-protected communications with multiple second network devices or with a single second network device. The first network device 110 can be configured as a server device or a client device. The second network device can be a device according to one embodiment, such as the first network device, but this is not required. The second network device can be conventional.

[0072] Cryptographically protected communication includes various protocols, at least a handshake protocol, a bulk data cryptographic protection protocol, and a recovery protocol. These protocols are further explained herein. Embodiments may follow one of the standards mentioned herein to implement these protocols; however, embodiments that do not follow those standards are also possible.

[0073] For example, communication system 100 can be used to protect other communication needs, such as secure messaging, email, banking, cloud computing, and so on.

[0074] The first network device 110 may include a processor system 130, a storage device 140, and a communication interface 150. The second network device 160 may include a processor system 170, a storage device 180, and a communication interface 190. Storage devices 140 and 180 may be, for example, electronic storage devices, magnetic storage devices, etc. Storage devices may include local storage devices, such as local hard disk drives or electronic storage devices. Storage devices 140 and 180 may include non-local storage devices, such as cloud storage devices. In the latter case, storage devices 140 and 180 may include storage interfaces to non-local storage devices. The memory may include multiple discrete sub-storage devices, which together constitute storage devices 140 and 180. The storage device may include volatile writable portions (such as RAM), non-volatile writable portions (such as flash memory), and non-volatile non-writable portions (such as ROM).

[0075] Storage devices 140 and 180 can be non-transitory storage devices. For example, storage devices 140 and 180 can store data in the presence of power, such as volatile memory devices, such as random access memory (RAM). For example, storage devices 140 and 180 can store data both in the presence and absence of power, such as non-volatile memory devices, such as flash memory.

[0076] Devices 110 and 160 can communicate internally with each other, and with other devices, external storage devices, input devices, output devices, and / or one or more sensors via a computer network. The computer network can be the Internet, an intranet, a LAN, a WLAN, etc. Devices 110 and 160 include connection interfaces arranged to communicate as needed within or outside the communication system 100. For example, the connection interface can include connectors, such as wired connectors (e.g., Ethernet connectors, optical connectors, etc.) or wireless connectors (e.g., antennas, such as Wi-Fi, 4G, or 5G antennas).

[0077] Communication interface 150 can be used to send or receive digital data, such as communication, particularly password-protected communication. Communication interface 190 can be used to send or receive digital data, such as communication, particularly password-protected communication.

[0078] The execution of devices 110 and 160 can be implemented in a processor system. Devices 110 and 160 may include functional units that implement aspects of the embodiments. The functional units may be part of the processor system. For example, the functional units shown herein may be implemented, in whole or in part, as computer instructions stored in the storage device of the device and executable by the processor system.

[0079] The processor system may include one or more processor circuits, such as a microprocessor, CPU, GPU, etc. Devices 110 and 160 may include multiple processors. The processor circuits may be implemented in a distributed manner, for example, as multiple sub-processor circuits. For example, devices 110 and 160 may use cloud computing.

[0080] Typically, the first network device 110 and the second network device 160 each include a microprocessor that executes appropriate software stored at the device; for example, the software may have been downloaded and / or stored in a corresponding memory, such as volatile memory like RAM or non-volatile memory like flash memory.

[0081] Instead of using software to implement functionality, devices 110 and / or 160 can be implemented wholly or partially in programmable logic, such as as a field-programmable gate array (FPGA). These devices can be implemented wholly or partially as so-called application-specific integrated circuits (ASICs), such as integrated circuits (ICs) customized for a specific purpose. For example, the circuitry can be implemented using CMOS, for example, using hardware description languages ​​such as Verilog, VHDL, etc. Specifically, the first network device 110 and the second network device 160 may include circuitry for, for example, cryptographic and / or arithmetic processing.

[0082] The first network device 110 and / or the second network device 160 may include a security system. The security system is configured to store long-term secrets. For example, the security system may include a Trusted Platform Module (TPM) (e.g., according to ISO / IEC 11889), a secure cryptographic processor, or a dedicated microcontroller designed to securely store and / or isolate one or more cryptographic keys. The security system may include a hypervisor to create and / or implement a separate execution environment. The security system is preferably supported by secure hardware, but can also be created using software. For example, a kernel running on the device can implement a security system. A security system, especially one with hardware-based security, is preferred but not required; in critical situations, a session handler can handle the storage, protection, and processing of long-term keys. While the latter is not the preferred arrangement, it is still better than an arrangement where the host system handles long-term secrets.

[0083] These types of security systems are typically provided off-the-shelf as Hardware Security Modules (HSMs), Trusted Platform Modules (TPMs), PKCS#11-based security systems, or other types of specialized cryptographic subsystems. These subsystems typically only expose APIs for general cryptographic schemes (e.g., APIs for creating ECDSA signatures, RSA-based encryption and signing, etc.).

[0084] The first network device 110 and / or the second network device 160 can be configured to deploy multiple separate execution environments. For example, the device may include execution environment mechanisms. For example, the device may include an OS kernel and / or a hypervisor, etc., to create and / or implement separate execution environments.

[0085] In hybrid embodiments, the functional units are implemented in hardware (e.g., as a coprocessor, such as a cryptographic coprocessor) and in software stored and executed on the device.

[0086] Figure 1cAn example of an embodiment of communication system 101 is illustrated schematically. Communication system 101 may include a plurality of second network devices; second network devices 160.1 and 160.2 are shown. Communication system 100 may include a plurality of first network devices; a first network device 110 is shown. These devices are connected via computer network 172 (e.g., the Internet). Client and server devices may be configured according to one embodiment.

[0087] Figure 2 An example of an embodiment of a first network device configured for password-protected communication is illustrated schematically. The first network device 200 is configured to perform password-protected communication 211 with a second network device. Figure 2 The second network device is not shown. The first and second network devices, and possibly additional first and / or second network devices, may be part of a communication system for exchanging cryptographically protected data.

[0088] In one embodiment, the first network device 200 is compatible with existing standards, allowing the second network device to be a conventional network device. This is unnecessary; the second network device can be based on one embodiment. The latter is advantageous because if both endpoints are more secure, the data exchanged over the network is more secure. However, the second digital network can also, or instead, have higher security through conventional means.

[0089] Figure 2 Password-protected communication 211 with a second network device is illustrated. Password-protected communication 211 comprises at least three parts: a handshake protocol, a bulk data password protection protocol, and a recovery protocol. The handshake protocol establishes a short-lived key for password protection and, if necessary, arranges a means to resume communication without having to perform a full iteration of the handshake protocol. The latter is used in a later recovery protocol. This is advantageous because the handshake protocol takes time and delays communication. Removing or reducing the handshake protocol reduces latency.

[0090] For example, the first network device 200 and / or the second network device can run cryptographic applications that include communication with each other. The security of the application is increased by protecting the communication between the first and second devices.

[0091] The implementation can effectively sample on the server side. For example, in one embodiment, the first network device 200 may be a server device or an IoT backend device.

[0092] The implementation can effectively sample on the consumer side. For example, in one embodiment, the first network device 200 can be a consumer device or an IoT client.

[0093] Security System 230

[0094] The first network device 200 is configured with a security system 230. The security system 230 is configured to store a long-term secret. Typically, the security system 230 includes hardware-based security to protect the long-term secret. The security system can be configured to protect the long-term secret from the rest of the first network device 200. For example, the long-term secret may include the private key of an asymmetric key pair, such as a public-private key pair. For example, the long-term secret may include a private RSA key or a private ECDSA key. The public key corresponding to the private key can be shared with a second network device. For example, the long-term secret may include a symmetric key, which is shared with the second network device, for example, via an out-of-bounds channel. The long-term secret enables the generation of a short-term secret to be shared with another device. Access to the long-term secret generally enables the ability to read all communications and / or create authenticity tokens. Therefore, the disclosure of the long-term secret should be avoided.

[0095] The security system is configured such that the remainder of device 200 outside of security system 230 cannot directly access the long-term secret. To still allow use of the long-term secret, security system 230 derives a cryptographic interface 231 that allows certain operations to be performed using the long-term secret. The security system can be a hardware-based module that stores one or more long-term secrets accessible only through the cryptographic interface. For example, interface 231 may include operations for decrypting data using the long-term secret. For example, interface 231 may include operations for calculating an authentication token for data using the long-term secret (e.g., a signature or message authentication code). The security system can store multiple long-term secrets. The security system is preferred, but optional.

[0096] For enhanced security, a hardware-based security system is preferred, but it is not mandatory. For example, a security system can be an execution environment, such as a session handler (as described herein).

[0097] Execution environment

[0098] The first network device 200 is configured to house multiple separate execution environments. These multiple separate execution environments include a host system 210 and a session processing system 220.

[0099] For example, in an embodiment using (D)TLS, the host system can be considered the (D)TLS frontend. For instance, the (D)TLS frontend can be loaded into the execution environment as part of the original application process using (D)TLS, for example, by importing a library. The host system, such as the (D)TLS frontend, processes the application_data record. The session processing system can be considered the (D)TLS backend. For example, for this purpose, one or more dedicated daemons can run in separate process contexts. The frontend and backend can only connect via dedicated channels, such as via session and control channels. The session system, such as the (D)TLS backend, processes other sub-protocols of (D)TLS.

[0100] The execution environments cannot access data and / or software in another execution environment within the first network device 200, nor can they access data and / or software in the security system 230. Specifically, neither the host system 210 execution environment nor the session processing system 220 execution environment can access long-term secrets stored in the security system 230. Although the two execution environments cannot directly read or write code that accesses each other, they can be configured with interfaces to send and / or receive data.

[0101] Access to interface 231 is typically limited to a portion of system 200. For example, device 200 can be configured such that only session handler 220 can access interface 231.

[0102] In one embodiment, the host system runs a cryptographic application to cryptographically protect data using a bulk cryptographic protection key. This application is configured to use the bulk cryptographic protection key to protect data sent to and / or received from a second network device. For example, the cryptographic operations may be separated from other application components. For instance, in one embodiment, host system 210 runs a cryptographic application to cryptographically protect data using a bulk cryptographic protection key and runs a user application configured to use data received from and / or provide data to the second network device. Sending and receiving data by the user application can then be accomplished by the cryptographic application, wherein the data is protected with a bulk cryptographic protection key, as discussed herein.

[0103] For example, in one embodiment, the execution environment, particularly the host system execution environment and the session processing system execution environment, are separated from each other by hardware-supported execution separation (e.g., a hypervisor, such as a Type-1 hypervisor or a certain trusted execution environment variant).

[0104] Any general-purpose decoupling mechanism can be used to implement an execution environment. Decoupling mechanisms can utilize Trusted Computing Bases (TCBs). Decoupling can be implemented by a Trusted Computing Base (TCB). Examples of TCBs include TCBs that manage and decouple processes (such as the Linux or BSD kernel), TCBs that decouple the hypervisor of virtual machines (VMs), or TCBs that separate the insecure world from the secure world (such as the secure world of ARM TrustZone). These TCBs offer different trade-offs in terms of decoupling strength, hardware resource requirements, latency / throughput, etc. These TCBs can be stacked.

[0105] As discussed further in this article, different execution environments can be used to support different cryptographic applications.

[0106] Specifically, the host system can be used to support batch operations, such as password protection for batch data. For example, password protection can include confidentiality protection, such as data encryption and / or decryption. For example, password protection can include integrity protection, such as the generation and / or verification of authenticity tokens.

[0107] Session handlers can be used to support operations that are not related to bulk data protection. For example, session handlers can support operations that include using interface 231 of the security system.

[0108] For example, in one embodiment, the first network device 200 is configured according to TLS, for example according to RFC 8446 (included herein by reference), wherein

[0109] - Host system 210 is configured to handle records of type application_data protocol, but not other types of operations, such as handshakes, alerts, and change_cipher_spec types, and

[0110] -The session processing system 220 is configured to perform other types of operations.

[0111] Handshake Protocol

[0112] The handshake protocol is handled by a session handler. During the handshake protocol, session handling system 220 is configured to obtain a cryptographic response from security system 230 depending on a long-term secret. For example, depending on the long-term secret, interface 231 can be invoked with a request for a specified response. This response can be, for example, the decryption, signing, generation, or verification of a message authentication code. For example, the response can include a signature calculated using random numbers, etc.

[0113] A password response is sent to the second network device as part of a handshake protocol to establish a secure session between the first network device 200 and the second network device. The session processing system 220 obtains a first-batch password protection key and a recovery key from the handshake protocol. The first-batch password protection key is forwarded to the host system 210. The recovery key is not forwarded to the host system 210.

[0114] For example, a session processing system may obtain a key_block, which may contain one or more cryptographic keys. The key_block may include different keys for the client and server sides, and the keys may depend on the cipher suite used for encryption / authentication purposes. A typical example of a key used for bulk protection is a short-lived session key. As discussed herein, bulk protection can refer to the encryption of data sent from a first network device, the decryption of data received at the first network device, the generation and verification of authentication tokens, etc.

[0115] Two examples of establishing keys for bulk protection (e.g., for ephemeral session key material) are: 1) authentication key agreements, such as those based on (EC)DHE, and 2) key transmission, such as from older RSA cipher suites in TLS <= 1.2. See, for example, Section 4 of RFC 8446 (TLS 1.3) and Sections 7 and 8 of RFC 5246 (TLS 1.2), which are included herein by reference.

[0116] A recovery key generally refers to all other ephemeral key material that can be used to recover cryptographic communication between the first and second network devices, without involving long-term secrets, such as those that do not involve a full handshake protocol. For example, a recovery key may include a TLS or DTLS pre-master secret, a master secret, a recovery PSK, a session ticket encryption key (STEK), and so on.

[0117] Session processing system 220 can be configured to obtain a master secret shared with a second network device from a handshake protocol. The master secret can be used to derive a first-batch cryptographic protection key and a recovery key. More specifically, the master secret itself can be derived from a pre-master secret shared (e.g., negotiated) between the first and second network devices. The pre-master secret should also be protected. In TLS <= 1.2, the master secret can be used as a recovery key. In TLS 1.3, the recovery key is the derived key, called the pre-shared key.

[0118] Note that the host system 210 execution environment cannot access the recovery key. For example, if a master key and / or pre-master key are used, the host system 210 execution environment cannot access the master secret or pre-master secret. For example, the host system 210 execution environment may only be able to access ephemeral key material within the scope of bulk data protection, such as key_block or traffic key.

[0119] Bulk password protection keys and recovery keys are typically short-term keys. For example, they may have an validity period of up to one week, one day, etc.

[0120] The handshake protocol may include authentication of a second network device by a session handler.

[0121] Batch Data Password Protection Protocol

[0122] Host system 210 is configured to password-protect bulk data received at or sent to the second network device.

[0123] Password protection can be a form of confidentiality protection. For example, a bulk protection key, such as a symmetric decryption key, can be used to decrypt received data. Conversely, a bulk protection key, such as a symmetric decryption key, can be used to encrypt sent data.

[0124] Cryptographic protection can be integrity protection. For example, a bulk protection key, such as a symmetric authentication key, can be used to authenticate received data; for example, an authentication token associated with the received data (e.g., received as part of or in conjunction with the received data) can be authenticated using the bulk protection key. For example, an authentication token generated using the bulk protection key can be provided to the data being sent. Not all of the above four functions need to be present; for example, only one or two, or some, etc., may be required. For example, in one embodiment, confidentiality protection is not used, but authentication is used. For example, in one embodiment, integrity protection is not used, but confidentiality protection is used. The above four functions can each use different keys, or some or all can use the same key. For performance, a symmetric key is preferred for each of these, but each of these can also be performed using an asymmetric key. For example, asymmetric encryption / description, signature generation / verification, etc.

[0125] For example, on the receiving side, cryptographic protection of bulk data can include data decryption and authentication token verification. For instance, protection can include Authentication Encryption (AE) and Authentication Encryption with Associated Data (AEAD), for example, an encryption method that simultaneously ensures the confidentiality and authenticity of the data. For example, one embodiment can implement a cipher suite such as TLS <= 1.2, which supports authentication-only mode.

[0126] Depending on the desired outcome, additional cryptographic protection may be included. For example, replay protection may be added, thereby ensuring the freshness of sent and / or received responses. In one embodiment, bulk protection is specifically implemented within the execution environment of host system 210.

[0127] Recovery Agreement

[0128] Session processing system 220 is configured to obtain a cipher response from the recovery key during the recovery protocol. The cipher response is sent to the second network device as part of the recovery protocol to rebuild a secure session between the first network device 200 and the second network device. Session processing system 220 obtains a second bulk cipher protection key from the recovery protocol. The second bulk cipher protection key is forwarded to host system 210 for use in bulk data protection. Typically, the first and second bulk protection keys are symmetric keys; however, this is not required.

[0129] During the recovery protocol, the recovery key can be processed, for example, to obtain an alternative key. For instance, a pre-master secret or master secret can be processed during the recovery protocol to obtain an alternative key, which can then be used to perform cryptographic operations. Some processing in the recovery protocol can be pre-computed.

[0130] In one embodiment, session processing system 220 obtains a new key_block or new traffic key comprising multiple keys from a recovery protocol. These keys update existing keys. For example, the first batch protection key may be part of a first plurality of protection keys. The recovery protocol may provide a second plurality of protection keys.

[0131] The second batch protection key can be used by the host system for batch protection, such as as the first batch protection key, for confidentiality or integrity protection.

[0132] communication

[0133] In one embodiment, protocol communication is distributed between the host system and the session handler. In another embodiment, the security system is not configured to respond to or generate protocol messages. If a response from the security system is required, the session handler can invoke the security system's interface.

[0134] The host system and the session handler can work together in various ways. For example, in one embodiment, the host system 210 and the session handling system 220 are configured with a first communication channel 221.

[0135] For example, host system 210 and session processing system 220 may be configured with control mechanisms to indicate control over secure password-protected communication 211. This control mechanism indicates control over host system 210 during bulk protection. The control mechanism transfers control from host system 210 to session processing system 220 for both the handshake protocol and the recovery protocol.

[0136] Using a control mechanism, the host system 210 and the session handler 220 know which of them is responsible for communication. The control mechanism may include a second communication channel to transfer the state of secure, cryptographically protected communication 211 between the host system 210 and the session handler 220. For example, if the host system needs to generate a message it cannot generate (because it cannot access the key required to do so), it can send a message via the second communication channel 222 to transfer control. The transfer may include any state required to generate the new message.

[0137] For example, during the handshake protocol and recovery protocol, communication between the first network device 200 and the second network device can reach the host system 210 and be forwarded to the session processing system 220 through the first communication channel 221.

[0138] For example, if a message arrives while control is in a session handler, the communication may be forwarded.

[0139] The host system can also be configured, or instead, to forward received communications to the session handler depending on the type of communication associated with the received communication (e.g., the type of communication embedded therein).

[0140] In one embodiment, received communication may be encrypted, even if it is not bulk data. Specifically, any indication of the communication type may be encrypted; for example, the communication type itself may be encrypted. In one embodiment, the host system is configured to at least decrypt the communication type before forwarding it to the session handler, depending on the communication type. For example, in one embodiment, the host system is configured to decrypt all incoming communication and forward it if further processing by the session handler is required.

[0141] For example, embodiments using DTLS use a ContentType field that indicates the record type. The ContentType field can be used to determine whether a DTLS record will be processed by the host system or the session processing system. This corresponds to the sub-protocols used by TLS (e.g., application_data, handshake, alerts, etc.). The host system can be configured to pass all records that are not application_data to the session processing system. This can be extended with encryption of the ContentType field, for example, as part of the record payload protection feature. If encryption is used with the ContentType field, the host system can be configured to decrypt the record before processing it itself or forwarding it to the session handler.

[0142] Instead of having the host system simply forward (e.g., unmodified) all TLS (or DTLS) records that are not application_data to the session processing system, it is possible, as a variant, for the host system to always handle decryption / authentication checks for all kinds of protected records—not only application_data records, but also other types of TLS records after the initial handshake. This is possible because the host system and the session processing system can divide their responsibilities as desired, for example, using control channel 222.

[0143] Several additional optional improvements, details, and embodiments are described below.

[0144] Example 1

[0145] The setup and operation are outlined below. The device includes a TLS / DTLS session processing system. Note that the described method can be applied independently of the host system, acting as either a client or a server. For each active TLS / DTLS session with an external TLS / DTLS endpoint, two logical communication channels can be established between the host system and the TLS / DTLS session processing system. When the TLS / DTLS session processing system is in active control, the session channels can be used to transparently forward all TLS / DTLS protocol record types. The control channel can be used to transfer state and control between the host system and the TLS / DTLS session processing system (e.g., at each point in time and depending on the currently processed sub-protocol, only one of these systems can be the active TLS / DTLS protocol endpoint). During the full handshake, the TLS / DTLS session processing system interacts with the security system within the scope of endpoint authentication.

[0146] For example, the host system can be configured for TCP / IP-based connectivity with external TLS / DTLS endpoints. The host system is configured for bulk protection, specifically bulk encryption (e.g., handling the application_data record type). The host system has access to the symmetric key (key_block) used for encryption and authentication, but not to other ephemeral key material. The session channel is arranged to transparently relay all other record protocol types to the TLS / DTLS session processing system.

[0147] The session processing system is configured to manage the handshake and TLS / DTLS session state, as well as all ephemeral key material, such as handshake, alerts, and change_cipher_spec records. During the full handshake, the session processing system interacts with the security system within the scope of endpoint authentication.

[0148] Step 1. Initiate a new TCP / IP connection for TLS (or DTLS in the case of UDP) between the external TLS / DTLS endpoint and the host system. To initiate the TLS / DTLS handshake, the host system provides pre-initialized TLS / DTLS state (e.g., to signal whether TLS or DTLS is requested) and then transfers control to the TLS / DTLS session handling system. After relinquishing active control, the host system then transparently forwards all additional records between the TLS / DTLS session handling system and the external TLS / DTLS endpoint.

[0149] Step 2. Within the scope of endpoint authentication during the initial full handshake, the TLS / DTLS session processing system interacts with the security system (e.g., to obtain the ECDSA signature required for endpoint authentication via a long-term key). For the server-side TLS / DTLS endpoint, the involvement of the security system is not required if a shortened recovery handshake is requested and acceptable. The handshake between the TLS / DTLS session processing system and the external TLS / DTLS endpoint establishes all necessary state and ephemeral key material (e.g., key material for recovery, key_block for bulk encryption, STEK for encrypting session tickets if the server-side endpoint uses this recovery mechanism).

[0150] Step 3. After the handshake is complete, the TLS / DTLS session processing system provides the host system with all the state required to process the application_data record (e.g., key_block, but not other ephemeral key material) via the control channel and transfers control. The host system takes over control until it encounters a sub-protocol different from the application_data record type, which then triggers a transfer of state and control to another TLS / DTLS session processing system. The TLS / DTLS session processing system will then be the active TLS / DTLS endpoint until the corresponding sub-protocol event (e.g., key update, renegotiation, recovery, termination, etc.) has been completed.

[0151] Step 4. The host system takes over again as the active TLS / DTLS endpoint to handle bulk encryption (e.g., application_data records). Active involvement from the TLS / DTLS session handling system is not required until a record type other than application_data is encountered.

[0152] Example 2

[0153] In this exemplary embodiment, the first network device is equipped with a separation mechanism, such as a Trusted Computing Foundation (TCB), including a hypervisor and a security system. The security system is preferably configured to provide hardware-based protection for long-term secrets, but this is not mandatory. We will assume that the security system is a hardware-based module that stores one or more long-term secrets, accessible only through a cryptographic interface. It should be noted that the hardware module is not essential to the security system.

[0154] Without hardware-based protection, the setup may not protect the device from local physical attacks. This is particularly problematic because when the device is powered off, long-term private key material is left unprotected by any hardware device. However, separating long-term secrets from the host system still offers advantages if only attacks originating from the network are considered relevant.

[0155] This embodiment is assumed to have TCP / IP-based connectivity and TLS. Variant embodiments may instead use UDP and DTLS. Other variants use QUIC from RFC 9000. QUIC is also UDP-based.

[0156] For example, a separation mechanism such as a hypervisor can be used to create multiple execution environments. The first execution environment is called the "host execution environment." It runs a software package called the "host system." The first execution environment can also run applications, such as user applications. The second execution environment is called the "session processing execution environment." It runs a software package called the "session processing system."

[0157] For example, a user application can use the TLS library in a host execution environment, which essentially means that the library code runs in the same process context relative to TLS, with only the application_data subprotocol being processed there.

[0158] In the simplest case, for example, the session processing system could be a separate process decoupled solely from the OS kernel. This could be a separate process from the OS kernel's TCB, which is then dedicated to TLS session handling tasks, such as handling handshakes, alerts, and the `change_cipher_spec` sub-protocol, as well as interacting with the security system. As an alternative, using a stronger separation from the hypervisor, the host system and session processing system would reside in separate environments within different VMs decoupled from the hypervisor. Alternatively, the session processing system could potentially be implemented as some kind of bare-metal application, such as a unikernel omitting the POSIX OS kernel. Another alternative deployment scenario would be to move the session processing system into a Trusted Execution Environment (TEE).

[0159] One or more communication channels are created between the so-called host system and session processing system. In one embodiment, there are at least two communication channels: a session channel and a control channel.

[0160] In one embodiment, only one session channel and one control channel are used. Even in this case, multiple TLS sessions can be supported, for example, by multiplexing one or more communication channels. In one embodiment, creating multiple communication channels makes handling multiple TLS sessions easier.

[0161] In one embodiment, each application using TLS will typically correspond to a dedicated “host system” and will generally run as a dedicated application process—for example, the device may have multiple host systems in the sense of multiple TLS-enabled processes / applications. Each host system may have its own execution environment. Each host system can then connect to a single shared session processing system via one or more session and control channels. Alternatively, multiple dedicated session processing systems can be configured, such as one per host system.

[0162] Multiple TLS sessions handled by the same application (e.g., in the same host system environment) can be handled by a single pair of session and control channels (e.g., by utilizing multiplexing, or alternatively, by establishing a dedicated session and control channel for each TLS session).

[0163] Initial handshake - non-recovery case

[0164] Application: User applications signal to the host system via API that they want to initiate a password-protected end-to-end secure tunnel (referred to as a secure session) with a second network device using TLS. Instead of the application initiating the secure session, the secure session can be initiated by the second network device.

[0165] Typically, user applications and host systems belong to the same application process; for example, the TLS processing is usually handled by the loaded TLS library.

[0166] Host System:

[0167] a. Handing over control via the control channel. The host system can first pre-initialize the handshake message and forward it to the session processing system via the control channel, for example, in conjunction with handover control.

[0168] b. When control utilizes the session processing system, the host system transparently forwards all messages from the session processing system to the second network device, and vice versa.

[0169] For example, pre-initialization at the host system level can be used, at least in certain situations. For instance, when an application acts as a client, the host system can signal to the session handling system whether a TLS or DTLS session should be started, which SNI should be initialized, and possibly which TLS protocol version, cipher suite, etc. Such communication parameters can be transferred in a structured manner via the control channel rather than the session channel. Both options are possible.

[0170] Session processing system:

[0171] c. Complete the handshake protocol, which includes

[0172] i. Further populate the pre-initialized handshake message (if used).

[0173] ii. Interacting with security systems (e.g., to obtain the signature required for endpoint authentication via a long-term key).

[0174] iii. Obtained from the handshake protocol:

[0175] 1. Status

[0176] 2. Short-lived key material used for bulk encryption: key_block

[0177] An example of a key_block is given in TLS 1.2 RFC 5246. The example of a key_block is the traffic key in TLS 1.3 RFC 8446.

[0178] 3. Temporary key material for recovery.

[0179] d. Transfer control to the host system via the control channel, and forward the key_block to the host system via the control channel.

[0180] Generally, ephemeral key material is key material with a finite lifespan (e.g., short-lived as opposed to long-term keys). An initial handshake using a long-term key (e.g., involving DHE or ECDHE, etc.) can create a so-called pre-master secret. The pre-master secret is protected internally within the session processing system because it can be cryptographically combined with publicly visible information from previous handshakes to compute the master secret. Therefore, the master secret is derived from the pre-master secret, and this can be used for recovery purposes in TLS <= 1.2. In TLS 1.3, this recovery key is called a pre-shared key, and the protocol details differ.

[0181] Note that the key block (referred to as the traffic key in TLS 1.3 / RFC8446) is preferably the only ephemeral key material shared between the session processing system and the host system. The ephemeral key material used for recovery may include, for example, a master secret and a pre-master secret.

[0182] The Session Ticket Encryption Key (STEK) is another example of ephemeral key material, used only within the context of session ticket-based recovery and should be stored internally within the session processing system and not available to the host system. The STEK is used in the Session Ticket Mechanism (RFC 5077). The STEK is a key with a finite lifespan (e.g., 1 hour). It is used to encrypt session tickets, which are then sent to clients so that they can resume the session.

[0183] Batch protection

[0184] Host system: Receives a TLS message of type application_data containing encrypted data. Performs bulk decryption using the key_block received from the session handler. Sends the decrypted data to the application.

[0185] Examples of application_data are given in e.TLS 1.2 RFC5246 and TLS 1.3 RFC8446.

[0186] Host system: Receives unencrypted data from the application. Performs bulk encryption using key_block in a secure session. Sends encrypted data from the application_data message to a second network device.

[0187] This example treats encryption as a case of cipher protection for bulk traffic. However, other examples are possible. For instance (depending on the cipher suite used), a key block can include multiple symmetric keys, such as two for encryption and two for authentication. For example, for AES-CBC, there could be four keys: two for authentication and two for encryption—used separately by the client and server endpoints for one-way communication. Different options exist for AEAD ciphers, as AEAD utilizes a single operation for both encryption and authentication…; for TLS <= 1.2, authentication-only cipher suites are also possible, and so on.

[0188] Processing non-batch encrypted messages

[0189] Host system: Receives messages of type {handshake, alarm, change_cipher_spec}. Forwards messages to session handlers via session channels and transfers control via control channels.

[0190] Session processing system:

[0191] f. Create a response to a message of type other than application_data and send it to a second network device (using the host system via a session channel).

[0192] g. Returning control to the host system via the control channel.

[0193] Handshake - Recovery Case

[0194] Application / Host System: Initiate a reconstruction session with the second network device as described above.

[0195] Host system: Hands over control via the control channel. The host system can pre-initialize the handshake message and forward it to the session processing system via the control channel. As mentioned above, other options can also be used here.

[0196] Session processing system: Completes the handshake protocol, now using recovery key material instead of a long-term secret. Upon completion, control is returned to the host system.

[0197] Figure 3 An example embodiment of a method 300 for cryptographically protected communication between a first network device and a second network device is illustrated schematically. The cryptographically protected communication includes at least a handshake protocol, a bulk data cryptographic protection protocol, and a recovery protocol. The method includes...

[0198] - Multiple separate execution environments are arranged in the first network device (31), including a host system and a session processing system, wherein

[0199] - During the handshake protocol, the session processing system obtains a cryptographic response (320) based on a long-term secret. This cryptographic response is sent to the second network device as part of the handshake protocol to establish a secure session between the first and second network devices. The session processing system obtains the first batch cryptographic protection key and recovery key from the handshake protocol.

[0200] - Forward the first cryptographic protection key (330) to the host system,

[0201] - During the bulk data cryptographic protection protocol, the host system uses the bulk cryptographic protection key received from the session processing system to cryptographically protect the bulk data sent to and / or received from the second network device in the secure session (340).

[0202] During the recovery protocol, the session processing system obtains a (350) cipher response from the recovery key, which is sent to the second network device as part of the recovery protocol to rebuild the secure session between the first and second network devices. The session processing system also obtains a second batch cipher protection key from the recovery protocol.

[0203] - Forward (360) the second password protection key to the host system for use in bulk password protection.

[0204] In one embodiment, the first network device includes a security system configured to store long-term secrets, and the method includes obtaining a password response from the security system by a session processing system.

[0205] As will be apparent to those skilled in the art, many different ways are possible to perform the method. For example, the steps may be performed in the order shown, but the order of the steps may vary or some steps may be performed in parallel. Furthermore, other method steps may be inserted between the steps. The inserted steps may represent an improvement on the method described herein, or they may be unrelated to the method. For example, some steps may be performed at least partially in parallel. Moreover, a given step may not be fully completed before the next step begins.

[0206] Embodiments of this method can be executed using software that includes instructions for causing a processor system to perform method 300. The software may only include those steps taken by a specific sub-entity of the system. The software can be stored on a suitable storage medium, such as a hard disk, floppy disk, memory, optical disk, etc. The software can be transmitted as a signal along a wired or wireless route or using a data network (e.g., the Internet). The software can be made available for download and / or remote use on a server. Embodiments of this method can be executed using a bitstream arranged to configure programmable logic (e.g., a field-programmable gate array (FPGA)) to perform the method.

[0207] It will be appreciated that the currently disclosed subject matter also extends to computer programs suitable for putting the currently disclosed subject matter into practice, particularly computer programs on or in a carrier. The program may be in the form of source code, object code, intermediate source code, and object code, such as in a partially compiled form, or in any other form suitable for implementing embodiments of the method. Embodiments relating to computer program products include computer-executable instructions corresponding to each processing step of at least one of the methods described. These instructions may be subdivided into subroutines and / or stored in one or more files that may be statically or dynamically linked. Another embodiment relating to computer program products includes computer-executable instructions corresponding to each device, unit, and / or portion of at least one of the systems and / or products described.

[0208] Figure 4a A computer-readable medium 1000 having a writable portion 1010 and a computer-readable medium 1001 also having a writable portion are shown. The computer-readable medium 1000 is shown in the form of an optically readable medium. The computer-readable medium 1001 is shown in the form of an electronic memory, in this case, a memory card. The computer-readable media 1000 and 1001 can store data 1020, which can indicate instructions that, when executed by a processor system, cause the processor system to perform an embodiment of the communication method according to the embodiment. The computer program 1020 can be embodied on the computer-readable medium 1000 as a physical marker or by magnetization of the computer-readable medium 1000. However, any other suitable embodiments are contemplated. Furthermore, it will be appreciated that although the computer-readable medium 1000 is shown herein as an optical disc, the computer-readable medium 1000 can be any suitable computer-readable medium, such as a hard disk, solid-state memory, flash memory, etc., and can be non-recordable or recordable. The computer program 1020 includes instructions for causing the processor system to perform the communication method.

[0209] Figure 4b A schematic representation of a processor system 1140 according to an embodiment of a first network device is shown. The processor system includes one or more integrated circuits 1110. Figure 4b The diagram schematically illustrates the architecture of one or more integrated circuits 1110. Circuit 1110 includes a processing unit 1120, such as a CPU, for running computer program components to perform methods according to embodiments and / or implement modules or units thereof. Circuit 1110 includes a memory 1122 for storing program code, data, etc. A portion of the memory 1122 may be read-only. Circuit 1110 may include a communication element 1126, such as an antenna, a connector, or both, etc. Circuit 1110 may include an application-specific integrated circuit 1124 for performing some or all of the processing defined in the method. Processor 1120, memory 1122, application-specific IC 1124, and communication element 1126 may be interconnected to each other via interconnect 1130 (e.g., a bus). Processor system 1110 may be arranged for contact and / or contactless communication using antennas and / or connectors, respectively.

[0210] For example, in one embodiment, the processor system 1140 (e.g., a first network device) may include processor circuitry and memory circuitry, the processor being configured to execute software stored in the memory circuitry. For example, the processor circuitry may be an Intel Core i7 processor, an ARM Cortex-R8, etc. The memory circuitry may be ROM circuitry or non-volatile memory, such as flash memory. Alternatively, the memory circuitry may be volatile memory, such as SRAM. In the latter case, the device may include a non-volatile software interface, such as a hard disk drive, a network interface, etc., configured to provide the software.

[0211] It should be noted that the embodiments mentioned above are illustrative and not limiting of the subject matter currently disclosed, and those skilled in the art will be able to devise many alternative embodiments.

[0212] In the claims, any reference numerals placed between parentheses should not be construed as limiting the claims. The use of the verb "comprising" and its variations does not exclude the presence of elements or steps other than those stated in the claims. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as "at least one" preceding a list of elements indicate the selection of all elements or any subset of elements from the list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The subject matter currently disclosed can be implemented by hardware comprising several different elements and by a suitably programmed computer. In device claims that enumerate several parts, several of these parts can be embodied by the same hardware item. The mere fact that certain measures are referenced in mutually different dependent claims does not indicate that a combination of these measures cannot be used advantageously.

[0213] In the claims, reference numerals enclosed in parentheses refer to reference numerals in the accompanying drawings of exemplary embodiments or formulas of embodiments, thus increasing the comprehensibility of the claims. These reference numerals should not be construed as limiting the claims.

Claims

1. A first network device (200) configured for password-protected communication with a second network device, the password-protected communication comprising at least a handshake protocol, a bulk data password-protected protocol, and a recovery protocol, the first network device being configured to arrange a plurality of separate execution environments in the first network device, the plurality of separate execution environments comprising a host system (210) and a session handling system (220), wherein - during the handshake protocol, the session handling system is configured to obtain a password response depending on a long-term secret, the password response being sent to the second network device as part of the handshake protocol to establish a secure session between the first network device and the second network device, the session handling system obtaining a first bulk password-protected key and a recovery key from the handshake protocol, the first bulk password-protected key being forwarded to the host system, - during the bulk data password-protected protocol, the host system is configured to password-protect bulk data sent to or received from the second network device in the secure session using the first bulk password-protected key received from the session handling system, - during the recovery protocol, the session handling system is configured to obtain a password response from the recovery key, the password response being sent to the second network device as part of the recovery protocol to reestablish the secure session between the first network device and the second network device, the session handling system obtaining a second bulk password-protected key from the recovery protocol, the second bulk password-protected key being forwarded to the host system for use in the bulk password-protected.

2. The first network device of claim 1, wherein, The first network device comprises a security system (230) configured to store the long-term secret, the session handling system being configured to obtain the password response from the security system.

3. The first network device of claim 1 or 2, wherein, The bulk data password-protected protocol comprises bulk encryption, decryption, and / or authentication.

4. The first network device according to claim 1 or 2, wherein - the bulk password-protected is exclusively executed in the host system execution environment.

5. The first network device of claim 1 or 2, wherein, The execution environments have no access to data and / or software in another execution environment in the first network device, and no access to data and / or software in the security system.

6. The first network device according to claim 1 or 2, wherein - neither the host system execution environment nor the session handling system execution environment has access to the long-term secret, and - the host system execution environment has no access to the recovery key.

7. The first network device of claim 1 or 2, wherein, The host system runs a cryptographic application configured to password-protect data using the first bulk password-protected key or the second bulk password-protected key, the cryptographic application being configured to protect data sent to and / or received from the second network device.

8. The first network device of claim 1 or 2, wherein, During the handshake protocol, the session handling system is configured to obtain a master secret shared with the second network device from the handshake protocol, the first bulk password-protected key and the recovery key being derived from the master secret key, the master secret being inaccessible to the host system execution environment.

9. The first network device of claim 1 or 2, wherein, The first bulk password-protected key or the second bulk password-protected key and the recovery key are short-term keys.

10. The first network device according to claim 1 or 2, configured for TLS according to RFC8446, wherein - the host system is configured to process records of type application_data protocol, but not other types of operations, and the session handling system is configured to perform other types of operations.

11. The first network device of claim 10, wherein, The other types are at least one of handshake, alert, and change_cipher_spec types.

12. The first network device of claim 1 or 2, wherein, The host system and the session handling system are configured with a first communication channel, wherein communication between the first network device and the second network device during the handshake protocol and during the resume protocol arrives at the host system and is forwarded to the session handling system over the first communication channel.

13. The first network device of claim 1 or 2, wherein the host system and the session handling system are configured with a control mechanism to indicate control over the security ciphered communication, the control mechanism indicating control over the host system during the bulk ciphering, the control mechanism changing control from the host system to the session handling system for the handshake protocol and for the resume protocol.

14. The first network device of claim 13, wherein, The control mechanism comprises a second communication channel to hand over state of the security ciphered communication between the host system and the session handling system.

15. The first network device of claim 1 or 2, wherein, The communication comprises a communication type, the host system is configured to forward the communication to the session handling program depending on the communication type.

16. The first network device of claim 15, wherein, The communication type is encrypted, the host system is configured to at least decrypt the communication type before forwarding the communication to the session handling program depending on the communication type.

17. The first network device of claim 1 or 2, wherein, The host system is configured to provide a partial initialization state to the session handling system to be completed by the session handling system during the handshake protocol and / or the resume protocol.

18. The first network device of claim 1 or 2, wherein - the first network device is a consumer device or an IoT client, and / or - the first network device is a server device or an IoT backend device.

19. A method (300) for ciphered communication between a first network device and a second network device, the ciphered communication comprising at least a handshake protocol, a bulk data ciphering protocol, and a resume protocol, the method comprising - arranging (31) in the first network device a plurality of separate execution environments, the plurality of separate execution environments comprising a host system and a session handling system, wherein - obtaining (320) by the session handling system a cipher response depending on a long-term secret during the handshake protocol, the cipher response being sent to the second network device as part of the handshake protocol to establish a secure session between the first network device and the second network device, the session handling system obtaining a first bulk ciphering key and a resume key from the handshake protocol, - forwarding (330) the first bulk ciphering key to the host system, - ciphering (340) by the host system bulk data sent to and / or received from the second network device in the secure session during the bulk data ciphering protocol with the first bulk ciphering key received from the session handling system, - obtaining (350) by the session handling system a second bulk ciphering key from the second network device during the bulk data ciphering protocol, - ciphering (360) by the session handling system bulk data sent to and / or received from the second network device in the secure session during the bulk data ciphering protocol with the second bulk ciphering key obtained from the second network device, - obtaining (370) by the session handling system a third bulk ciphering key from the second network device during the resume protocol, - ciphering (380) by the session handling system bulk data sent to and / or received from the second network device in the secure session during the resume protocol with the third bulk ciphering key obtained from the second network device. - obtaining (350), by the session handling system from the recovery key, a cryptographic response during the recovery protocol, the cryptographic response being sent to the second network device as part of the recovery protocol to reestablish the secure session between the first network device and the second network device, the session handling system obtaining a second batch of password-protected keys from the recovery protocol, - forwarding (360) the second batch of password-protected keys to the host system for use in the batch password protection.

20. A transitory or non-transitory computer readable medium (1000) comprising data (1020) representing instructions, which when executed by a processor system, cause the processor system to perform the method according to claim 19.

Images