A zero trust local area network device discovery and automatic reconnection method and system

Abstract

The application discloses a zero-trust local area network device discovery and automatic reconnection method and system. After a first device completes a security handshake for the first time, the first device generates a secure random pairing token and only issues the pairing token to a second device through an encrypted channel; the first device announces an address in response to a multicast during a pairing window period, and the announcement content only carries a hash truncated value of the pairing token and does not carry the token itself; after disconnection, the second device multicasts a query, compares the hash truncated value with a local value in constant time, reconnects with a new address and re-hands if the values match, and falls back to manual input if there is no match in the guard window; the token is invalidated with the end of a session. Under the premise of zero trust that an attacker can hear, answer and forge, the automatic reconnection is achieved without manual intervention, the broadcast does not disclose secrets, and an attacker cannot impersonate the opposite end; same link verification, speed limiting, whitelist consumption and pointer loop detection make the discovery layer resistant to flooding, anti-reflection amplification and anti-teratogenic packets.

Description

Technical Field

[0001] This invention relates to the field of local area network (LAN) device discovery and secure access technology, specifically to a zero-trust LAN device discovery and automatic reconnection method and system, applicable to mutual discovery and automatic reconnection after disconnection of two terminal devices in a local network link without a central server or internet dependence. Background Technology

[0002] Automatic device discovery within a local area network (LAN) typically employs link-local multicast protocols such as multicast DNS (mDNS): devices announce their service type, port, and address via multicast, and peers retrieve this information through multicast queries. The design premise of such protocols is that "discovery layer information is trustworthy," and the announcements are broadcast in plaintext, allowing any device on the same network segment to listen.

[0003] Applying the above discovery mechanism to secure transmission applications presents significant security risks: when a device roams and changes its address within a local area network, it needs to re-discover the peer. If automatic reconnection is relied upon, attackers on the same network segment can eavesdrop and forge responses, impersonating the peer device to induce the reconnecting party to connect to themselves, thereby carrying out phishing, traffic hijacking, or denial-of-service attacks. Existing technologies address these issues in two main ways: first, by introducing additional encryption or signature mechanisms at the discovery layer, but this makes a "trusted discovery layer" a new assumption, introducing complex issues such as certificate distribution and key management, and multicast discovery does not have this convention; second, by requiring users to manually re-enter the peer address, sacrificing the continuity of use in roaming scenarios.

[0004] In addition, when the multicast discovery protocol is implemented on the public network, it is also at risk of being used as an amplifier for reflection amplification attacks, as well as engineering security issues such as malformed packets causing the parser to crash and display injection.

[0005] Therefore, a device discovery and automatic reconnection scheme that neither trusts the discovery layer itself nor increases manual operation is needed. Summary of the Invention

[0006] Technical problems to be solved

[0007] 1. Under the zero-trust premise that "attackers on the same network segment can eavesdrop, respond, and forge messages", achieve automatic reconnection after roaming and address changing, and prevent attackers from inducing the reconnecting party to connect to the wrong peer.

[0008] 2. Discovery layer broadcasts do not reveal any secret information that could be used to impersonate the other party;

[0009] 3. The discovery layer itself possesses engineering robustness against flooding, reflection amplification, and malformed messages.

[0010] Technical solution

[0011] A zero-trust LAN device discovery and automatic reconnection method, applied to a first device and a second device, includes:

[0012] Pairing token issuance steps: After the first device and the second device establish a connection for the first time and complete a secure handshake and establish an encrypted channel, the first device generates a secure random pairing token and sends the pairing token to the second device only through the encrypted channel; the pairing token does not appear in any plaintext messages or broadcast messages.

[0013] Controlled announcement steps: During the pairing window, the first device responds to multicast queries for the agreed service type by announcing its own address and port in a multicast response manner. The announcement content only carries the hash truncated value of the pairing token, without carrying the pairing token itself. Outside the pairing window, the first device remains silent to the multicast queries.

[0014] The rediscovery matching step: After the connection between the first device and the second device is lost, if the second device fails to reconnect using the cached address, it sends a multicast query to the agreed service type, collects multicast responses, extracts the hash truncation value declared in each response, and compares it with the hash truncation value of the pairing token stored locally; if the comparison matches, it reconnects to the first device using the address declared in the response; if there is no matching item in the preset guard window, it falls back to the connection method of manually entering the address.

[0015] Token invalidation procedure: The lifespan of the pairing token is limited to one transmission session, and the pairing token is invalidated after the session ends.

[0016] Preferably, the hash truncation value is the hexadecimal encoding of the first 16 bytes after performing SHA-256 hash on the paired token; the comparison adopts constant-time comparison to prevent timing side-channeling.

[0017] Preferably, both the declaration and the query are implemented through multicast DNS messages, and the following anti-abuse checks are performed: only responding to messages on the same link with an Internet Protocol Time-to-Live (IPL) field of 255; only responding to messages whose source port is a multicast DNS convention port and has query semantics; rate limiting of declaration responses; and deduplication by service instance name at the discovery end, with new responses for the same instance overwriting old records and using the latest address as the standard.

[0018] Preferably, the message parsing performs the following security checks: message length limit check, domain name compression pointer loop detection and back pointer check, tag length and full name length check; text key values ​​in the declaration content are consumed using a whitelist, and instance names are escaped and truncated before being displayed.

[0019] Preferably, after the first device roams and changes its address, it first sends a farewell announcement with a time-to-live of zero, and then re-announces the address with the new address.

[0020] Preferably, the trust of the automatic reconnection is anchored at the secure handshake layer: even if the reconnecting party connects to the wrong peer, the peer cannot obtain any data because it does not hold the session password and key material and therefore cannot pass the secure handshake.

[0021] Beneficial effects

[0022] 1. Zero-trust automatic reconnection: Attackers cannot calculate the matching hash truncation value without knowing the matching token, and cannot induce the reconnecting party to connect to themselves; even if a collision occurs by chance, no data can be obtained because a secure handshake cannot be passed - automatic reconnection remains secure under the threat model of "being able to listen, being able to answer, and being able to forge".

[0023] 2. Zero secret leakage in broadcasts: Only hash truncation values ​​appear in multicast broadcasts, making it impossible to deduce pairing tokens; completely silent outside the pairing window, reducing device exposure.

[0024] 3. No trust assumptions are introduced at the discovery layer: No need to configure certificates or encryption for the discovery layer, avoiding the complexity of key management, and all trust is anchored to the existing secure handshake layer;

[0025] 4. Robustness: Measures such as link verification, rate limiting, whitelist consumption, and compressed pointer loop detection enable the discovery layer to resist flooding, reflection amplification, and malformed packets; the protocol uses local multicast on the link and does not physically leave the router, making it naturally compatible with isolated scenarios of "no cloud access, no internet access";

[0026] 5. Continuous Experience: Reconnection in roaming and address-changing scenarios requires no manual intervention. If a failure is detected, it automatically reverts to manually entering the address, ensuring an uninterrupted experience. Attached Figure Description

[0027] Figure 1 is a timing diagram of the issuance of the pairing token and the controlled declaration;

[0028] Figure 2 is a flowchart of the automatic reconnection process based on disconnection rediscovery and hash matching;

[0029] Figure 3 is a schematic diagram of the anti-abuse verification chain. Detailed Implementation

[0030] The following example uses two mobile terminals running the E2EFort application (the sending end is the first device, and the receiving end is the second device) to illustrate the process.

[0031] Service type and declaration content. The service type is `_sptp._tcp.local`, and the instance name is "E2EFort-" followed by 4 random hexadecimal characters (for demonstration purposes only). The declaration records include: a PTR record pointing to the service instance; an SRV record carrying the port and hostname; an A record carrying the current IPv4 address; and a TXT record carrying only two key-value pairs—the protocol version number and the token hash truncation value th.

[0032] The pairing token lifecycle (see Figure 1 for the token issuance and controlled announcement sequence). After the initial secure handshake (SM2 temporary key pair exchange + dynamic password authentication) establishes the encrypted control channel, the sender generates a 16-byte secure random token, `pair_token`, which is delivered to the receiver via the file list response extension field of the encrypted control channel. Within the pairing window, the sender announces the first 16 bytes (32 characters) of the hexadecimal encoding of `th = SHA-256(pair_token)`. The token is invalidated upon session termination (success, failure, or guard window exhaustion); the token and transmission progress status disappear together when the process restarts.

[0033] The declaration side implements anti-abuse measures (see Figure 3 for the anti-abuse verification chain). The declaration thread listens on port 5353: Packet reception verification checks the IP TTL field to be 255 (if the platform cannot obtain the TTL, it will allow the packet through token hashing and the handshake layer as a fallback); the source port must be 5353; the packet must be query semantic (QR=0); a response is only given when querying a PTR record for the agreed service type; the interval between two responses must be no less than 1 second. Strict packet parsing verification is implemented: packet length does not exceed 9000 bytes; domain name compression pointer jumps do not exceed 32 times and must point back; the tag does not exceed 63 bytes, and the full name does not exceed 255 bytes; packets exceeding these limits are discarded.

[0034] Rediscovery and Matching (see Figure 2 for the disconnection rediscovery and automatic reconnection process). If the receiving end fails to reconnect to the cached address after disconnection, it enters the rediscovery phase: every 2 seconds, it sends a PTR multicast query for the agreed service type (without setting a unicast response bit, only receiving multicast responses), continuously listening within the guard window (default 10 seconds); after performing TTL=255 verification and source port check on the response, it assembles packets according to PTR / SRV / A / TXT, deduplicating by instance name (new responses overwrite old records, using the latest address), extracting the th value and comparing it with the locally cached token hash truncation value over a constant time; if a match is found, it connects to the address and port of the response and enters a complete security handshake (new temporary key pair, new session random number, new time anchor). If the guard window expires and no match is found, a clear error is reported and it falls back to the manually entered address.

[0035] Roaming handling. When the sending end detects an address change, it first sends a farewell declaration with TTL=0 to invalidate the old record, and then re-declare the record with the new address; the receiving end uses the latest response.

[0036] Degradation Boundaries. Multicast is inherently unavailable in cross-subnet (routing isolation) scenarios. Handle the issue by manually entering the address after the guard window is exhausted. In public, untrusted Wi-Fi environments, manual entry is recommended as the default, with automatic discovery as a supplement.

[0037] Coexistence with online declaration mode. In this embodiment, silence outside the pairing window period means not declaring any information associated with the pairing token. The device can simultaneously provide an online declaration mode without secret materials: while the user is online, it responds to multicast queries with the same agreed service type, and the declaration content only contains the pattern tag and device display identity (device identifier and device display name), without the pairing token and its hash truncation value; the browsing party consumes only the pattern tag and display identity fields according to the whitelist, and the pairing declaration carrying the hash truncation value is skipped because it does not contain the pattern tag, and the two declaration semantics do not interfere with each other. The online declaration mode also performs anti-abuse measures such as same-link verification, query semantic verification, response rate limiting, and text key-value whitelist consumption.

[0038] Constant-time comparison implementation. After XORing and accumulating each character, it checks if the result is zero. If the lengths are unequal, the comparison fails directly. The comparison time does not change with the length of the matching prefix, preventing leakage of hash value prefix information by the timing side channel.

[0039] The above embodiments are only used to illustrate the present invention. Parameters such as hash algorithm, truncation length, rate limiting interval, and guard window duration can be adjusted without departing from the concept of the present invention.

Claims

1. A method for zero-trust local area network device discovery and automatic reconnection, characterized in that, The method, applied to a first device and a second device communicating via a link-local network, includes: a pairing token issuance step: after the first device and the second device establish a connection for the first time and complete a secure handshake and establish an encrypted channel, the first device generates a secure random pairing token and sends the pairing token to the second device only through the encrypted channel; the pairing token does not appear in any plaintext or broadcast messages; a controlled announcement step: during the pairing window period, the first device responds to multicast queries for a specified service type, announcing its own address and port in a multicast response manner, with the announcement content carrying only the hash truncated value of the pairing token and not the pairing token itself; outside the pairing window period, The first device remains silent in response to the multicast query; the rediscovery matching step: after the connection between the first device and the second device is broken, if the second device fails to reconnect with the cached address, it sends a multicast query to the agreed service type and collects multicast responses, extracts the hash truncation value declared in each response, and compares it with the hash truncation value of the pairing token stored locally; if the comparison matches, it reconnects to the first device with the address and port declared in the response and re-executes the security handshake; if there is no matching response within the preset guard window, it falls back to the connection method of manually entering the address; the token invalidation step: the lifespan of the pairing token is limited to one transmission session, and the pairing token is invalidated after the session ends.

2. The method according to claim 1, characterized in that, The hash truncation value is the encoded value of the first preset number of bytes after performing a hash operation on the paired token; the comparison is a constant-time comparison, and the comparison time does not change with the length of the matching prefix.

3. The method according to claim 1, characterized in that, The multicast query and multicast response are implemented based on multicast DNS messages, and the controlled announcement step and rediscovery matching step perform anti-abuse verification: only messages on the same link with an Internet Protocol Time-to-Live (IPL) field of 255 are processed; only messages whose source port is a multicast DNS convention port and have query semantics are responded to; and responses are rate-limited according to a preset minimum interval.

4. The method according to claim 3, characterized in that, The resolution of multicast DNS messages performs the following security checks: message length limit check; domain name compression pointer jump limit check and the pointer must point back; tag length and full name length limit check; If any verification fails, the message is discarded.

5. The method according to claim 3, characterized in that, The text key-value pairs in the announcement are consumed according to a whitelist, which contains only the protocol version number and the hash truncation value; the service instance name is only used for display and is escaped and truncated before display.

6. The method according to claim 1, characterized in that, In the rediscovery matching step, the second device deduplicates the collected responses according to the service instance name, and the new response of the same service instance overwrites the old record and takes the latest declared address as the standard.

7. The method according to claim 1, characterized in that, After the first device roams and changes its address, it first sends a farewell announcement with a time-to-live of zero, and then re-announces the address with the new address.

8. The method according to claim 1, characterized in that, The secure handshake employs a one-time temporary key pair exchange and dynamic password authentication; after the second device reconnects, it performs a full secure handshake, preventing the peer holding incorrect key materials from passing authentication.

9. A zero-trust local area network device discovery and automatic reconnection system, characterized in that, The system includes a first device and a second device. The first device includes: a token generation module configured to generate a secure and random pairing token after establishing an encrypted channel with the second device, and to distribute it only through the encrypted channel; and an announcement module configured to respond to multicast queries for a specified service type during the pairing window period, announcing its own address and port with a multicast response, the announcement content carrying only the hash truncation value of the pairing token, and remaining silent outside the pairing window period. The second device includes: a token storage module configured to receive and store the pairing token through the encrypted channel; and a rediscovery module configured to, when the connection is broken and reconnection with the cached address fails, send a multicast query, collect multicast responses, extract the hash truncation value from the response and compare it with the hash truncation value of the local pairing token, and if the comparison matches, reconnect to the first device with the address announced by the response, and if there is no match within the guard window, revert to the manual address input method.

10. An electronic device, characterized in that, The method includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the first device side and / or the second device side in the method of any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the first device side and / or the second device side in the method of any one of claims 1 to 8.

Images