Knx system instruction encryption method and knx system target device instruction execution method

Abstract

The application provides a KNX system instruction encryption method and a KNX system target device instruction execution method, which comprises the following steps: obtaining first hardware fingerprint information of a gateway device and second hardware fingerprint information of a target device; generating a root key based on the first hardware fingerprint information and the second hardware fingerprint information, and generating a main session key based on the root key and a shared key negotiated with the target device; in response to a control instruction of a current session, generating a sub-session key based on the main session key and a session binding parameter corresponding to the current session; wherein the session binding parameter is updated after each generation of the sub-session key, so that the sub-session keys of different sessions are different; performing encryption processing on the control instruction based on the sub-session key to obtain current ciphertext; in the case that the current ciphertext is legal, sending the current ciphertext to the target device, so that the target device performs decryption processing on the current ciphertext to obtain the control instruction and executes the control instruction. The method can make the KNX system have strong security.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a KNX system instruction encryption method and a KNX system target device instruction execution method. Background Technology

[0002] The KNX (Konnex) system is a globally adopted open building automation control bus standard (ISO / IEC 14543), whose core advantages lie in its high degree of device interoperability and system reliability. Through a unified communication protocol, the KNX system integrates lighting, shading, HVAC, security, and energy management equipment from different manufacturers onto a unified platform, enabling centralized monitoring and intelligent linkage of various terminal devices within the building. The communication media of the KNX system primarily include twisted-pair cable (TP1), power line (PL), and Ethernet (IP). Among these, the TP1 bus, due to its stability and reliability, is widely used for local communication between end devices and control panels and gateways.

[0003] To address the cybersecurity threats faced by KNX systems, existing technologies primarily rely on some form of fixed key or long-term session key for encryption and authentication. Specifically, these include the following implementation methods: 1. Schemes based on pre-set shared keys, such as the KNX IP Secure standard launched by the KNX Association, which pre-installs an X.509 certificate and an initial shared key at the factory, negotiating subsequent session keys through a TLS handshake; however, this session key remains valid indefinitely. 2. Lightweight encryption schemes based on fixed keys. Some manufacturers, to adapt to low-computing-power environments, use fixed-key XOR operations or AES algorithms to encrypt commands; the key remains unchanged throughout the device's lifecycle. 3. Schemes based on storing fixed keys in a secure chip, where long-term keys are embedded in a hardware secure chip to enhance key storage security.

[0004] However, the existing technical solutions that rely on fixed keys or long-term session keys have the following drawbacks: once the fixed key or long-term session key is leaked during production, distribution or storage, all historical and future communications can be decrypted, making the entire KNX system insecure. Summary of the Invention

[0005] This application provides a KNX system instruction encryption method and a KNX system target device instruction execution method to solve the problem in the prior art that once the fixed key or long-term session key is leaked in the production, distribution or storage process, all historical and future communications can be decrypted, making the entire KNX system insecure.

[0006] In a first aspect, this application provides a KNX system command encryption method, the method being applied to a gateway device, the gateway device being communicatively connected to a target device in the KNX system, the method comprising:

[0007] Obtain the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device;

[0008] Based on the first hardware fingerprint information and the second hardware fingerprint information, a root key is generated; and based on the root key and the shared key negotiated with the target device, a master session key is generated.

[0009] In response to control commands for the current session, a sub-session key is generated based on the master session key and the session binding parameters corresponding to the current session; wherein, the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys for different sessions are different;

[0010] The control command is encrypted using the sub-session key to obtain the current ciphertext. If the current ciphertext is valid, it is sent to the target device so that the target device can decrypt it to obtain the control command and execute it.

[0011] Optionally, encrypting the control command based on the sub-session key to obtain the current ciphertext includes:

[0012] To obtain the compressed public key, the target device generates an original public key based on the NTRU encryption algorithm, and then compresses the original public key to obtain the compressed public key.

[0013] Based on the sub-session key, random parameters are generated, and based on the compressed public key, the random parameters, and the control command, encryption is performed using the NTRU encryption algorithm to obtain the current ciphertext.

[0014] Optionally, the step of generating random parameters based on the sub-session key, and performing encryption operations using the NTRU encryption algorithm based on the compressed public key, the random parameters, and the control command to obtain the current ciphertext includes:

[0015] The sub-session key is converted into a random number using a hash function, and the random number is converted into a corresponding random polynomial using a preset rule. The random polynomial is then used as the random parameter.

[0016] Convert the control command into a message polynomial of the NTRU encryption algorithm;

[0017] Based on the compressed public key, the message polynomial, and the random parameters, the control command is encrypted using the NTRU encryption algorithm to obtain the current ciphertext; wherein, the private key corresponding to the original public key is used to decrypt the current ciphertext to obtain the control command;

[0018] And / or, the verification method for whether the current ciphertext is valid includes:

[0019] Calculate the difference polynomial between the current ciphertext and each pre-stored legitimate ciphertext, wherein the legitimate ciphertext is obtained by encrypting legitimate instructions from the target device using the compressed public key;

[0020] Calculate the infinite norm of each of the difference polynomials, where the infinite norm is the maximum absolute value of all coefficients in the difference polynomial;

[0021] If there exists an infinite norm less than a preset threshold, the current ciphertext is determined to be valid.

[0022] Optionally, the step of negotiating and generating a shared key with the target device includes:

[0023] A first temporary key pair is generated on the gateway device side, the first temporary key pair including a first temporary public key and a first temporary private key;

[0024] The first temporary public key is fragmented and embedded into a predetermined free field of multiple original control messages of the KNX system to obtain a modified control message, which is then sent to the target device as the first message.

[0025] The target device receives a second message returned by the target device, wherein the target device restores the first temporary public key based on the first message, generates a second temporary public key and a second temporary private key, and fragments the second temporary public key in the same way and embeds it into the predetermined free field of the original control message to obtain the second message;

[0026] The second temporary public key is restored based on the second message; and the shared key is calculated based on the first temporary private key and the second temporary public key.

[0027] The predetermined idle field includes at least one of the following: a reserved field for the priority field in the control byte of the original control message; a redundant field for the numerical field used to indicate the control status in the original control message; and a field encoded by modulating the transmission interval of the original control message.

[0028] Optionally, obtaining the first hardware fingerprint information of the gateway device includes:

[0029] Within the trusted execution environment of the gateway device, a first feature acquisition operation is performed, the first feature acquisition operation including:

[0030] Collect the current actual operating frequency of the central processing unit of the gateway device, and calculate the frequency deviation between the current actual operating frequency and the nominal operating frequency of the central processing unit;

[0031] In the gateway device, a target memory region is determined in the dynamic random access memory, the charge leakage rate of different memory cells in the target memory region is collected, and a memory cell leakage current mapping feature vector is generated based on the charge leakage rate of the different memory cells.

[0032] The programming voltage threshold deviation of multiple predetermined physical address storage cells of the embedded storage chip in the gateway device is collected, and a flash memory cell feature vector is generated based on all the programming voltage threshold deviations.

[0033] The frequency deviation value, the memory cell leakage current mapping feature vector, and the flash memory cell feature vector are concatenated into concatenated feature data, and a secure hash algorithm is performed on the concatenated feature data to obtain the first hardware fingerprint information;

[0034] And / or, obtaining the second hardware fingerprint information of the target device includes:

[0035] Perform multiple second feature acquisition operations, the second feature acquisition operations including:

[0036] Send a request message to the target device, the request message being used to query the status of the target device;

[0037] Collect response feature information, which includes: the time interval from sending the request message to receiving the response message from the target device; and the waveform transition time between the rising edge and the falling edge in the signal of the response message.

[0038] The collected response feature information is subjected to discrete wavelet transform, and the second hardware fingerprint information is obtained based on the low-frequency coefficients obtained after the discrete wavelet transform.

[0039] Optionally, generating the root key based on the first hardware fingerprint information and the second hardware fingerprint information includes:

[0040] Obtain the first verification information corresponding to the first hardware fingerprint information and the second verification information corresponding to the second hardware fingerprint information;

[0041] The first hardware fingerprint information and the first verification information are input into the Reed-Solomon decoder so that the decoder calibrates the first hardware fingerprint information based on the first verification information to obtain the first calibrated fingerprint information.

[0042] The second hardware fingerprint information and the second verification information are input into the Reid-Solomon decoder, so that the decoder calibrates the second hardware fingerprint information based on the second verification information to obtain the second calibrated fingerprint information;

[0043] The first calibration fingerprint information and the second calibration fingerprint information are concatenated to form a concatenated fingerprint information. Based on the concatenated fingerprint information, the root key is generated through a key derivation function.

[0044] Optionally, sending the current ciphertext to the target device includes:

[0045] The current ciphertext, the session binding parameters corresponding to the current session, and the address information of the target device are concatenated to form the message to be authenticated.

[0046] Based on the sub-session key, the message to be authenticated is processed by a message authentication code construction algorithm to generate a first message verification code corresponding to the message to be authenticated;

[0047] The data at the preset byte position of the first message verification code and the message to be authenticated are combined into target information, and the target information is sent to the target device.

[0048] Secondly, this application provides a KNX system target device instruction execution method, the method being applied to a target device in a KNX system, the target device being communicatively connected to a gateway device, the method comprising:

[0049] After generating the original public key based on the NTRU encryption algorithm, the polynomial coefficients in the original public key are grouped to obtain multiple coefficient groups, each of which includes multiple polynomial coefficients.

[0050] Based on the polynomial coefficients included in each coefficient group, generate a hash value corresponding to each coefficient group;

[0051] For each coefficient group, a portion of the hash value is extracted to obtain the fingerprint information corresponding to each coefficient group.

[0052] All the fingerprint information is concatenated into a compressed public key, and the compressed public key is sent to the gateway device;

[0053] The steps for receiving the current ciphertext sent by the gateway device and generating the current ciphertext by the gateway device include: generating a root key based on the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device; generating a master session key based on the root key and a shared key negotiated with the target device; generating a sub-session key based on the master session key and the session binding parameters corresponding to the current session in response to the control command of the current session, wherein the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys of different sessions are different; generating random parameters based on the sub-session key, and performing encryption operations using the NTRU encryption algorithm based on the compressed public key, the random parameters, and the control command to obtain the current ciphertext;

[0054] The current ciphertext is decrypted to obtain the control command, and the control command is executed.

[0055] Optionally, receiving the current ciphertext sent by the gateway device includes:

[0056] The gateway device receives target information sent by the gateway device and parses data at a preset byte position of the first message verification code and a message to be authenticated from the target information. The message to be authenticated includes the current ciphertext, session binding parameters corresponding to the current session, and the address information of the target device. The first message verification code is generated by the gateway device based on the sub-session key and by processing the message to be authenticated through a message authentication code construction algorithm.

[0057] And / or, executing the control command includes:

[0058] Obtain the sub-session key, and based on the sub-session key, process the message to be authenticated using the message authentication code construction algorithm to generate a second message verification code corresponding to the message to be authenticated;

[0059] Compare the data at the preset byte position of the first message verification code and the data at the preset byte position of the second message verification code to see if they are consistent. If they are consistent, perform decryption processing on the current ciphertext to obtain the control instruction, and execute the control instruction.

[0060] And / or, the method for obtaining the sub-session key includes:

[0061] A master session key is generated based on the root key and the shared key negotiated with the target device; the root key is generated based on the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device.

[0062] Based on the master session key and the session binding parameters, the sub-session key is generated in the same manner as the gateway device.

[0063] Thirdly, this application provides a KNX system command encryption device, which is applied to a gateway device and is communicatively connected to a target device in the KNX system. The device includes:

[0064] The fingerprint acquisition module is used to acquire the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device.

[0065] An encryption module is used to generate a root key based on the first hardware fingerprint information and the second hardware fingerprint information; and to generate a master session key based on the root key and a shared key negotiated with the target device.

[0066] In response to control commands for the current session, a sub-session key is generated based on the master session key and the session binding parameters corresponding to the current session; wherein, the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys for different sessions are different;

[0067] The control command is encrypted using the sub-session key to obtain the current ciphertext. If the current ciphertext is valid, it is sent to the target device so that the target device can decrypt it to obtain the control command and execute it.

[0068] Fourthly, this application provides a KNX system target device instruction execution apparatus, which is applied to a target device in a KNX system, the target device being communicatively connected to a gateway device, and the apparatus comprising:

[0069] A compressed public key generation module is used to generate an original public key based on the NTRU encryption algorithm, and then group the polynomial coefficients in the original public key to obtain multiple coefficient groups, each of which includes multiple polynomial coefficients.

[0070] Based on the polynomial coefficients included in each coefficient group, generate a hash value corresponding to each coefficient group;

[0071] For each coefficient group, a portion of the hash value is extracted to obtain the fingerprint information corresponding to each coefficient group.

[0072] All the fingerprint information is concatenated into a compressed public key, and the compressed public key is sent to the gateway device;

[0073] A receiving module is configured to receive current ciphertext sent by the gateway device. The steps by which the gateway device generates the current ciphertext include: generating a root key based on a first hardware fingerprint of the gateway device and a second hardware fingerprint of the target device; generating a master session key based on the root key and a shared key negotiated with the target device; generating a sub-session key based on the master session key and session binding parameters corresponding to the current session in response to a control command of the current session, wherein the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys of different sessions are different; generating random parameters based on the sub-session key, and performing encryption operations using the NTRU encryption algorithm based on the compressed public key, the random parameters, and the control command to obtain the current ciphertext.

[0074] The decryption module is used to decrypt the current ciphertext to obtain the control command and execute the control command.

[0075] Fifthly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0076] The memory stores computer-executed instructions;

[0077] The processor executes computer execution instructions stored in the memory to implement the method as described in the first aspect, or to implement the method as described in the second aspect.

[0078] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect or the method described in the second aspect.

[0079] The KNX system instruction encryption method and the KNX system target device instruction execution method provided in this application have the following technical advantages:

[0080] 1. By acquiring hardware fingerprint information and generating a root key, the KNX system's root key is not a static, pre-installed plaintext number in the firmware or storage chip. Instead, it is derived in real-time from the unique, non-cloneable hardware characteristics of both the gateway device and the target device. This eliminates the risk of key leakage caused by its existence and circulation in plaintext during production, distribution, and storage. Attackers cannot obtain a valid root key by stealing firmware images or physically probing the storage chip. Even if an attacker manages to obtain the derived root key data block, the key is strongly bound to a specific pair of hardware devices and cannot be used on other devices, thus preventing key duplication and proliferation attacks.

[0081] 2. This method generates different sub-session keys based on the master session key and continuously updated session binding parameters. Each control command encryption uses a unique sub-session key derived from the fresh session binding parameters, ensuring that the encryption key for each communication is effectively "one-time pad". When an attacker cracks a sub-session key used for encryption, they can only decrypt the communication data encrypted with that specific key. Since the session binding parameters are updated after each key generation, the attacker cannot use the leaked key to decrypt previous historical communications (because historical communications used different sub-session keys) or future communications (because future communications will use new sub-session keys derived from the new parameters). This provides the KNX system with strong forward security and solves the problem in existing technologies where fixed key leakage leads to insecurity across all communications. Attached Figure Description

[0082] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0083] Figure 1 This is a schematic diagram of the KNX system instruction encryption method provided in the embodiments of this application;

[0084] Figure 2 This is a schematic flowchart illustrating a method for negotiating and generating a shared key with a target device, as provided in an embodiment of this application.

[0085] Figure 3 This is a schematic flowchart of a method for generating a compressed public key provided in an embodiment of this application;

[0086] Figure 4 This is a schematic flowchart of the KNX system target device instruction execution method provided in an embodiment of this application;

[0087] Figure 5 This is a schematic diagram of the method for generating a root key provided in an embodiment of this application;

[0088] Figure 6 A schematic diagram of the KNX system instruction encryption device provided in the embodiments of this application;

[0089] Figure 7 A schematic diagram of the KNX system target device instruction execution apparatus provided in the embodiments of this application;

[0090] Figure 8 A schematic diagram of the structure of the electronic device provided in this application.

[0091] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0092] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments matching this application. Rather, they are merely examples of apparatuses and methods matching some aspects of this application as detailed in the appended claims.

[0093] The KNX system faces the following problems in practical applications:

[0094] I. The KNX native protocol lacks an encryption mechanism. The KNX standard (ISO / IEC 14543) prioritizes reliability and interoperability in its design and does not mandate end-to-end encryption. This results in all control commands (such as turning on lights, locking / unlocking, and adjusting temperature) being transmitted in plaintext or with only a simple checksum over TP1 twisted-pair or IP networks. Attackers only need physical access to the KNX bus or intercept LAN data packets to completely steal the building's operational status and control logic, and even directly forge and inject malicious control commands to illegally control critical equipment such as lighting, air conditioning, door locks, and security systems, posing serious information leakage and physical security risks.

[0095] Second, the security of core hub nodes is vulnerable. The Android smart central control screen in the KNX system plays a dual role as a "protocol conversion gateway": on the one hand, it interacts with the low-speed KNX TP1 bus, and on the other hand, it communicates with high-speed IP networks (such as the cloud and LAN). This dual identity makes it a "choke point" for attacks. Once the device is compromised through physical contact or software vulnerabilities, attackers gain absolute control over the entire KNX bus network and can impersonate legitimate gateways to send arbitrary messages, while traditional bus devices cannot distinguish the authenticity of the commands.

[0096] Third, bandwidth constraints and computational resource constraints coexist. The physical layer bandwidth of the KNX TP1 bus is extremely low (maximum 9.6kbps), and the data field of a single frame is only 14 bytes at most. This means that any security protocol that introduces extra bytes will directly increase the number of packets, exacerbate bus congestion, and may lead to instruction delays or even loss, thus compromising the real-time performance and reliability of the system. Traditional Internet security protocols (such as the TLS handshake) with their overhead of hundreds of bytes are completely inapplicable in this scenario.

[0097] Fourth, key management is difficult to implement. If a scheme with a pre-set single key is adopted, the leakage of a key on a single device means that all devices in the entire system or area are at risk, lacking attack isolation capabilities. If a centralized key server is used, new devices cannot join the network when the network fails, and existing devices cannot update their keys. System availability is constrained by the network, which does not meet the basic requirements of high reliability and offline availability for building control systems.

[0098] For security protection of KNX systems, the industry currently mainly adopts the following types of implementation solutions:

[0099] I. KNX IP Secure (KNX Security Extension Standard). Introduced by the KNX Association in 2017, this solution encrypts KNXnet / IP packets based on the TLS 1.2 protocol and is only applicable to IP media (KNXnet / IP tunnels or routers). Its core process is as follows: devices are pre-installed with an X.509 certificate and initial PSK at the factory; upon initial network access, a session key is negotiated via a TLS handshake; subsequent packets are encrypted using AES-128-CBC. This solution effectively protects KNX packets at the IP layer, but offers no protection for plaintext transmission at the TP1 bus segment physical layer. Attackers can still directly intercept or inject packets at the TP1 layer.

[0100] II. Fixed XOR / Fixed Key Scheme. To reduce overhead, some embedded KNX gateway manufacturers use a fixed-key XOR encryption method at the application layer to encrypt data bytes. This scheme adds almost no processing latency and can run on low-power devices, but its security is extremely weak: XOR encryption is equivalent to the Vernam cipher degenerating into a reversible substitution under a fixed key. Attackers only need to collect a small number of known plaintext messages (such as the GroupValue_Write message for turning lights on / off) to deduce the key.

[0101] III. IPsec / VPN-based tunneling solutions. Some system integrators establish IPsec or WireGuard tunnels between the Android gateway and the cloud control server to encrypt control commands sent from the cloud to the gateway end-to-end. This solution can effectively defend against attacks from the external network, but it cannot protect against eavesdropping on the internal network segment or the local TP1 bus. Furthermore, it is complex to configure, requires maintaining the VPN connection state at the Android system layer, and places high demands on system stability.

[0102] IV. Whitelist / ACL Access Control Scheme. This scheme establishes a GroupAddress whitelist on the gateway side, forwarding only packets from authorized physical addresses. While this can limit unauthorized devices from sending packets to some extent, it relies on the physical address (KNX Individual Address) not being tampered with; attackers can bypass this by forging the physical address.

[0103] V. Security Chip (SE) Key Storage Scheme. Some high-end gateways use a security chip (such as NXP SE050) to store long-term keys, combined with AES-CCM to encrypt critical messages. This scheme offers high key storage security, but requires the additional purchase of a security chip, increasing hardware costs. Furthermore, it still relies on pre-set long-term keys and cannot achieve dynamic key rotation or forward security.

[0104] The aforementioned existing technical solutions all have varying degrees of technical defects, which are analyzed in detail below:

[0105] I. Limitations of the KNX IP Secure Solution. This solution only covers the IP medium and cannot protect the TP1 bus segment. In actual deployments, the TP1 segment between the Android gateway and various KNX actuators (such as electric curtain controllers, light dimmers, and door lock actuators) is still transmitted in plaintext. Furthermore, the minimum data size for a TLS handshake is approximately 300 to 500 bytes, far exceeding the 14-byte data field of a single KNX TP1 frame, making it impossible to directly use TLS at the TP1 layer. The session key in this solution is a device-level static key; if leaked, the session history can be completely decrypted, lacking forward security.

[0106] II. Security Flaws of Fixed XOR / Fixed Key Schemes. XOR encryption, with a fixed key, is equivalent to a simple substitution cipher and has been thoroughly proven by the academic community to lack semantic security. Attackers can recover the key directly after obtaining a small amount of data using a Known Plaintext Attack (KPA). Furthermore, this scheme lacks any integrity protection; attackers can perform bit-flipping attacks on the ciphertext, modifying instructions without knowing the key (e.g., changing "closed" to "open"), posing a significant threat.

[0107] III. Scope Limitations of the IPsec / VPN Tunnel Solution. This solution only protects communication between the gateway and the external server, offering no protection for the local area network (LAN) segment or the TP1 bus segment. Malicious insiders or devices already connected to the network can directly launch man-in-the-middle attacks on the local segment. Furthermore, the establishment and maintenance of the VPN tunnel consumes significant Android system resources, and connection drops may occur under high system load, affecting the real-time performance of control commands.

[0108] IV. The Bypassability of ACL Whitelist Schemes. KNX Individual Addresses (physical addresses) are transmitted in plaintext on the bus, and the KNX protocol itself does not authenticate addresses. Attackers can easily bypass the whitelist mechanism through address spoofing. This scheme is essentially an access control based on the invalidation of security assumptions and cannot be used as an independent security mechanism.

[0109] V. Scalability and Cost Issues of Security Chip Solutions. Security chip solutions require purchasing a security chip for each gateway device, increasing the BOM cost by approximately 15 to 30 RMB per unit, resulting in significant economic costs during large-scale deployments. Furthermore, this solution relies on pre-installed long-term keys from the factory, leading to complex key management. If a key is leaked during production, a batch of devices will be compromised. Moreover, existing solutions do not support verifying command legitimacy without decryption; the gateway must completely decrypt each message frame to determine its legitimacy, making it impossible to enforce access control policies in the encrypted domain, increasing processing latency and computational consumption.

[0110] Therefore, addressing the problem in existing technologies where leaks of fixed keys or long-term session keys during production, distribution, or storage can lead to the decryption of all past and future communications, rendering the entire KNX system insecure, this application provides a technical concept: Obtaining the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device in the KNX system, a root key is generated based on these two hardware fingerprints. Then, a shared key is generated through negotiation between the gateway device and the target device, and a master session key is obtained based on the shared key and the root key. When a control command needs to be sent to the target device in the current session, a dynamically updated sub-session key is generated based on the master session key. Using this sub-session key, the control command is encrypted using an encryption algorithm to obtain ciphertext. After verifying the validity of the ciphertext, it is forwarded to the target device, allowing the target device to decrypt the ciphertext, obtain the control command, and execute the control command.

[0111] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0112] Figure 1 This is a schematic flowchart of a KNX system instruction encryption method provided in an embodiment of this application. The method is applied to a gateway device, which is communicatively connected to a target device in the KNX system. The gateway device can be: a wall-mounted or desktop touchscreen running Android, Linux, or other embedded operating systems; a dedicated KNX / IP gateway or router; a building management server or industrial control host. The target device refers to an end device connected to the KNX TP1 or RF bus, receiving control instructions from the gateway device and executing specific operations. It has a microcontroller to run the decryption algorithm. The target device and the gateway device can be connected, for example, via the KNX TP1 bus or via KNXnet / IP. The target device may include, for example:

[0113] Lighting control devices, such as switch actuators, dimming actuators, LED drivers, and scene controllers, are designed to receive commands to switch circuits, adjust light brightness, and switch lighting scenes. Their safety requirements include preventing unauthorized switching on / off of lights from causing energy waste or safety hazards, and preventing malicious dimming from damaging the lighting fixtures.

[0114] Curtains and sunshades: such as curtain motor controllers, blind controllers, and roller shutter controllers. Their function is to control the forward and reverse rotation of the motor to adjust the opening and closing of the curtains and the angle of the blinds. The safety requirement is to prevent unauthorized operation.

[0115] HVAC components: such as air conditioning thermostats, fan coil unit controllers, floor heating controllers, and VAV variable air volume terminal controllers. Their function is to adjust temperature, fan speed, and mode. Their safety requirement is to prevent malicious tampering with temperature settings, which could cause a surge in energy consumption or an unsuitable environment.

[0116] Security and access control products: such as door lock actuators, electric door / window magnetic controllers, and alarm input / output modules. Their functions are to control door lock switches, arm / disarm alarm systems, and trigger audible and visual alarms. The security requirement is to prevent their control commands from being tampered with or forged.

[0117] Energy management and sensor products, such as smart meter interfaces, relay actuators, and general-purpose input / output modules, are used to switch on and off high-power loads, collect electricity data, and receive dry contact signals. Their security requirements are to prevent unauthorized switching on and off of important loads (such as production equipment) and to prevent the theft of energy data.

[0118] like Figure 1 As shown, the method includes:

[0119] S101. Obtain the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device;

[0120] In this step, for the first hardware fingerprint information, the gateway device can collect the following identifiers: the device's unique ID assigned by the Android system, the device's motherboard serial number, the MAC address of the Wi-Fi module or Bluetooth adapter, and the device model and hardware version number; after concatenating the collected identifiers in a predetermined order and format to form an original identifier string, the original identifier string is input into a cryptographically secure hash function (such as SHA-256), and the output hash value is used as the first hardware fingerprint information.

[0121] For the second hardware fingerprint information, the gateway device can send a specific probe message to the target device via the KNX bus. This message can be a standard GroupValue_Read request or a custom diagnostic message requiring an immediate response. After sending the probe message, the gateway device can use a high-precision timer to accurately record the round-trip time from sending the last bit of the probe message to fully receiving the first bit of the target device's response message. To reduce the random error of a single measurement, the above process can be repeated multiple times (e.g., 8 or 16 times). After removing obviously abnormal measurements, the arithmetic mean of the remaining valid round-trip time measurements is calculated. This arithmetic mean is concatenated with the target device's KNX physical address, and the device manufacturer ID and device type code obtained from the target device's attribute query. This concatenated string is also processed using a hash function (such as SHA-256), and the output hash value is used as the second hardware fingerprint information.

[0122] Optionally, obtain the first hardware fingerprint information of the gateway device, including:

[0123] Step 1: Within the trusted execution environment of the gateway device, perform the first feature acquisition operation, which includes:

[0124] A. Collect the current actual operating frequency of the central processing unit of the gateway device, and calculate the frequency deviation between the current actual operating frequency and the nominal operating frequency of the central processing unit;

[0125] Specifically, within the Trusted Execution Environment (TEE) of ARM TrustZone, a trusted application (TA) can read the real-time operating frequency of the CPU core by accessing secure system registers or driver interfaces. This reading is then compared to the CPU's factory-specified rated frequency to calculate the frequency deviation. It should be noted that this deviation originates from differences in the physical processes used in crystal oscillator manufacturing and is random and unique.

[0126] B. Determine the target memory region in the dynamic random access memory of the gateway device, collect the charge leakage rate of different storage units in the target memory region, and generate a memory unit leakage current mapping feature vector based on the charge leakage rate of different storage units.

[0127] Specifically, during TEE startup, the trusted application within it allocates a contiguous region from the system's reserved, protected secure memory as the target memory region. It then initializes this target memory region by writing a known, uniform test data pattern to each storage cell. Possible test data patterns include writing all 1s (i.e., all bits are high) or writing alternating checkerboard patterns such as 0xAA or 0x55. Writing all 1s is to observe the flipping of "1"s to "0"s due to charge loss in subsequent steps.

[0128] After writing the test data, trusted applications need to avoid performing standard DRAM refresh operations on this memory region. DRAM needs to be refreshed periodically to maintain data; stopping the refresh will cause the charge in the memory cells to gradually leak out through tiny leakage currents in physical structures such as transistors.

[0129] Trusted applications maintain the target memory region in this "no-refresh" static state for a predetermined waiting time. It should be noted that this waiting time is calibrated, sufficient for "weak" memory cells with high leakage current to begin experiencing data errors (i.e., bit flips), but not enough to cause all cells to fail.

[0130] After the waiting period ends, the trusted application performs multiple (e.g., hundreds or thousands) consecutive read operations on the target memory region, each read retrieving the charge state (represented as 0 or 1) of the current memory cell. Due to random factors such as thermal noise and alpha particle bombardment, a single read may not consistently capture errors caused by inherent leakage current differences. Therefore, a large number of repeated reads are required, and the read results for each specific memory cell (usually counted on a "row" basis, as memory cells in the same row are physically close and may have related process characteristics) are statistically analyzed to calculate the probability of a bit flip occurring in that cell during the test. For example, an ideal cell should always read a 1, while a cell with faster leakage current may read a 0 in some reads.

[0131] After collecting the flip probability data of all storage units, the feature vector is generated. The specific steps are as follows:

[0132] First, the target memory region is divided into multiple logical blocks (e.g., each row consists of 1024 memory cells). The flip probability of all cells within each logical block is aggregated and calculated, for example, by calculating the average flip probability of cells in that row, or by counting the number of cells whose flip count exceeds a certain threshold.

[0133] Secondly, the aggregated result of each logic block (a floating-point number or count value) is mapped (quantized) to a discrete numerical level. For example, the probability value range is evenly divided into 256 levels and represented by an 8-bit integer (0-255).

[0134] Finally, all these quantized discrete values ​​representing the leakage current characteristics of different memory regions are concatenated in a predetermined order (such as memory addresses from low to high) to form a long bit string, which is the final memory cell leakage current mapping feature vector.

[0135] C. In the acquisition gateway device, the programming voltage threshold deviation of multiple predetermined physical address storage units of the embedded storage chip is collected, and a flash memory cell feature vector is generated based on all programming voltage threshold deviations;

[0136] Specifically, within the TEE, a pre-selected set of fixed physical address memory cells in the embedded memory chip (such as eMMC) is directly read. The deviation of the programming voltage threshold of these cells from the nominal value is obtained through the underlying interface. Then, the most significant bits (such as the most significant bit, MSB) of these deviation values ​​are extracted and concatenated to form the flash memory cell feature vector. The flash memory cell feature vector can reflect the microscopic differences in the flash memory silicon wafer during manufacturing.

[0137] Step 2: Concatenate the frequency deviation value, the memory cell leakage current mapping feature vector, and the flash memory cell feature vector into concatenated feature data, and perform a secure hash algorithm operation on the concatenated feature data to obtain the first hardware fingerprint information;

[0138] In this step, the frequency deviation value, memory cell leakage current mapping feature vector, and flash memory cell feature vector collected in the above steps are sequentially concatenated to form a longer original feature data string.

[0139] Next, the concatenated original feature data string is input into a cryptographically secure hash function (such as SHA3-256) for calculation, and a fixed-length (such as 512 bits) digest value with high confusion and collision resistance is output, which is the final first hardware fingerprint information.

[0140] And / or, obtain the second hardware fingerprint information of the target device, including:

[0141] Step 1: Perform multiple second feature acquisition operations, which include:

[0142] A request message is sent to the target device to query the status of the target device and to collect response characteristic information, including: the time interval from sending the request message to receiving the response message from the target device; and the waveform transition time between the rising and falling edges in the response message signal.

[0143] Specifically, the gateway device sends a standard GroupValue_Read request message to the target device via the KNX bus. At the moment the gateway device sends the request message, it starts a high-precision timer, which stops when the target device's response message arrives at the gateway's KNX bus interface. It should be noted that this time interval includes the target device's internal processing delay and bus transmission delay, among which the portion determined by the target device's hardware (such as MCU processing speed and internal clock accuracy) has stability and characteristics.

[0144] Simultaneously, the gateway device captures the physical electrical signal waveform of the response message, accurately measuring the transition time of its rising edge (from low to high level) and falling edge (from high to low level). Since this transition time is determined by the physical characteristics of the target device's output drive circuit, it is also unique.

[0145] The aforementioned time intervals and waveform transition times together constitute a set of response characteristic information. To obtain stable characteristics, the second feature acquisition operation needs to be repeated multiple times (e.g., 32 times) to form a feature sequence.

[0146] Step 2: Perform discrete wavelet transform on the multiple response feature information collected, and obtain the second hardware fingerprint information based on the low-frequency coefficients obtained after the discrete wavelet transform.

[0147] Specifically, a discrete wavelet transform is performed on a sequence of response feature information obtained from multiple acquisitions. Haar wavelets or similar methods can be used to decompose the sequence into multiple levels. It should be noted that wavelet transform can decompose a signal into high-frequency components (representing noise and random interference) and low-frequency components (representing stable, slowly changing core features in the signal). The low-frequency coefficients after decomposition are extracted, and these coefficients reflect the inherent, stable patterns of the target device's hardware response.

[0148] By quantizing and encoding these low-frequency coefficients, a second hardware fingerprint of fixed length (e.g., 128 bits) can be generated.

[0149] S102. Generate a root key based on the first hardware fingerprint information and the second hardware fingerprint information; and generate a master session key based on the root key and the shared key negotiated with the target device.

[0150] Specifically, the first hardware fingerprint information (512 bits) obtained in the first step can be concatenated with the second hardware fingerprint information (128 bits) as the input key material for the key derivation function. This concatenated fingerprint information, the gateway device's serial number (as a salt value), and a fixed identifier string are then input into an HMAC-based key derivation function (such as the HKDF-SHA256 function) to generate a 256-bit device binding root key.

[0151] In response to the problem that the amount of key negotiation data in the aforementioned existing technical solutions is too large, far exceeding the maximum data field capacity of 14 bytes per frame of KNX TP1, and therefore cannot be directly implemented on the TP1 bus with a bandwidth of only 9.6kbps, the inventors of this application further considered that the key can be split and implicitly written into the free field of the KNX standard control field during the key negotiation process. Figure 2 This is a schematic diagram of the method for negotiating and generating a shared key with a target device according to an embodiment of this application, as shown below. Figure 2 As shown, the method includes:

[0152] S201. Generate a first temporary key pair on the gateway device side. The first temporary key pair includes a first temporary public key and a first temporary private key.

[0153] Specifically, the gateway device can call the key pair generator of the security key management service (such as the Android Keystore System) within its ARM TrustZone trusted execution environment. The generated key can be based on elliptic curve cryptography and use the secp256r1 (also known as P-256) standard curve.

[0154] The key generator executes within the secure environment of the TEE, producing a temporary elliptic curve key pair. This key pair includes: a first temporary public key consisting of 64 bytes (containing 32 bytes each of uncompressed X and Y coordinates), and a corresponding first temporary private key. After generation, the first temporary private key is stored in the protected storage area of ​​the TEE, ensuring that it cannot be read by the operating system or other applications; while the first temporary public key is prepared for subsequent transmissions.

[0155] S202. The first temporary public key is fragmented and embedded into a predetermined free field of multiple original control messages of the KNX system to obtain a modified control message, which is then sent to the target device as the first message. The predetermined free field includes at least one of the following: a reserved field of the priority field in the control byte of the original control message; a redundant field of the numerical field used to indicate the control status in the original control message; and a field encoded by modulating the transmission interval of the original control message.

[0156] The first temporary public key is 512 bits (64 bytes × 8 bits / byte). To accommodate the low bandwidth of the KNX bus, it needs to be transmitted in fragments. This embodiment defines the steganographic data unit that each KNX standard control frame can carry as 9 bits. Therefore, the entire public key is divided into approximately 57 (512 / 9, rounded up) 9-bit data fragments. Next, the fragmented data is embedded into the following three types of predefined free fields in a normal KNX control message. These fields are either underutilized or contain redundant information in standard communication:

[0157] Priority reserved bits in control bytes: In the control bytes of KNX TP1 frames, two bits are defined as system priority fields, but in most building control scenarios, they are fixed at the default value and rarely change. Therefore, these two bits are used as steganography carriers.

[0158] Redundant high bits of numerical fields: When the control instruction is a simple binary state (such as a switch quantity of 0 or 1), the low bits of its data byte are sufficient to represent it. The high bits (such as Bit7 to Bit2) are usually fixed values, which constitute redundancy. Therefore, these 6 redundant high bits are used as steganography carriers.

[0159] Message transmission interval time encoding: The KNX standard specifies the minimum time interval between messages. Therefore, by precisely modulating the transmission interval between two adjacent normal messages, for example, the standard minimum interval can be used to represent binary '0', and a slightly longer but still standard time interval can be used to represent binary '1', thereby encoding 1 bit of steganographic information in the time dimension.

[0160] When the gateway device needs to send a normal KNX control message to the target device, it simultaneously performs a steganography operation. Specifically, it fragments a 9-bit public key and fills it into two reserved bits in the control byte of the current message and six redundant bits in the data field. The last bit is encoded by adjusting the transmission interval with the next message. Thus, a modified control message carrying steganographic data is generated. The gateway continuously sends approximately 57 such messages, forming the first message sequence. For the target device, these messages are firstly legitimate control commands; simultaneously, they secretly carry key negotiation data.

[0161] S203. Receive the second message returned by the target device, wherein the target device restores the first temporary public key based on the first message, generates a second temporary public key and a second temporary private key, and fragments the second temporary public key in the same way and embeds it into a predetermined free field of the original control message to obtain the second message.

[0162] The target device continuously listens to the bus. When it receives the first message sequence from the gateway device, it first processes it as a normal control command. Simultaneously, its firmware's steganography parsing module extracts 9 bits of steganographic data from predetermined free fields (control byte reservation bits, data redundancy bits, and measurement frame interval) of each message. After collecting approximately 57 fragments, it reassembles them to reconstruct the gateway device's first temporary public key.

[0163] Subsequently, the target device generates its own second temporary key pair locally (including a second temporary public key and a second temporary private key), using the same algorithm and parameters as the gateway. Next, the target device uses the exact same steganography rules as S202 to fragment its second temporary public key and embed it into the corresponding free field of the original control message it needs to send to the gateway device, forming a second message sequence, which it then sends back to the gateway device.

[0164] S204. Restore the second temporary public key based on the second message; and calculate the shared key based on the first temporary private key and the second temporary public key;

[0165] After receiving the second message sequence returned by the target device, the gateway device, while processing its normal control information, extracts and reconstructs the target device's second temporary public key from these messages. At this point, the gateway device and the target device have securely exchanged temporary public keys. The gateway device uses the securely stored first temporary private key and the newly restored second temporary public key to execute the elliptic curve Diffie-Hellman algorithm, specifically, elliptic curve scalar multiplication, resulting in a 32-byte shared secret value. This shared secret value is the shared key subsequently used to derive the master session key. It should be noted that this calculation is performed within the TEE (Trusted Execution Environment), ensuring that the private key does not leave the secure environment and that the calculation process cannot be eavesdropped on.

[0166] Figure 2 The method shown has the following technical effects:

[0167] During the negotiation and generation of the shared key, underutilized bit and time resources within the normal control message format are utilized. All steganography operations occur within standard-defined message fields, and modifications to field values ​​are controlled within the scope permitted by the standard or not explicitly defined. The message carrying the steganographic data fully conforms to the KNX standard in terms of format, length, and addressing mode, and can be normally received and forwarded by any standard KNX device on the network. Furthermore, this design does not generate any additional KNX communication messages, thus not increasing the bus load. Splitting the public key into dozens of normal messages distributes the communication overhead of key negotiation over a period of normal communication, minimizing the impact on the real-time performance of a single instruction. Additionally, elliptic curve operations are highly efficient on modern gateway processors, meeting the computational limitations of KNX devices.

[0168] After obtaining the root key and shared key, the lower 16 bits (or 32 bits) of the Unix timestamp of the gateway device's current system time can be retrieved. For example, the last 16 bits of the binary representation of the timestamp value can be used as the timestamp. It should be noted that this timestamp is a public or semi-public random number (nonce) that changes over time, primarily to provide freshness and uniqueness. Even if the same pair of devices renegotiates multiple times within a short period, different timestamps will result in different master session keys, effectively preventing replay attacks and ensuring the uniqueness of each session key.

[0169] Finally, the master session key is generated using an HMAC-based key derivation function. Taking HKDF (RFC 5869) as an example, the specific steps are as follows:

[0170] Step 1: Define HKDF parameters;

[0171] Input key material: Use the negotiated shared key as the IKM of HKDF.

[0172] Salt: The Device Binding Root Key (DBRK) is used as the salt for the HKDF. In cryptography, the salt is used to increase the randomness and complexity of the key derivation process.

[0173] Information: Construct a specific string as the HKDF's info parameter. This string can consist of a fixed identifier and a variable part, such as: "KNX-KDP-SK-v1"||timestamp_16bit. Here, "KNX-KDP-SK-v1" is the fixed identifier for the protocol version, and timestamp_16bit is the 16-bit timestamp mentioned above. The info parameter is used to bind the derived key to a specific context or purpose, ensuring that the key used to encrypt KNX commands is not misused for other purposes.

[0174] Step 2: Execute HKDF-SHA256

[0175] Extraction phase: First, HKDF uses the HMAC-SHA256 function with the salt value as the key to process IKM and extract a pseudo-random, uniformly distributed intermediate key PRK.

[0176] PRK = HMAC-SHA256(Salt=DBRK, IKM=SharedSecret)

[0177] Extension Phase: Then, using PRK and info, the master session key of the required length is extended by iterating through HMAC-SHA256. In this embodiment, the master session key can be, for example, a 128-bit (16-byte) master session key, so only one extension is needed.

[0178] Master session key = HMAC-SHA256(PRK,T(1)||info), where T(1) is the iteration counter, taking the first 128 bits of the output result.

[0179] The validity period of the generated master session key can be set to, for example, 24 hours, which can be configured through the gateway device's management interface. By configuring the validity period, even if the master session key is leaked for some reason, attackers can only decrypt or forge communications generated within the validity period (maximum 24 hours). After expiration, a new key must be renegotiated, thus limiting the potential loss.

[0180] S103. In response to the control command of the current session, generate a sub-session key based on the main session key and the session binding parameters corresponding to the current session; wherein, the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys of different sessions are different;

[0181] The purpose of this step is to generate a unique, temporary sub-session key for each specific control command interaction, ensuring forward security of communication. Even if the long-term master session key or a particular sub-session key is leaked in the future, attackers will not be able to decrypt historical or future communication sessions. The trigger condition for generating a sub-session key is when the gateway device is ready to send a new control command to the target device. That is, before starting the encryption process of the control command, it first checks and generates a sub-session key dedicated to this communication, thereby limiting the validity period and use of the key to the very short time of a single control command transmission.

[0182] Specifically, in this embodiment, the session binding parameter can be a 32-bit unsigned integer counter, which is dedicated to binding to each upcoming control command session. After the master session key is successfully negotiated through step S102, the counter is initialized to 0 and the counter value is stored in the volatile memory of the gateway device.

[0183] The update rule for this counter can be as follows: each time the gateway device needs to send a new control command to the target device, it generates a sub-session key specific to this command based on the current counter value. Once the sub-session key is generated and ready to be used to encrypt the command, the counter value is immediately incremented (e.g., by 1) to prepare for the key generation of the next command. Through this design, each control command is bound to a unique counter value.

[0184] When the application layer of the gateway device generates a control command that needs to be sent to the target device in the KNX system, the subkey generation process is triggered. The specific process is as follows:

[0185] A fixed string constant (e.g., "KNX-SK-RENEW") identifying the purpose of the key update is concatenated with the current non-incrementing 32-bit counter value to form a unique message data block. Then, the aforementioned master session key is used as the key, and the concatenated message data block is used as input to execute a hash-based message authentication code algorithm. Specifically, this embodiment uses the HMAC-SHA256 algorithm. This algorithm uses the SHA-256 hash function to process the input message under the control of the master session key, generating a 256-bit (32-byte) pseudo-random output. Finally, the required number of bits (e.g., the first 128 bits) can be extracted from the output of the HMAC-SHA256 algorithm as the sub-session key used for encrypting this control command. This sub-session key will be specifically used to encrypt the subsequent single control command and calculate its message authentication code. Since the sub-session key used for each control command is derived from the master session key and the unique counter through a one-way hash function (HMAC-SHA256), it is computationally impossible to derive the master session key from the sub-key. Even if an attacker intercepts the ciphertext of a particular communication and manages to crack the sub-session key used in that communication, they cannot use this key to decrypt any other past or future communication records. This is because past communications used smaller counter values, while future communications use larger counter values, resulting in completely different derived sub-session keys. Furthermore, since the master session key itself has an expiration date, it periodically expires and is renegotiated, further reducing the potential time window for loss due to key exposure.

[0186] Furthermore, since the aforementioned counter is stored in volatile memory, the counter value will be lost after the gateway device is powered off and restarted. Therefore, when the gateway device is powered on again and needs to send commands, a completely new key negotiation process needs to be triggered to establish a new session state, thereby ensuring that each communication after the gateway device starts up is based on a completely new key sequence, which enhances security.

[0187] S104. Encrypt the control command based on the sub-session key to obtain the current ciphertext; if the current ciphertext is valid, send the current ciphertext to the target device so that the target device can decrypt the current ciphertext, obtain the control command, and execute the control command.

[0188] In this step, the control commands are encrypted based on the sub-session key to obtain the current ciphertext, which may include:

[0189] Step 1: Obtain the compressed public key. After the target device generates the original public key based on the NTRU encryption algorithm, it compresses the original public key to obtain the compressed public key.

[0190] Specifically, the NTRU encryption algorithm can be used to encrypt control commands. During the initialization phase, a set of lightweight NTRU encryption algorithm public parameters needs to be selected and published, and the corresponding raw key pair (including the raw public key and the raw private key) needs to be generated.

[0191] Specifically, the selected common parameters include:

[0192] Selecting a polynomial ring

[0193] in:

[0194] =251 (a prime number that determines the degree of the polynomial);

[0195] =2048 (modulus, approximately) (used for coefficient modulo).

[0196] Private key polynomial The range of values ​​for the coefficient is And its Hamming weight (i.e., the number of terms with non-zero coefficients) Public key generation auxiliary polynomial The range of values ​​for the coefficient is also... Hamming weight .

[0197] The target device generates its original key pair in a secure environment, where the original private key is a polynomial. The corresponding original public key Generated by the following formula:

[0198]

[0199] in, It is a small module (usually 3 is acceptable). It is a polynomial of the original private key In the ring The modular inverse of the above satisfies:

[0200]

[0201] The final generated original public key It has A polynomial with n coefficients, each coefficient being in the range of n. Integers within.

[0202] To adapt to the bandwidth constraints of the KNX bus and the computing power limitations of terminal devices, this embodiment provides a method for generating compressed public keys, which can be executed by the target device. Figure 3 This is a schematic diagram of the method for generating a compressed public key provided in an embodiment of this application, as shown below. Figure 3 As shown, the method includes:

[0203] S301. The polynomial coefficients in the original public key are grouped to obtain multiple coefficient groups, each of which includes multiple polynomial coefficients.

[0204] Due to the original public key The original public-key polynomial is quite large (N=251 coefficients, each requiring approximately 11 bits, totaling about 345 bytes), and direct use for encryption and transmission would exceed the capacity of the KNX system. Therefore, lossless compression is necessary. Thus, a block hash compression algorithm is used in this step. The 251 coefficients are grouped into groups of four in order, with zeros used to fill the last group if there are fewer than four coefficients.

[0205] S302. Based on the polynomial coefficients included in each coefficient group, generate a hash value corresponding to each coefficient group;

[0206] Specifically, for each group of 4 coefficients (a total of 44 bits of information), calculate its SHA-256 hash value.

[0207] S303. For the hash value corresponding to each coefficient group, extract a portion of the hash value to obtain the fingerprint information corresponding to each coefficient group;

[0208] For each coefficient group, the first 16 bits (2 bytes) of the hash value can be taken as the compressed representation of the coefficients (i.e., fingerprint information).

[0209] S304. Concatenate all fingerprint information into a compressed public key.

[0210] The fingerprint information obtained after all groups are compressed is concatenated sequentially to obtain a 64-byte data block, which is the compressed public key. After obtaining the master session key and deriving the sub-session key for the current session (the target device generates the sub-session key in the same way as the gateway device), the target device can use the currently valid sub-session key to encrypt the compressed public key, and then send it to the gateway device through the KNX bus. The gateway device uses the sub-session key to decrypt and obtain the compressed key.

[0211] Step 2: Based on the sub-session key, generate random parameters, and based on the compressed public key, random parameters, and control commands, perform encryption operations using an asymmetric encryption algorithm to obtain the current ciphertext.

[0212] Specifically, based on the sub-session key, random parameters are generated, and based on the compressed public key, random parameters, and control commands, an asymmetric encryption algorithm is used to perform encryption operations to obtain the current ciphertext, including:

[0213] 1. Convert the sub-session key into a random number using a hash function, and then convert the random number into a corresponding random polynomial using a preset rule, using the random polynomial as a random parameter;

[0214] The encryption process requires a randomized blinding polynomial r, whose coefficients also belong to {-1, 0, 1}, with a Hamming weight dr = 72. Specifically, this is based on the sub-session key currently used for encryption. As a random number seed, this seed is input into an expandable output function (e.g., SHAKE-128). From the output stream of the expandable output function, sufficiently long pseudo-random bytes are extracted sequentially, and these bytes are mapped according to specific rules (e.g., rejection sampling) to a random polynomial r with coefficients ranging from {-1, 0, 1} and a Hamming weight of exactly 72. Since... Since the encryption is unique for each time, the generated random polynomial r is also unique for each encryption, ensuring the semantic security of the encryption.

[0215] 2. Convert control commands into message polynomials using the NTRU encryption algorithm;

[0216] Specifically, the single-byte control instruction value Encoded as message polynomial The encoding rule is: generate a A polynomial of degree such that its constant term ( The coefficient is All other terms have a coefficient of 0. That is:

[0217]

[0218] At the same time, it is necessary to ensure The absolute value is less than This satisfies the decryption conditions of the NTRU algorithm.

[0219] 3. Based on the compressed public key, message polynomial, and random parameters, the control command is encrypted using the NTRU encryption algorithm to obtain the current ciphertext; the private key corresponding to the original public key is used to decrypt the current ciphertext to obtain the control command.

[0220] Specifically, using compressed public keys random polynomial and message polynomial The ciphertext polynomial is calculated using the following homomorphic encryption formula:

[0221]

[0222] in, Indicates ring This involves polynomial multiplication (i.e., convolution multiplication) in the domain. In practical applications, since compressed public keys are used, they must first be decompressed or an equivalent polynomial multiplication operation must be designed directly in the compressed domain to recover the result compared to the operation using the original public key. The results are equivalent in operation. After the calculation is complete, the resulting polynomial is... Modulate each coefficient Perform the operation to make it fall within the range The final encrypted polynomial is obtained. It can be encoded into a fixed-length byte string (e.g., 32 bytes, depending on the parameters N and q).

[0223] Verification methods for checking the validity of the current ciphertext include:

[0224] Step 1: Calculate the difference polynomial between the current ciphertext and each pre-stored legitimate ciphertext, where the legitimate ciphertext is obtained by encrypting the legitimate instructions of the target device using a compressed public key;

[0225] Specifically, the first step is to determine the set of legal plaintext commands during the pre-computation phase. Based on the business logic of the target device (such as a curtain controller), the set of all legal control command values ​​it is allowed to accept is determined. Then, the NTRU compressed public key corresponding to the target device is read from storage. Use and obtain the current ciphertext The encryption process uses the exact same algorithm and parameters, iterating through each legitimate instruction value in the set of legitimate plaintext instructions to encrypt it, thus obtaining a set of legitimate ciphertext.

[0226] When the gateway device receives or is about to send the current ciphertext, it performs the following homomorphic verification process:

[0227] For each legitimate ciphertext in the pre-stored set of legitimate ciphertexts Calculate the current ciphertext and Difference polynomial :

[0228]

[0229] This operation is performed on the polynomial ring. This is performed by subtracting the corresponding coefficients of the two polynomials modulo q. According to the additive homomorphic property of the NTRU cryptosystem, if the current ciphertext... It is a legal instruction The result is obtained through encryption, and the random polynomial used in the encryption is: Then the following relationship exists:

[0230]

[0231] at the same time,

[0232]

[0233] The random parameters for calculating the legal ciphertext are used in the pre-computation stage to calculate the legal instructions.

[0234] but:

[0235]

[0236] The difference polynomial The coefficients are entirely determined by the difference between the two random polynomials. Decide. , The coefficients are all small integers, therefore Each coefficient is expected to be a relatively small integer in absolute value.

[0237] Step 2: Calculate the infinite norm of each difference polynomial. The infinite norm is the maximum absolute value of all coefficients in the difference polynomial.

[0238] The infinite norm is defined as the maximum absolute value among all the coefficients of the polynomial.

[0239] Infinite norm The calculation method is as follows:

[0240]

[0241] in, Representing a polynomial middle The coefficient of the term.

[0242] Step 3: If there is an infinite norm less than the preset threshold, determine that the current ciphertext is valid.

[0243] Each calculated infinity norm is compared with a preset threshold. If at least one infinity norm is less than the preset threshold, the current ciphertext is deemed valid. Otherwise, it is deemed invalid. The preset threshold is a value selected based on the NTRU encryption algorithm parameters and security requirements, according to the NTRU algorithm parameters in this embodiment (…). =251, =2048), preset threshold It can be:

[0244]

[0245] This preset threshold ensures that when the current ciphertext is indeed encrypted by a legitimate instruction, the infinite norm of the difference between it and the corresponding pre-stored legitimate ciphertext is highly likely to be less than the threshold; while when the current ciphertext is encrypted by an illegitimate instruction or random data, the infinite norm of the difference between it and any pre-stored legitimate ciphertext is highly likely to be greater than the threshold.

[0246] The above-mentioned scheme for verifying the validity of the current ciphertext has the following technical effects:

[0247] 1. The gateway device does not need to decrypt the current ciphertext during the entire verification process. Therefore, the gateway device never comes into contact with the plaintext content of the control commands, which achieves the separation of privacy protection and security policy execution and complies with the "principle of least knowledge". Even if the gateway device is compromised, attackers cannot directly obtain sensitive control command information from the massive amount of ciphertext flowing through the gateway.

[0248] 2. The core operations of the verification process are polynomial subtraction and finding the maximum value of coefficients, both of which are lightweight operations with low linear complexity. This reduces computational overhead and enables the gateway to complete security checks in real time under high-concurrency instruction streams, thus avoiding becoming a performance bottleneck.

[0249] Optionally, the current ciphertext may be sent to the target device, including:

[0250] Step 1: Concatenate the current ciphertext, the session binding parameters corresponding to the current session, and the address information of the target device into a message to be authenticated;

[0251] In this step, the address information of the target device is the KNX group address to which this control command is to be sent. This is used to bind the message to a specific actuator or actuator group to prevent the command from being redirected to other devices.

[0252] The current ciphertext, the session binding parameters corresponding to the current session, and the address information of the target device are sequentially concatenated into binary to form a complete byte stream of the message to be authenticated. This concatenation operation ensures that the final generated message verification code is strongly associated with the specific ciphertext, the specific encrypted session (identified by a counter), and the specific target device.

[0253] Step 2: Based on the sub-session key, process the message to be authenticated using the message authentication code construction algorithm to generate the first message verification code corresponding to the message to be authenticated;

[0254] This step employs a hash-based message authentication code algorithm. Specifically, HMAC-SHA256 is used as the message authentication code construction algorithm, the sub-session key is used as the key for the HMAC algorithm, and the byte stream of the message to be authenticated obtained in step one is used as the input message for the HMAC algorithm.

[0255] Next, HMAC-SHA256 calculation is performed, outputting a 256-bit (32-byte) hash digest, which is the first message verification code. Since the sub-session key is dynamically generated and may be different for each encryption, even for the same control command and the same target device, the generated first message verification code will be completely different as long as the session counter is different.

[0256] Step 3: Combine the data at the preset byte position of the first message verification code and the message to be authenticated into target information, and send the target information to the target device.

[0257] From the 32-byte first message verification code generated in step two, data at a preset byte position is extracted. For example, the first 8 bytes (64 bits) can be extracted. This length strikes a balance between security strength and transmission overhead, providing sufficient security while significantly reducing bus load.

[0258] The extracted 8-byte verification code data is concatenated with the message to be authenticated from step one to form the final target information. That is: Target Information = (Extracted 8-byte Verification Code) || (Current Ciphertext || Session Binding Parameters || Target Device Address). Here, "||" indicates concatenation. It should be noted that the message to be authenticated at this point already contains the original current ciphertext.

[0259] The gateway device sends the assembled target information data packet to the designated target device via the KNX bus (TP1 or IP medium). Upon receiving the packet, the target device performs the reverse process: first, it extracts the session binding parameters (counter) and the target device address; then, it recalculates the HMAC using the locally stored shared key (or derived sub-session key) and compares it with the received 8-byte verification code to verify the integrity and freshness of the message. Only after successful verification will the control commands in the current ciphertext be executed.

[0260] The above solution has the following technical effects:

[0261] By using the HMAC algorithm with a dynamic sub-session key as the key, a unique and unforgeable authentication tag is generated for each extended instruction. Any tampering with the ciphertext, destination address, or session counter during transmission will cause the receiver to fail to verify, thus ensuring that the instruction is not maliciously modified or forged during transmission.

[0262] Figure 4 This is a schematic flowchart of a KNX system target device instruction execution method provided in an embodiment of this application. The method is applied to a target device in a KNX system, and the target device is communicatively connected to a gateway device. Figure 4 As shown, the method includes:

[0263] S401. Generate a compressed public key based on the NTRU encryption algorithm and send the compressed public key to the gateway device;

[0264] In this step, the method for generating the compressed public key can refer to the aforementioned embodiments.

[0265] S402. Receive the current ciphertext sent by the gateway device. The steps for the gateway device to generate the current ciphertext include: generating a root key based on the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device; generating a master session key based on the root key and the shared key negotiated with the target device; generating a sub-session key based on the master session key and the session binding parameters corresponding to the current session in response to the control command of the current session, wherein the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys of different sessions are different; generating random parameters based on the sub-session key, and performing encryption operations using the NTRU encryption algorithm based on the compressed public key, the random parameters, and the control command to obtain the current ciphertext.

[0266] S403. Decrypt the current ciphertext to obtain control commands and execute them.

[0267] Optionally, the current ciphertext sent by the receiving gateway device includes:

[0268] The gateway device receives target information sent by the gateway device and parses the data at the preset byte position of the first message verification code and the message to be authenticated from the target information. The message to be authenticated includes the current ciphertext, the session binding parameters corresponding to the current session, and the address information of the target device. The first message verification code is generated by the gateway device based on the sub-session key and through the message authentication code construction algorithm to process the message to be authenticated.

[0269] Specifically, the target device needs to continuously monitor the KNX bus. Since the target information sent by the gateway device (i.e., the complete encrypted instruction packet, specifically referring to the target information generated by the gateway device in the aforementioned embodiments) may be fragmented due to its length exceeding the KNXTP1 single-frame payload (14 bytes), the gateway can, for example, divide the target information into multiple consecutive KNX standard data frames for transmission according to an agreed fragmentation protocol (e.g., using the sequence number bit of the APCI field or a custom multi-frame transmission protocol). The target device receives these fragmented frames sequentially and reassembles them in a buffer based on the fragmentation control information (such as sequence number, start / end flags) in the frames, ultimately restoring the complete target information data block.

[0270] The recombined target information has a fixed format, and its structure is: current encrypted connection first message verification code.

[0271] The target device extracts a fixed-length data segment from the beginning of the target information as the current ciphertext, which is 32 bytes long. The fixed-length data (e.g., 8 bytes) immediately following the current ciphertext is parsed into the first message verification code. This verification code is generated by the gateway before transmission, based on the sub-session key and using a message authentication code construction algorithm (specifically HMAC-SHA256), and its first 8 bytes are appended to the ciphertext.

[0272] To enable subsequent verification, the target device needs to locally reconstruct the original authentication message used by the gateway to generate the first message verification code. In this embodiment, the authentication message is composed of the following three parts concatenated in a predetermined order:

[0273] a. Current ciphertext: The 32 bytes of ciphertext data that have just been parsed.

[0274] b. Session binding parameters corresponding to the current session: namely, the synchronous incrementing counter value associated with this communication. This counter is kept synchronized with the gateway device in the key derivation chain.

[0275] c. Target device address information: that is, the KNX group address or physical address to which this control command is to be sent.

[0276] The target device has local ownership of or can determine the two parts of information b and c through context, and therefore can completely assemble the original message for receiving verification.

[0277] And / or, execute control instructions, including:

[0278] Obtain the sub-session key, and based on the sub-session key, process the message to be authenticated using the message authentication code construction algorithm to generate the second message verification code corresponding to the message to be authenticated;

[0279] Compare the data at the preset byte position of the first message verification code with the data at the preset byte position of the second message verification code to see if they are consistent. If they are consistent, perform decryption processing on the current ciphertext to obtain control instructions, and execute the control instructions.

[0280] Specifically, the target device first needs to obtain the same sub-session key used by the gateway device for encrypting and generating the first message verification code. The method of obtaining the key is described in the following embodiment.

[0281] After obtaining the sub-session key, the target device uses the exact same message authentication code construction algorithm and parameters as the gateway. Specifically, the sub-session key is used as the key, and the locally reconstructed message to be authenticated (i.e., the concatenation of the current ciphertext, session binding parameters (counter), and target address) is used as input data to calculate the HMAC (Hash-based Message Authentication Code), which is the second message verification code. In this scheme, the hash function used is SHA-256, i.e., calculating HMAC - SHA256(sub-session key, message to be authenticated). After the calculation is completed, the first 8 bytes of the HMAC result are also extracted.

[0282] Next, the target device compares the data at the preset byte position of the received first message verification code (i.e., the parsed 8-byte MAC) bit by bit with the data at the preset byte position of the second message verification code (i.e., the calculated 8 bytes) that it just calculated locally. If the two are completely identical, it proves that the current ciphertext and associated session binding parameters have not been tampered with during transmission, and that the message was indeed sent by a legitimate gateway holding the same sub-session key, and has not been subjected to a replay attack.

[0283] After the above verification is successful, proceed with the decryption step.

[0284] The target device uses the private key of the NTRU encryption algorithm stored locally to decrypt the current ciphertext (i.e., 32-byte NTRU ciphertext polynomial encoding) and finally recovers the plaintext control command value (a 1-byte data, such as 0x00 representing "off" and 0x01 representing "on").

[0285] The target device's application logic receives the decrypted plaintext instruction value and drives the corresponding hardware actuators (such as relays and motor drivers) to complete the specified physical actions, such as turning lights on and off or adjusting the position of curtains.

[0286] And / or, methods for obtaining the sub-session key, including:

[0287] A master session key is generated based on the root key and the shared key negotiated with the target device; the root key is generated based on the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device.

[0288] Based on the master session key and session binding parameters, a sub-session key is generated in the same way as the gateway device.

[0289] Specifically, during the initialization phase, the target device collaborates with the gateway device to complete bidirectional hardware fingerprint acquisition and key negotiation. The target device itself possesses hardware characteristics (i.e., a second hardware fingerprint). Through secure interaction, the target device and the gateway jointly participate in a key derivation function based on their respective hardware fingerprints and salt values, generating a common root key bound to the hardware of both parties. This root key is also securely stored on the target device's side within its secure element or encrypted storage area.

[0290] During the key negotiation phase, the target device and the gateway execute an ECDH (Elliptic Curve Diffie-Hellman) key negotiation protocol based on steganographic messages. The target device generates its own temporary ECDH private key and receives the public key sent by the gateway device and sends its own public key via a KNX bus steganographic carrier. Subsequently, both parties independently calculate the same shared key using the elliptic curve algorithm.

[0291] Next, the target device uses the shared key obtained in the previous step as the input key material, the root key as the salt, and combines it with the identification information of the current session (such as the lower 16-bit timestamp) to derive a 128-bit master session key through HKDF (a key derivation function based on HMAC, specifically HKDF-SHA256).

[0292] The target device maintains a session binding parameter locally that is strictly synchronized with the gateway. This parameter could be a 32-bit incrementing counter, which is updated after each successful use of a sub-session key. When a control command needs to be processed, the target device uses the currently valid master session key as the key to calculate the HMAC-SHA256 hash of a fixed message (e.g., the string "KNX-SK-RENEW" concatenated with the current session binding parameter). From the HMAC-SHA256 output, the required length of bits (e.g., 128 bits) is extracted to generate the sub-session key used for the current command communication.

[0293] This embodiment also provides an optional method for generating a root key to address minor deviations (bit flips) that may occur in hardware fingerprints due to environmental factors (such as temperature, voltage fluctuations, and device aging), ensuring that the root key generated each time is strictly consistent, thereby guaranteeing the reliability of the security protocol. Figure 5 This is a schematic diagram of the method for generating a root key provided in an embodiment of this application, as shown below. Figure 5 As shown, the method includes:

[0294] S501. Obtain the first verification information corresponding to the first hardware fingerprint information and the second verification information corresponding to the second hardware fingerprint information;

[0295] During the device manufacturing or initialization phase, a corresponding error correction check code is pre-generated for each device's hardware fingerprint, where:

[0296] Generating the first verification information: Within the TEE of the gateway device (such as an Android central control screen), after acquiring the first hardware fingerprint information, it is immediately encoded using a selected Reed-Solomon encoder. This embodiment uses RS(255,223) encoding, which can encode a 223-byte information block into a 255-byte codeword, capable of correcting errors up to 16 bytes. DF_Raw is used as the information bit input to the encoder, and the redundant verification bytes output are the first verification information C1. Similarly, the same RS(255,223) encoder is used to generate the corresponding second verification information C2 for the acquired second hardware fingerprint information.

[0297] S502. Input the first hardware fingerprint information and the first verification information into the Reed-Solomon decoder so that the decoder calibrates the first hardware fingerprint information based on the first verification information to obtain the first calibrated fingerprint information.

[0298] When a root key needs to be generated, the gateway device performs the following operations:

[0299] Re-collect the current first hardware fingerprint information of the gateway device within the TEE (this value may differ slightly from the first collection due to environmental factors). Simultaneously, read the pre-stored first verification information C1 from storage.

[0300] The current first hardware fingerprint information, along with C1, is input into the Reed-Solomon decoder. The decoder runs the RS decoding algorithm (e.g., using the libfec open-source library ported to the embedded platform), using the check information C1 to correct any errors in the current first hardware fingerprint information that may contain errors. If the difference between the current first hardware fingerprint information and the information bits during the original encoding (bit errors) is within the error correction capability of the RS code (16 bytes for RS(255,223), the decoder will be able to completely correct these errors and output the correct first calibration fingerprint information that is completely consistent with the initialization.

[0301] S503. Input the second hardware fingerprint information and the second verification information into the Reed-Solomon decoder so that the decoder calibrates the second hardware fingerprint information based on the second verification information to obtain the second calibrated fingerprint information.

[0302] The implementation principle of this step is the same as that of S502, and you can refer to the implementation of S502 for details.

[0303] S504. The first calibration fingerprint information and the second calibration fingerprint information are concatenated into concatenated fingerprint information. Based on the concatenated fingerprint information, the root key is generated through the key derivation function.

[0304] The first calibration fingerprint information and the second calibration fingerprint information are spliced ​​together in an agreed order to form spliced ​​fingerprint information.

[0305] Next, this concatenated fingerprint information is used as the input key material (IKM), and the unique identifier such as the device serial number is used as the salt value. A fixed information string (info) is also added and input into a standard key derivation function (HKDF-SHA256 in this embodiment). The output of this function is the final, stable and unique device binding root key.

[0306] Figure 5 The method shown has the following technical effects:

[0307] Since the slight fluctuations in the fingerprint information of hardware devices are an inherent characteristic of the physical entropy source, directly using them to derive keys may result in different root keys each time, thus causing the security protocol to fail. This embodiment introduces a Reed-Solomon forward error correction mechanism to effectively "calibrate" each real-time collected fingerprint, which may contain noise, to the initial, consensus-correct value, thereby ensuring the long-term stability and 100% reproducibility of the root key.

[0308] It should be noted that the ChaCha20-Poly1305 algorithm can be used to replace NTRU, which is suitable for scenarios that do not require homomorphic verification but pursue extremely high encryption and decryption speeds and shorter ciphertexts; Chinese national cryptographic algorithms can be fully adopted, with SM2 / SM3 / SM4 replacing ECDH / SHA256 / NTRU, which is suitable for projects with Chinese national cryptographic compliance requirements; and the traditional finite field Diffie-Hellman exchange can be used to replace elliptic curve ECDH, which is suitable for end devices with extremely limited computing power and that do not support elliptic curve operations, but at the cost of slower negotiation speed and larger data volume.

[0309] Figure 6 This is a schematic diagram of a KNX system command encryption device provided in an embodiment of this application. The device 60 is applied to a gateway device, which is communicatively connected to a target device in the KNX system. The device 60 includes:

[0310] The fingerprint acquisition module 601 is used to acquire the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device.

[0311] The encryption module 602 is used to generate a root key based on the first hardware fingerprint information and the second hardware fingerprint information; and to generate a master session key based on the root key and the shared key negotiated with the target device.

[0312] In response to control commands of the current session, a sub-session key is generated based on the master session key and the session binding parameters corresponding to the current session; wherein, the session binding parameters are updated after each generation of a sub-session key so that the sub-session keys of different sessions are different;

[0313] The control commands are encrypted using the sub-session key to obtain the current ciphertext. If the current ciphertext is valid, it is sent to the target device so that the target device can decrypt it, obtain the control commands, and execute them.

[0314] Figure 7 This is a schematic diagram of a KNX system target device instruction execution apparatus provided in an embodiment of this application. The apparatus 70 is applied to a target device in a KNX system, and the target device is communicatively connected to a gateway device. The apparatus 70 includes:

[0315] The compressed public key generation module 701 is used to generate an original public key based on the NTRU encryption algorithm, and then group the polynomial coefficients in the original public key to obtain multiple coefficient groups, each coefficient group including multiple polynomial coefficients.

[0316] Based on the polynomial coefficients included in each coefficient group, generate a hash value corresponding to each coefficient group;

[0317] For each coefficient group, extract a portion of the hash value to obtain the fingerprint information for each coefficient group.

[0318] All fingerprint information is concatenated into a compressed public key, and the compressed public key is sent to the gateway device;

[0319] The receiving module 702 is used to receive the current ciphertext sent by the gateway device. The steps by which the gateway device generates the current ciphertext include: generating a root key based on the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device; generating a master session key based on the root key and a shared key negotiated with the target device; generating a sub-session key based on the master session key and the session binding parameters corresponding to the current session in response to the control command of the current session, wherein the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys of different sessions are different; generating random parameters based on the sub-session key, and performing encryption operations using the NTRU encryption algorithm based on the compressed public key, the random parameters, and the control command to obtain the current ciphertext.

[0320] The decryption module 703 is used to decrypt the current ciphertext to obtain control commands and execute the control commands.

[0321] The apparatus provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0322] Figure 8 A schematic diagram of the structure of the electronic device provided in this application. Figure 8 As shown, the electronic device 80 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the device 80 further includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus 804.

[0323] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0324] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0325] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0326] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0327] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0328] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0329] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0330] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0331] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0332] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0333] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0334] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0335] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0336] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0337] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A KNX system instruction encryption method, characterized in that, The method is applied to a gateway device, which is communicatively connected to a target device in a KNX system. The method includes: Obtain the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device; Based on the first hardware fingerprint information and the second hardware fingerprint information, a root key is generated; and based on the root key and the shared key negotiated with the target device, a master session key is generated. In response to control commands for the current session, a sub-session key is generated based on the master session key and the session binding parameters corresponding to the current session; wherein, the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys for different sessions are different; The control command is encrypted using the sub-session key to obtain the current ciphertext. If the current ciphertext is valid, it is sent to the target device so that the target device can decrypt it to obtain the control command and execute it.

2. The method according to claim 1, characterized in that, The encryption of the control command based on the sub-session key to obtain the current ciphertext includes: To obtain the compressed public key, the target device generates an original public key based on the NTRU encryption algorithm, and then compresses the original public key to obtain the compressed public key. Based on the sub-session key, random parameters are generated, and based on the compressed public key, the random parameters, and the control command, encryption is performed using the NTRU encryption algorithm to obtain the current ciphertext.

3. The method according to claim 2, characterized in that, The process involves generating random parameters based on the sub-session key, and then performing encryption operations using the NTRU encryption algorithm based on the compressed public key, the random parameters, and the control command to obtain the current ciphertext, including: The sub-session key is converted into a random number using a hash function, and the random number is converted into a corresponding random polynomial using a preset rule. The random polynomial is then used as the random parameter. The control command is converted into a message polynomial of the NTRU encryption algorithm; Based on the compressed public key, the message polynomial, and the random parameters, the control command is encrypted using the NTRU encryption algorithm to obtain the current ciphertext; wherein, the private key corresponding to the original public key is used to decrypt the current ciphertext to obtain the control command; And / or, the verification method for whether the current ciphertext is valid includes: Calculate the difference polynomial between the current ciphertext and each pre-stored legitimate ciphertext, wherein the legitimate ciphertext is obtained by encrypting legitimate instructions from the target device using the compressed public key; Calculate the infinite norm of each of the difference polynomials, where the infinite norm is the maximum absolute value of all coefficients in the difference polynomial; If there exists an infinite norm less than a preset threshold, the current ciphertext is determined to be valid.

4. The method according to claim 1, characterized in that, The process of negotiating and generating a shared key with the target device includes: A first temporary key pair is generated on the gateway device side, the first temporary key pair including a first temporary public key and a first temporary private key; The first temporary public key is fragmented and embedded into a predetermined free field of multiple original control messages of the KNX system to obtain a modified control message, which is then sent to the target device as the first message. The target device receives a second message returned by the target device, wherein the target device restores the first temporary public key based on the first message, generates a second temporary public key and a second temporary private key, and fragments the second temporary public key in the same way and embeds it into the predetermined free field of the original control message to obtain the second message; The second temporary public key is restored based on the second message; and the shared key is calculated based on the first temporary private key and the second temporary public key. The predetermined idle field includes at least one of the following: a reserved field for the priority field in the control byte of the original control message; a redundant field for the numerical field used to indicate the control status in the original control message; and a field encoded by modulating the transmission interval of the original control message.

5. The method according to claim 1, characterized in that, The step of obtaining the first hardware fingerprint information of the gateway device includes: Within the trusted execution environment of the gateway device, a first feature acquisition operation is performed, the first feature acquisition operation including: Collect the current actual operating frequency of the central processing unit of the gateway device, and calculate the frequency deviation between the current actual operating frequency and the nominal operating frequency of the central processing unit; In the gateway device, a target memory region is determined in the dynamic random access memory, the charge leakage rate of different memory cells in the target memory region is collected, and a memory cell leakage current mapping feature vector is generated based on the charge leakage rate of the different memory cells. The programming voltage threshold deviation of multiple predetermined physical address storage cells of the embedded storage chip in the gateway device is collected, and a flash memory cell feature vector is generated based on all the programming voltage threshold deviations. The frequency deviation value, the memory cell leakage current mapping feature vector, and the flash memory cell feature vector are concatenated into concatenated feature data, and a secure hash algorithm is performed on the concatenated feature data to obtain the first hardware fingerprint information; And / or, obtaining the second hardware fingerprint information of the target device includes: Perform multiple second feature acquisition operations, the second feature acquisition operations including: Send a request message to the target device, the request message being used to query the status of the target device; Collect response feature information, which includes: the time interval from sending the request message to receiving the response message from the target device; and the waveform transition time between the rising edge and the falling edge in the signal of the response message. The collected response feature information is subjected to discrete wavelet transform, and the second hardware fingerprint information is obtained based on the low-frequency coefficients obtained after the discrete wavelet transform.

6. The method according to any one of claims 1-5, characterized in that, The step of generating a root key based on the first hardware fingerprint information and the second hardware fingerprint information includes: Obtain the first verification information corresponding to the first hardware fingerprint information and the second verification information corresponding to the second hardware fingerprint information; The first hardware fingerprint information and the first verification information are input into the Reed-Solomon decoder so that the decoder calibrates the first hardware fingerprint information based on the first verification information to obtain the first calibrated fingerprint information. The second hardware fingerprint information and the second verification information are input into the Reid-Solomon decoder, so that the decoder calibrates the second hardware fingerprint information based on the second verification information to obtain the second calibrated fingerprint information; The first calibration fingerprint information and the second calibration fingerprint information are concatenated to form a concatenated fingerprint information. Based on the concatenated fingerprint information, the root key is generated through a key derivation function.

7. The method according to claim 1, characterized in that, Sending the current ciphertext to the target device includes: The current ciphertext, the session binding parameters corresponding to the current session, and the address information of the target device are concatenated to form the message to be authenticated. Based on the sub-session key, the message to be authenticated is processed by a message authentication code construction algorithm to generate a first message verification code corresponding to the message to be authenticated; The data at the preset byte position of the first message verification code and the message to be authenticated are combined into target information, and the target information is sent to the target device.

8. A method for executing instructions on a target device in a KNX system, characterized in that, The method is applied to a target device in a KNX system, the target device being communicatively connected to a gateway device, the method comprising: After generating the original public key based on the NTRU encryption algorithm, the polynomial coefficients in the original public key are grouped to obtain multiple coefficient groups, each of which includes multiple polynomial coefficients. Based on the polynomial coefficients included in each coefficient group, generate a hash value corresponding to each coefficient group; For each coefficient group, a portion of the hash value is extracted to obtain the fingerprint information corresponding to each coefficient group. All the fingerprint information is concatenated into a compressed public key, and the compressed public key is sent to the gateway device; The steps for receiving the current ciphertext sent by the gateway device and generating the current ciphertext by the gateway device include: generating a root key based on the first hardware fingerprint information of the gateway device and the second hardware fingerprint information of the target device; generating a master session key based on the root key and a shared key negotiated with the target device; generating a sub-session key based on the master session key and the session binding parameters corresponding to the current session in response to the control command of the current session, wherein the session binding parameters are updated after each generation of the sub-session key so that the sub-session keys of different sessions are different; generating random parameters based on the sub-session key, and performing encryption operations using the NTRU encryption algorithm based on the compressed public key, the random parameters, and the control command to obtain the current ciphertext; The current ciphertext is decrypted to obtain the control command, and the control command is executed.

9. The method according to claim 8, characterized in that, The receipt of the current ciphertext sent by the gateway device includes: The gateway device receives target information sent by the gateway device and parses data at a preset byte position of the first message verification code and a message to be authenticated from the target information. The message to be authenticated includes the current ciphertext, session binding parameters corresponding to the current session, and the address information of the target device. The first message verification code is generated by the gateway device based on the sub-session key and by processing the message to be authenticated through a message authentication code construction algorithm. And / or, executing the control command includes: Obtain the sub-session key, and based on the sub-session key, process the message to be authenticated using the message authentication code construction algorithm to generate a second message verification code corresponding to the message to be authenticated; Compare the data at the preset byte position of the first message verification code and the data at the preset byte position of the second message verification code to see if they are consistent. If they are consistent, perform decryption processing on the current ciphertext to obtain the control instruction, and execute the control instruction.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7, or to implement the method as described in claim 8 or 9.

Images