Local Large Language Model Sharing Apparatus and Method Based on Network Service Discovery with Device Identifier-Derived Per-User Key Isolation

Abstract

The present invention relates to a local large-scale language model sharing device and method based on network service discovery having user-specific key isolation based on a device identifier. The device according to the present invention comprises: an ad transmission unit that transmits an ad payload through a first communication channel, the ad payload including metadata regarding LLM inference capability and an authentication method identifier representing a client identification-based key setting method; an authentication verification unit that verifies the validity of client identification information or device-combined authentication information received from a client device; a security processing unit that manages a host master key in a hardware security area; a key derivation module that generates a client-specific session key by performing a key derivation operation in conjunction with the security processing unit, wherein the host master key and the validated client identification information or device-combined authentication information are input values, and performs the key derivation operation such that at least the plaintext of the host master key is not exposed outside the hardware security area; a context storage unit that protects or isolates LLM inference context data by client using a client-specific session key or a subkey derived from a client-specific session key; and a channel control unit that transmits an LLM inference response to the client device through a second communication channel that is distinct from the first communication channel used for transmitting the ad payload.

Description

Technology Field

[0001] The present invention relates to a network service discovery-based local large-scale language model sharing device and method having device identifier-based user-specific key isolation. Background Technology

[0002] Recently, local Large Language Model (LLM) inference servers are becoming widespread in home, small office, and vehicle environments. These local LLM inference hosts feature lower communication latency compared to cloud LLM services, do not transmit user data externally, and can operate even in environments disconnected from the internet.

[0003] However, conventional local LLM inference hosts have the following problems.

[0004] First, there is the burden of manual connection configuration. It is assumed that the client must know the host's IP address, TCP / UDP port number, loaded LLM model identifier, and context window size in advance and manually enter them or register them via a separate configuration file. This acts as a practical barrier for non-technical users in home environments, public environments where multiple people stay for short periods, and scenarios where portable devices move between multiple network environments.

[0005] Second, there is a lack of a standardized automatic discovery mechanism for multi-user sharing. Existing network service discovery standards, such as Apple Bonjour, Microsoft WS-Discovery, and UPnP’s SSDP, define service types for the automatic discovery of printers, media renderers, IoT devices, etc., but they do not define standardized service types or data schemas for advertising LLM inference capabilities—namely, loaded model identifiers, context window size, token throughput, domain tags, and load metrics.

[0006] Third, there is a risk of inference context leakage between users. When a single LLM host is shared by multiple users, there is a risk that the KV-cache, user-specific audit logs, system prompts, etc., may be unintentionally exposed among users. In particular, key isolation mechanisms that block plaintext access to other users' inference contexts, even for those holding host administrator privileges, are generally not provided in conventional local LLM servers.

[0007] Fourth, there is a lack of device-level authentication and key derivation mechanisms. Conventional LLM service authentication typically adopts authentication based on pre-issued API keys or user account passwords. However, since API keys are not tied to a client device, the same API key can be used on multiple devices and is not combined with device-level attestation. Consequently, the combination in which the LLM host attests the client's device unique identifier and derives a user-specific key using that attested identifier as input is absent in conventional LLM host authentication models.

[0008] Fifth, there are discovery limitations in environments where Wi-Fi multicast is unavailable and in heterogeneous network environments. In environments where Wi-Fi multicast is blocked (hospitals, factories, public wireless LANs, cellular environments, etc.) or where clients and hosts are located in different VLANs or IP subnets, mDNS multicast advertisements do not reach. Furthermore, there is no standardized mechanism for discovering LLM hosts in mobile scenarios where only BLE is available.

[0009] Sixth, there is a bandwidth dependency issue between the discovery channel and the data transmission channel. If the channel used for device discovery and the channel delivering the actual LLM inference response are not separated, the narrow bandwidth of the discovery channel directly affects token streaming performance. A channel separation structure that allows the advertising policy of the discovery phase and the encryption and transmission policy of the token stream phase to be applied independently is not provided by conventional local LLM servers.

[0010] Meanwhile, network service discovery, device assertion, key derivation function, data encryption, and multiple communication channels are each known independently. However, in the prior art, a series of session establishment structures were not provided that determine the client assertion procedure based on the authentication method identifier included in the ad payload, make the successful verification of the assertion a prerequisite for the generation of a client-specific session key, and link the generated session key or its subkey to both the protection of the LLM inference context and the protection of the inference response channel. Furthermore, a linkage structure was not provided to ensure that the isolation of the inference context is maintained by the same client-specific key hierarchy even when the physical media of the search / pairing channel and the token stream channel are changed. The problem to be solved

[0011] Accordingly, the technical problem that the present invention aims to solve is to provide an LLM sharing device and a method thereof, which can discover an LLM inference host without manual configuration in a network service discovery-based environment, protect or isolate LLM inference context data on a client-by-client basis using a client-specific session key generated based on client identification information or device combination authentication information, and provide an LLM inference response through a second communication channel that is distinct from a first communication channel used for transmitting an advertisement payload. means of solving the problem

[0012] An LLM sharing device according to the present invention for solving the aforementioned technical problem is an LLM sharing device that provides a Large Language Model (LLM) inference service based on Network Service Discovery (NSD) to one or more client devices, comprising: an ad transmission unit that transmits an ad payload through a first communication channel, the ad payload including metadata regarding LLM inference capability and an authentication method identifier representing a client identification-based key setting method; an authentication verification unit that verifies the validity of client identification information or device-linked authentication information received from the client device; a security processing unit that manages a host master key in a hardware security area; a key derivation module that generates a client-specific session key by performing a key derivation operation including the host master key and the validated client identification information or device-linked authentication information as input values ​​in conjunction with the security processing unit, wherein at least the plaintext of the host master key is not exposed outside the hardware security area; a context storage unit that protects or isolates LLM inference context data for each client using the client-specific session key or a subkey derived from the client-specific session key; and an LLM through a second communication channel distinguished from the first communication channel used for transmitting the ad payload. It includes a channel control unit that transmits an inference response to the client device.

[0013] An LLM sharing method according to the present invention for solving the aforementioned technical problem comprises: a step of transmitting an advertisement payload through a first communication channel, the advertisement payload including metadata regarding LLM inference capability and an authentication method identifier representing a client identification-based key setting method; a step of verifying the validity of client identification information or device-linked authentication information received from a client device; a step of generating a client-specific session key by performing a key derivation operation including a host master key managed in a hardware security area and the validated client identification information or device-linked authentication information as input values, wherein the key derivation operation is performed such that at least the plaintext of the host master key is not exposed outside the hardware security area; a step of protecting or isolating LLM inference context data for each client using the client-specific session key or a subkey derived therefrom; and a step of transmitting an LLM inference response to the client device through a second communication channel distinct from the first communication channel used for transmitting the advertisement payload. Effects of the invention

[0014] According to the present invention, a client device can automatically discover LLM inference capabilities and authentication methods through an ad payload without manually configuring the IP address, port number, or loading model information of a host device in advance. Furthermore, even when multiple hosts exist, a suitable host can be selected based on load indicators, model matching, and communication status, thereby enabling easier and more efficient sharing of LLM inference services in a local network environment.

[0015] Furthermore, the present invention derives a client-specific session key based on a verified device unique identifier and a host master key within a security processing unit, and uses this to cryptographically isolate the KV-cache, audit log, and response channel on a client-by-client basis. Accordingly, even when multiple users share a single LLM host, the exposure of inference context between users can be prevented, and by separating the discovery / pairing channel from the token stream channel, stable discovery and response streaming can be provided even in Wi-Fi multicast restricted environments or BLE-based environments. Brief explanation of the drawing

[0016] FIG. 1 is a block diagram showing the overall configuration of an NSD-based LLM sharing system according to one embodiment of the present invention. FIG. 2 is a block diagram showing the internal configuration of a host device according to one embodiment of the present invention in more detail. FIG. 3 is a block diagram showing the internal configuration of a client device according to one embodiment of the present invention in more detail. FIG. 4 is a sequence diagram showing the discovery, appraisal, and session establishment process according to one embodiment of the present invention. FIG. 5 is a diagram showing the key hierarchy of device unique identifier-based key derivation and subkey expansion according to one embodiment of the present invention. FIG. 6 is a diagram showing the configuration of an advertisement payload according to one embodiment of the present invention. FIG. 7 is a diagram showing the separation structure of a search / pairing channel and a token stream channel according to an embodiment of the present invention. FIG. 8 is a diagram showing a context isolation structure for simultaneous multi-client access according to an embodiment of the present invention. FIG. 9 is a flowchart illustrating the discovery, pairing, and token stream processing process in a BLE standalone environment according to one embodiment of the present invention. Specific details for implementing the invention

[0017] Then, with reference to the attached drawings, embodiments of the present invention will be described in detail so that those skilled in the art can easily implement the present invention.

[0018] The terms used herein are for describing the embodiments and are not intended to limit the invention. In this specification, the singular form includes the plural form unless specifically stated otherwise in the text. The terms “comprises” and / or “comprising” as used in this specification do not exclude the presence or addition of one or more other components in addition to the components mentioned. Throughout the specification, the same reference numerals refer to the same components, and “and / or” includes each of the mentioned components and all combinations of one or more. Although terms such as “first,” “second,” etc., are used to describe various components, these components are not limited by these terms. These terms are used merely to distinguish one component from another.

[0019] FIG. 1 is a block diagram showing the overall configuration of an NSD-based LLM sharing system according to one embodiment of the present invention.

[0020] Referring to FIG. 1, an NSD-based LLM sharing system according to one embodiment of the present invention may include a host device (100), at least one client device (200), and a local network (300) connecting the host device (100) and the client device (200). In this case, the host device (100) generates and transmits an advertisement payload, and a key layer (500) may be configured within the host device (100).

[0021] A host device (100) is an LLM sharing device according to the present invention, and can transmit an advertisement payload including LLM inference metadata and an authentication method identifier to a search / pairing channel (310), receive and verify an attribute for a device unique identifier from a client device (200), derive a client-specific session key (520) by an HMAC-based key derivation function (HKDF, RFC 5869), and transmit an LLM inference response through a token stream channel (320). Here, LLM (Large Language Model) refers to a large language model that generates a natural language output or a token sequence output equivalent thereto for a natural language input based on a Transformer or an equivalent neural network architecture, and includes a general term for a model that uses a KV-cache that caches key and value tensor values, which are intermediate results of attention operations in the inference stage, in token units.

[0022] The host device (100) can be implemented as a computing device. Here, "computing device" includes all various devices capable of performing computational processing and providing results to a user. For example, a computing device may be a device that achieves desired system performance by utilizing a combination of computing hardware devices (e.g., a device that may include a computer processor, memory, storage, input and output devices, and other components of an existing computing device) and computer software (i.e., instructions that cause the computing device to function in a specific way), such as a desktop PC, a laptop computer, a server computer, as well as a mini PC and a vehicle computing terminal. According to one embodiment, the host device (100) may be implemented in the form of a desktop inference server for home or small office use, an in-house inference server, or a portable mini PC, and it is also possible to implement it by integrating the components according to the present invention as software modules into an existing LLM inference server software stack.

[0023] The client device (200) may be any computing terminal capable of storing and attesting a device unique identifier in a form bound to the device, such as a smartphone, laptop, tablet, or IoT terminal. Here, the term "Device Identifier" (hereinafter DID) refers to an identifier that is bound to the client device (200) and can be attested in a way that prevents tampering, and the term "attestation" refers to a mechanism that proves that the device unique identifier has not been tampered with by a signature in the device's security area or an equivalent trust area. In this specification, the terms "client identification information" or "device-bound authentication information" refer to information provided by being bound to the client device to identify or authenticate the client device or its user, and may include a device unique identifier, a device-bound public key, a certificate, attestation information signed by a security area, passkey-based authentication information, a TPM Quote, or equivalent authentication information.

[0024] The local network (300) may be implemented using one or more combinations of media such as Wi-Fi (IEEE 802.11 series), Ethernet, Bluetooth Low Energy (hereinafter BLE), Ultra-Wideband (UWB), USB, Thunderbolt, PCIe over USB4. The search / pairing channel (310) and the token stream channel (320) are separated into distinct logical channels that can be mapped to the same medium or different media. According to one embodiment, in an environment where the client device (200) and the host device (100) are located in different VLANs or IP subnets, discovery relay by a Discovery Proxy (330) defined in RFC 8766 may be additionally utilized, and the guarantee of authenticity of the advertisement payload itself may be supplemented by DNSSEC or a combination of optional verification information described later.

[0025] The ad payload may be transmitted simultaneously in either or both formats of mDNS / DNS-SD TXT records and BLE GATT ad data, and may further include optional verification information depending on one embodiment.

[0026] The key layer (500) may include a host master key (510) generated and stored within the security processing unit (130), a client-specific session key (520) derived from it via HKDF, and four types of subkeys derived from the client-specific session key (520) via HKDF-Expand: an inference context encryption key (530), an audit log encryption key (540), a response channel encryption key (550), and a session token signature key (560).

[0027] The detailed internal configuration of the host device (100) and the client device (200) will be described later with reference to FIG. 2 and FIG. 3, respectively.

[0028] FIG. 2 is a block diagram showing the internal configuration of a host device according to one embodiment of the present invention in more detail.

[0029] Referring to FIG. 2, a host device (100) according to one embodiment of the present invention may include an advertisement transmission unit (110), an attribute verification unit (120), a security processing unit (130), a key derivation module (140), an LLM inference runtime (150), a context storage unit (160), and a channel control unit (180).

[0030] The ad delivery unit (110) can perform the function of delivering LLM inference metadata, including a model identifier, context window size, token throughput, domain tag, load metric, and authentication method identifier, to the search and pairing channel (310) by including it in the ad payload. According to one embodiment, the ad delivery unit (110) may include an mDNS / DNS-SD Advertiser (110a), a BLE GATT Advertiser (110b), a TXT record configuration unit (110c), and a GATT Characteristic configuration unit (110d).

[0031] The mDNS / DNS-SD Advertiser (110a) can transmit PTR / SRV / TXT records of service types for LLM inference via UDP 5353 multicast. According to one embodiment, the mDNS / DNS-SD Advertiser (110a) can transmit separate subtypes for each function class of LLM by utilizing the DNS-SD subtype mechanism. For example, by transmitting a subtype corresponding to chat completion capability, a subtype corresponding to embedding capability, and a subtype corresponding to reranking capability, it is possible to implement a system whereby the client device (200) can query only the subtype of the required function class to narrow down the matching hosts.

[0032] The BLE GATT Advertiser (110b) can include a 128-bit custom service UUID in the advertisement header and transmit core metadata in a bitfield compressed format of 25 bytes or less in the Manufacturer Specific Data area, and according to one embodiment, the LE Coded PHY 125 kbps option of BLE 5.0 or higher can be used.

[0033] The TXT record composition unit (110c) can serialize key-value pairs and compress them so that the total number of bytes is about 200 bytes or less.

[0034] The GATT Characteristic configuration part (110d) can define four characteristics within the GATT service: CAP_CHAR, DISCO_CHAR, ATTEST_CHAR, and STREAM_CHAR.

[0035] According to one embodiment, the advertisement transmission unit (110) can simultaneously operate the mDNS / DNS-SD Advertiser (110a) and the BLE GATT Advertiser (110b) to transmit the same metadata in both formats, thereby forming a fallback structure in which mDNS is prioritized in a Wi-Fi-available environment and BLE is prioritized in an environment where only BLE is available.

[0036] According to one embodiment, the load metric included in the ad payload can be calculated by the formula load = (active_streams × avg_tok_per_s) / (max_streams × max_tok_per_s). Here, active_streams may represent the number of currently active inference streams, avg_tok_per_s may represent the average token processing speed of the active streams, max_streams may represent the maximum number of streams that the host can process simultaneously, and max_tok_per_s may represent the maximum token processing speed of the host. The calculated load metric is updated at a predetermined update cycle—e.g., a range of 1 second to 5 seconds—and can be transmitted via the TTL rotation of mDNS or the update of BLE ads. From this, the client side can recognize the load status of the host during the discovery phase, thereby enabling load balancing within the discovery plane itself.

[0037] According to one embodiment, the advertisement transmission unit (110) may transmit by including signature data calculated by a key within the security processing unit (130) in the advertisement payload. Since mDNS / DNS-SD is unauthenticated by design, there is no standardized mechanism for the receiving side to verify the authenticity of the advertisement payload transmitted via multicast (see RFC 8882), so if the discovery results are trusted as is, it may be exposed to attacks caused by advertisement forgery or advertisement interception. In this embodiment, the client device (200) can verify the authenticity of the host device (100) and the integrity of the advertisement payload at the advertisement reception stage by verifying the signature data. At this time, the signature data does not need to be loaded in the Manufacturer Specific Data area of ​​the BLE advertisement, and can be provided to the client device (200) through a capability lookup channel such as an mDNS TXT record or a CAP_CHAR Read response described later.

[0038] The attest verification unit (120) can perform the function of verifying the authenticity of an attest for a device unique identifier received from a client device (200). According to one embodiment, the attest verification unit (120) receives an attest payload, such as an X.509 certificate chain or an attest key signature, and can verify the integrity and issuer trust according to any one of the following mechanisms: Android Key Attestation, iOS DeviceCheck App Attest, Apple App Attestation, TPM 2.0 Quote, WebAuthn passkey attestation, or any other mechanism that attests the device unique identifier. The root trust point of the certificate chain required for verification may be stored in advance in the trust store of the host device (100). If verification fails, the derivation of a client-specific session key (520) by the key derivation module (140) is not performed, and a rejection response may be sent to the client device (200).

[0039] The security processing unit (130) can generate and store the host master key (510) within a physically isolated hardware security area and perform at least a portion of the key derivation function operations of the key derivation module (140) internally. According to one embodiment, the security processing unit (130) may be composed of any one of a Trusted Execution Environment (TEE) separated by ARM TrustZone, a Secure Element, a Trusted Platform Module (TPM) 2.0, a virtualized TPM (vTPM), or other components having security processing functions. The host master key (510) may be generated by a hardware random number generator within the security processing unit (130) and sealed and stored in an internal non-volatile storage (e.g., a sealed storage of the TPM, a secure NVRAM of the Secure Element, a secure storage of the TEE), and its plaintext may not be exposed to memory and disk in the operating system user area of ​​the host device (100).

[0040] The key derivation module (140) can perform the function of deriving a client-specific session key (K_user, 520) by HKDF (RFC 5869) using the host master key (510) inside the security processing unit (130), the device unique identifier verified by the authentication verification unit (120), and a session random number as inputs. HKDF is a standard key derivation function consisting of two stages, an Extract stage and an Expand stage. In one embodiment, SHA-256 may be adopted as the hash function, and it is also possible to replace it with SHA-384, SHA-512, or a hash function having a security strength equivalent to or greater than that.

[0041] According to one embodiment, an HKDF input for deriving a client-specific session key (520) can be configured such that the IKM (input key material) is a host master key (510) (e.g., 32 bytes), the salt is a concatenation of a host identifier (host_uuid) and a session random number (e.g., 48 bytes), the info is a concatenation of a predefined label (e.g., "llm-user-key") and a device unique identifier, and the output length L is 32 bytes. The input structure can simultaneously provide security attributes such as key separation between multiple hosts by the host identifier included in the salt, session-specific key independence by the session random number included in the salt, uncalculable separation of client-specific keys by the device unique identifier included in the info, and domain separation by the label of the info.

[0042] The HKDF operation of the key derivation module (140) may be configured to be performed within the security processing unit (130) so that the result is not exposed as plaintext in the memory of the host operating system user area. According to another embodiment, it is also possible to implement the derivation of the client-specific session key (520) only within the security processing unit (130), and the HKDF-Expand based on the client-specific session key (520) to be performed externally, while the client-specific session key (520) is stored in a sealed area. Additionally, the HKDF operation of the key derivation module (140) may be performed by a CPU having SHA-256 instruction extension or by a hardware SHA accelerator within the security processing unit (130).

[0043] Four types of subkeys can be derived from the derived client-specific session key (520) by HKDF-Expand. According to one embodiment, the inference context encryption key (530) can be derived as HKDF-Expand(K_user, info="kv-cache", L=32), the audit log encryption key (540) as HKDF-Expand(K_user, info="log", L=32), the response channel encryption key (550) as HKDF-Expand(K_user, info="channel", L=32), and the session token signature key (560) as HKDF-Expand(K_user, info="session-token", L=32).

[0044] The inference context encryption key (530) can be used for disk encryption of the KV-cache storage unit (160a), the audit log encryption key (540) for separate encryption of the audit log storage unit (160b), the response channel encryption key (550) for secondary encryption of the response chunk of the token stream channel (320), and the session token signature key (560) for HMAC signature and authenticity verification of the session token. Since all four types of subkeys are derived from the client-specific session key (520), if the client-specific session key (520) is compromised, all four types may be compromised, but the reverse is not true.

[0045] Client-specific session keys derived for each of multiple client devices can be separated into uncomputable units by the pseudo-random function (PRF) properties of the HKDF. That is, even if one client possesses its own client-specific session key, calculating another client's client-specific session key is not possible with efficient algorithms recognized in the field; therefore, the exposure of one client-specific session key does not lead to the estimation of another client-specific session key or its subkey.

[0046] The LLM inference runtime (150) can perform the function of performing LLM inference for multiple clients. According to one embodiment, the LLM inference runtime (150) can perform multi-user inference using a single base model alone and can be performed using any of the known local LLM inference engines, and the present invention is not limited to a specific inference engine. When the LLM inference runtime (150) performs inference using a GPU or accelerator, protection by any one of Confidential Computing-based GPU memory protection or other memory encryption technology may be applied so that the client-specific session key (520) or the plaintext of the intermediate inference result is not exposed to the memory of the host operating system user space.

[0047] In an optional embodiment, the LLM inference runtime (150) can simultaneously load a single base model and a plurality of Low-Rank Adaptation (LoRA) adapter slots by the adapter slot management unit (150a). According to one embodiment, the number of adapter slots N can be set in the range of 4 to 64 depending on the available GPU memory, and each slot can store an adapter fine-tuned to a specific domain (e.g., code, medical, legal, Korean, corporate internal business).

[0048] The adapter slot management unit (150a) can select one of a plurality of adapter slots by deriving a slot identifier from a client-specific session key (520). According to one embodiment, the derivation of the slot identifier can be performed in the form of slot_id = HKDF-Expand(K_user, info="lora-slot", L=4) mod N, or slot_id = (the first 4 bytes of SHA-256(K_user∥"lora-slot")) mod N. Through this derivation, a consistent slot is selected within the same session of the same client, and since different clients have client-specific session keys that are separated into uncomputable ones, a conflict in slot selection does not occur except in the case of chance. Meanwhile, even if a conflict occurs where multiple clients happen to have the same slot identifier, each adapter slot can be operated as a domain-specific shared resource, and the output data of the slot delivered to each client is encrypted by an additional encryption key different for each client, so the client-specific isolation of the output data is maintained even when the slot is shared.

[0049] The output data of the selected adapter slot can be encrypted by an additional encryption key distinct from the response channel encryption key (550) and transmitted to the client device (200). According to one embodiment, the additional encryption key may be derived by HKDF-Expand from the client-specific session key (520) with a label different from the response channel encryption key (550) (e.g., "lora-channel") and separated from the response channel encryption key (550) by domain separation, or may be implemented with a key separately generated and stored for each client within the security processing unit (130). This separates the response channel and the adapter slot output into separate key regions, so that damage to the key in one region does not propagate to the other region. Additionally, according to one embodiment, the adapter weight file itself may be encrypted and stored on disk using a mechanism equivalent to the inference context encryption key (530).

[0050] The context storage unit (160) is a component that protects or isolates client-specific inferred context data by means of a client-specific session key (520) or at least one subkey derived from it via HKDF-Expand. Here, protecting or isolating by client may include, for example, isolating and encrypting storage using the client-specific session key (520) or its subkey. According to one embodiment, the context storage unit (160) may include a KV-cache storage unit (160a) and an audit log storage unit (160b).

[0051] The KV-cache storage unit (160a) can encrypt and store the KV-cache on disk using an authentication encryption (AEAD) method—e.g., AES-256-GCM, AES-256-OCB, ChaCha20-Poly1305, etc.—by the inference context encryption key (530). According to one embodiment, the KV-cache may be divided into page units (e.g., 16KB or 64KB) and a separate random number (nonce) may be assigned to each page, in which case damage to some pages does not affect the decryption of other pages. Additionally, the KV-cache may be stored in an area (file, directory, or logical volume) isolated per client.

[0052] The audit log storage unit (160b) can store client-specific audit logs separately, encrypted, and stored using an audit log encryption key (540). The audit log may include the request time, the hash value of the input prompt, the number of output tokens, the model version, the public part of the client identifier, etc., and whether to include input / output plaintext may be determined by a separate policy.

[0053] Even for the highest privilege administrator of the host device (100), plaintext access to the KV-cache or audit log stored on a disk or non-volatile storage may not be permitted except for the host master key (510). That is, even if the highest privilege administrator of the host operating system directly accesses the stored ciphertext file, only the ciphertext can be observed without the client's inference context encryption key, and plaintext recovery is impossible. This attribute can function as a core mechanism for protecting user privacy in scenarios involving sensitive information, such as medical, legal, or corporate internal information.

[0054] The channel control unit (180) can perform the function of separating the search / pairing channel (310) and the token stream channel (320) into separate logical channels that may be the same or different media. The channel control unit (180) can apply an advertising policy (e.g., ad cycle, visibility policy, rotation identifier update) in the search / pairing stage and independently apply an encryption / transmission policy (e.g., chunk size, secondary encryption by response channel encryption key, token splitting boundary) in the token stream stage.

[0055] The partitioning boundary of the token chunk transmitted by the channel control unit (180) through the token stream channel (320) can be determined at any one of the Unicode graphim cluster boundary, the subword token boundary, and the byte pair encoding (BPE) token boundary. The Unicode graphim cluster is a boundary of user-recognizable character units defined in Unicode UAX #29, where in the case of Korean, one graphim cluster corresponds to one syllable or a combination of consonants and vowels, and combined characters and emoji ZWJ sequences also form a single graphim cluster. If the token chunk is partitioned only at the graphim cluster boundary, broken characters such as consonant-vowel separation or combined character separation are not displayed even if the client immediately displays the partially received chunk, thus ensuring the streaming display quality of the response containing Korean, Chinese, Japanese, and emojis. The subword token boundary is a boundary corresponding to the lexical dictionary unit of the LLM model (in one embodiment: sentencepiece token boundary), where a single token is not partitioned across two chunks, so the client can perform accurate token count measurement and tokenizer decoding on a chunk basis. Byte pair encoding token boundaries are applied to token streams of models using the BPE tokenizer and have model-friendly properties equivalent to subword token boundaries.

[0056] Meanwhile, the host device (100) may further include a communication interface (190) for transmitting and receiving an ad payload and an LLM inference response to the outside. The communication interface (190) may include at least one of a Wi-Fi radio (190a) and a BLE radio (190b), and the ad payload generated by the ad transmission unit (110) and the token chunk transmitted by the channel control unit (180) may be transmitted to a search / pairing channel (310) or a token stream channel (320) through the communication interface (190).

[0057] FIG. 3 is a block diagram showing the internal configuration of a client device according to one embodiment of the present invention in more detail.

[0058] Referring to FIG. 3, a client device (200) according to one embodiment of the present invention may include an NSD / BLE browser unit (210), a device unique identifier storage unit (220), an attribute presentation unit (230), a host selection unit (240), and a token stream receiving unit (250).

[0059] The NSD / BLE browser unit (210) can perform the function of receiving an advertisement payload on a local network (300), and according to one embodiment, it may include an mDNS browser that receives an mDNS PTR query response and a BLE scanner that performs BLE scanning and GATT Read. The NSD / BLE browser unit (210) can be implemented through standard APIs specific to the operating system.

[0060] The device unique identifier storage unit (220) can perform the function of storing the device unique identifier of the client device (200) in a form bound to the device so as not to tamper with it. According to one embodiment, the device unique identifier storage unit (220) may be implemented in any one of the following forms: a device binding key of an Android Keystore, a sealing key of an iOS Secure Enclave, an Endorsement Key of TPM 2.0, or other identifiers that can be bound to the device and tested.

[0061] The test presentation unit (230) can transmit a test (DID test) for an identifier stored in the device unique identifier storage unit (220) to the test verification unit (120) of the host device (100) and receive a session token from the host device (100).

[0062] The host selection unit (240) can perform the function of selecting a single host device (100) by a weighted sum or a multi-criteria decision function based on at least two of a load indicator, a model match, and a round-trip time (RTT) included in a plurality of ad payloads received from a plurality of host devices (100). According to one embodiment, the host selection unit (240) has score_i = w_load A score for each host i can be calculated by a weighted sum function of × (1 - load_i) + w_match × match_i + w_rtt × (1 - norm_rtt_i), and the host with the highest score can be selected. Here, load_i is the load metric of host i (0 or greater, 1 or less), match_i is the degree of match with the model and domain required by the client (0 or greater, 1 or less), norm_rtt_i is the normalized round-trip time, and w_load, w_match, and w_rtt are predetermined weights. According to another embodiment, a multi-criteria decision function such as TOPSIS or AHP, or a machine learning-based scoring function, may be used instead of the weighted sum function.

[0063] The token stream receiver (250) can receive token chunks of an LLM inference response through a token stream channel (320) and reassemble the received chunks according to token boundaries and deliver them to the application layer. According to one embodiment, the token stream receiver (250) may include at least one sub-configuration of a Server-Sent Events (SSE) receiver, a WebSocket receiver, or a BLE GATT Notify receiver, and the received chunks may be decrypted by a response channel encryption key (550).

[0064] FIG. 4 is a sequence diagram showing the discovery, appraisal, and session establishment process according to one embodiment of the present invention.

[0065] Referring to FIG. 4, the discovery, authentication, and session establishment between a client device (200) and a host device (100) according to one embodiment of the present invention can be performed in the following order.

[0066] First, the advertisement transmission unit (110) of the host device (100) can transmit a PTR / SRV / TXT record of a service type for LLM inference via UDP 5353 multicast through the mDNS / DNS-SD Advertiser (110a), and simultaneously transmit BLE advertisement data (420) including a 128-bit custom service UUID and Manufacturer Specific Data through the BLE GATT Advertiser (110b). Thus, an advertisement payload (400) including LLM inference metadata and an authentication method identifier is transmitted through the search / pairing channel (310) (S410).

[0067] The NSD / BLE browser unit (210) of the client device (200) receives an advertisement payload (400) through an mDNS PTR query or a BLE scan, and when advertisements are received from multiple hosts, the host selection unit (240) can select a single host device (100) based on load indicators, model matching, round-trip time, etc. (S420). According to one embodiment, the client device (200) may also passively detect advertisements from the host device (100) by performing a BLE scan in a background low-power mode.

[0068] Next, the attribute presentation unit (230) of the client device (200) transmits an attribute for an identifier stored in the device unique identifier storage unit (220) to the attribute verification unit (120) of the host device (100) (S430), and the attribute verification unit (120) can verify the authenticity of the received attribute (S440). If verification is successful (S440-Yes), the verified device unique identifier is transmitted to the key derivation module (140), and if verification fails (S440-No), the derivation of the client-specific session key (520) is not performed, and a rejection response may be transmitted to the client device (200) (S450).

[0069] The key derivation module (140) that receives the verification success result can cooperate with the security processing unit (130) to derive a client-specific session key (520) using HKDF, and can expand and derive four types of subkeys, including an inference context encryption key (530), an audit log encryption key (540), a response channel encryption key (550), and a session token signature key (560), using HKDF-Expand (S441).

[0070] Subsequently, a session token signed by HMAC with a session token signing key (560) may be issued to a client device (200) (S443). According to one embodiment, the session token may be implemented in the JSON Web Token (JWT) format of RFC 7519 or an equivalent self-verifiable token format, and the payload may include a tested device unique identifier, issuance and expiration times, and a host identifier.

[0071] Finally, the client device (200) can send an inference request including a session token and a user prompt to the host device (100) (S460). After verifying the HMAC signature of the session token, the host device (100) can decrypt the KV-cache stored by encrypting it with the inference context encryption key (530), load it into the LLM inference runtime (150), and perform inference (S465). The channel controller (180) transmits the response in chunks through the token stream channel (320) (S470), and each chunk can be further encrypted with the response channel encryption key (550). This secondary encryption is applied over the primary encryption of the token stream channel itself (e.g., TLS 1.3) to further protect against the risk of plaintext leakage even when the channel endpoint is located in the user space. After the inference is finished, the updated KV-cache can be re-encrypted with the inference context encryption key (530) and stored in the KV-cache storage unit (160a), and the audit log can be encrypted with the audit log encryption key (540) and stored in the audit log storage unit (160b).

[0072] In this manner, the ad transmission unit (110), the authentication verification unit (120), the security processing unit (130), the key derivation module (140), the context storage unit (160), and the channel control unit (180) are not configured to operate independently in parallel, but rather the result of validation according to the authentication method indicated by the ad payload controls whether to perform the key derivation operation, and the client-specific session key (520) or its subkey, which is the result of the key derivation operation, can be combined so that it is continuously used for the protection of the LLM inference context and the protection of the inference response through the second communication channel. Accordingly, for clients that fail validation, the client-specific session key (520) is not generated, and access to the protected inference context and inference response channel may not be allowed.

[0073] FIG. 5 is a diagram showing the key hierarchy of device unique identifier-based key derivation and subkey expansion according to one embodiment of the present invention.

[0074] Referring to FIG. 5, a key layer according to one embodiment of the present invention may be configured as a two-layer structure in which a client-specific session key (520) is derived from a host master key (510), and four types of sub-keys (530, 540, 550, 560) are derived from the client-specific session key (520). A host identifier and a session random number are concatenated to form a salt, and a predefined label and a device unique identifier are concatenated to form info, and a client-specific session key (520) can be derived by an HKDF operation with the host master key (510) as the IKM.

[0075] The core security attribute of this key layer is that plaintext access to client-specific inference contexts stored on disk or non-volatile storage is not allowed, except for the host master key (510), even with administrator privileges of the host device (100). The host master key (510) is used only within the security processing unit (130), the client-specific session key (520) is protected within the security processing unit (130) or by memory encryption technology, and the four types of subkeys are derived keys of the client-specific session key (520) and are limited to their respective uses.

[0076] In addition, since session random numbers are generated independently for each session, when the same client reconnects after terminating an inference session, a new client-specific session key is derived using the updated session random number, and the new key is separated from the previous session's key as uncalculable. This improves key independence between sessions.

[0077] FIG. 6 is a diagram showing the configuration of an advertisement payload according to one embodiment of the present invention.

[0078] Referring to FIG. 6, an advertisement payload (400) according to one embodiment of the present invention may be transmitted in two forms: an mDNS TXT record (410) format and a BLE advertisement data (420) format, and may further include optional verification information (430) depending on one embodiment.

[0079] mDNS TXT records (410) can be configured in the key-value pair format defined in RFC 6763. According to one embodiment, the key set of the TXT record (410) may include a discovery profile identifier and version (e.g., rp=llm / v1), an application layer protocol supported by the host (e.g., proto=openai-chat,ollama), a loaded model identifier (e.g., mdl=llama3-8b,qwen2-7b-int4), a context window size (e.g., ctx=8192), a token throughput limit (e.g., tok=4096), a domain tag (e.g., dom=code,korean,medical), a supported TLS version (e.g., tls=1.3,1.2), an authentication method identifier (e.g., auth=did-hkdf,oauth2,mtls), a supported authentication mechanism (e.g., did_alg=android-attest,ios-dcappattest,tpm2), a load metric (e.g., load=0.42), and a visibility policy (e.g., vis=public / group / restricted, optional). According to one embodiment, the advertisement payload (400) may include at least four keys from the above set of keys, and the total length of the TXT record may be adjusted to about 200 bytes or less by a compressed representation of key-value pairs such as bitpack enumeration, base64, or by splitting multiple TXT records in accordance with the recommendations of RFC 6763. The did-hkdf value included in the authentication method identifier indicates to the client that a key derivation method using a device unique identifier as input is supported on the host.

[0080] BLE advertising data (420) can be transmitted by being included in the Manufacturer Specific Data area within the BLE Advertising Data structure according to the Bluetooth Core Specification. According to one embodiment, the size of this area may be limited to 25 bytes or less in consideration of the BLE advertising PDU size constraint, and core metadata may be serialized in a bitfield compressed format of an index of a pre-registered model identifier (e.g., 8 bits), a log2 representation of the context window size (e.g., 4 bits, where the value 13 means 8192), a value quantized from 0 to 255 for the load indicator (e.g., 8 bits), and a bitmask of visibility and authentication methods (e.g., 2 bits each). A 128-bit custom service UUID is included in the header portion of the BLE advertising data (420) so that the LLM service according to the present invention can be distinguished from a general BLE device.

[0081] According to one embodiment, the host device (100) may use a Resolvable Private Address (RPA) that is updated at a predetermined interval as the advertiser address during BLE advertising. The original device address of the RPA can be identified only by an Identity Resolving Key (IRK) shared between the client device (200) and the host device (100) that are previously bonded. Additionally, separately, the BLE advertising data (420) may further include a rotation identifier field that is updated at a predetermined rotation interval—e.g., a range of 1 second to 1 hour—along with LLM inference metadata. By means of the RPA and the rotation identifier, only a pre-authenticated client can identify or verify the host device (100), and the possibility of continuous identification or advertising tracking by external unauthorized observers can be reduced.

[0082] Optional verification information (430) is a data field for verifying the authenticity of the host device (100) or the integrity of the advertisement payload (400), and may include signature data calculated by a key within the security processing unit (130) according to one embodiment. Optional verification information (430) is not an essential component of the present invention and may be further included in the advertisement payload (400) according to one embodiment.

[0083] A GATT service corresponding to a 128-bit custom service UUID advertised by a BLE GATT Advertiser (110b) may include four attributes. CAP_CHAR(Read) is an attribute that returns the entire set of the host's capability specifications in JSON or CBOR format, and the client can obtain detailed capability specifications by reading this attribute after receiving core metadata from the BLE advertisement, and the signature data of the optional validation information (430) may also be provided through this attribute. DISCO_CHAR(Read) is an attribute that returns the host identifier and additional information required for the discovery step. ATTEST_CHAR(Write / Notify) is a bidirectional attribute in which the client sends an assertion for the device unique identifier via Write, and the host replies with the validation result and session token via Notify. STREAM_CHAR(Notify) is a unidirectional attribute in which the host sends a token chunk to the client via Notify. According to one embodiment, a Data Length Extension (DLE) is applied separately, and the ATT MTU can be negotiated to 247 bytes through an ATT MTU exchange procedure. In this case, the characteristic value included in a single Handle Value Notification may be up to 244 bytes, excluding protocol overhead. Due to the GATT service structure, the entire flow of discovery, assertion, and token streams according to the present invention can be completed on a single BLE medium, even in an environment where only BLE is available.

[0084] FIG. 7 is a diagram showing the separation structure of a search / pairing channel and a token stream channel according to an embodiment of the present invention.

[0085] Referring to FIG. 7, the search / pairing channel (310) and the token stream channel (320) according to one embodiment of the present invention may be operated as separate logical channels that can be mapped to the same medium or different media, respectively.

[0086] In one embodiment, the search / pairing channel (310) and the token stream channel (320) may both be configured as separate logical channels of the BLE medium. In this case, search / pairing may be performed with a Service UUID and Manufacturer Specific Data in the BLE advertising channel, and the token stream may be performed with a GATT Notify of the STREAM_CHAR attribute, which is suitable for environments where Wi-Fi multicast is blocked or for mobile scenarios.

[0087] In another embodiment, the search / pairing channel (310) may be an mDNS multicast (UDP 5353) channel, and the token stream channel (320) may be an HTTP / 2-based SSE, HTTP / 3-based streaming response, or WebSocket for a host IP and port extracted from an SRV record. In a typical embodiment of a home Wi-Fi or in-house LAN environment, even if the two channels are mapped to the same medium, the protocol, port, and encryption policy are applied independently.

[0088] In another embodiment, the search / pairing channel (310) may be implemented in a medium switching form configured as BLE Coded PHY 125 kbps (low speed / long range) and the token stream channel (320) as Wi-Fi 5 GHz or UWB (high band). In this case, after the client device (200) discovers and pairs with a host via BLE, it receives Wi-Fi credentials encrypted with the response channel encryption key (550) via the ATTEST_CHAR Notify of the BLE GATT, and the subsequent token stream may be switched to be performed via Wi-Fi.

[0089] In another embodiment, the search / pairing channel (310) may be configured as mDNS over Wi-Fi, and the token stream channel (320) may be configured as USB, Thunderbolt, PCIe over USB4, or an equivalent wired high-bandwidth medium.

[0090] The channel control unit (180) can operate in any one of the above embodiments, and ensure that client-specific keys, such as the response channel encryption key (550), are maintained for the same session of the same client regardless of channel switching. That is, even if the medium is switched from BLE to Wi-Fi, the chunk is secondarily encrypted with the same response channel encryption key and transmitted, and even if channel switching occurs, the isolation of the host-side KV-cache and audit log is maintained by the inference context encryption key (530) and the audit log encryption key (540), so channel switching and context isolation are applied independently of each other.

[0091] FIG. 8 is a diagram showing a context isolation structure for simultaneous multi-client access according to an embodiment of the present invention.

[0092] Referring to FIG. 8, a host device (100) according to one embodiment of the present invention can derive a client-specific session key that is separated from each other and cannot be computed from each client's device unique identifier, even when a plurality of client devices simultaneously connect and perform LLM inference, thereby isolating and encrypting the KV-cache and user-specific audit logs on a client-specific basis.

[0093] The key derivation module (140) can use the same host master key (510) while including each client's device unique identifier in the info of the HKDF, thereby allowing client-specific session keys derived from different device unique identifiers to be separated into uncalculable ones by the pseudo-random number function attribute of the HKDF. Each client's session random number is generated independently for each session, and the device unique identifier is an untamper-proof identifier verified by an authentication test.

[0094] The inference context encryption key derived from each client's client-specific session key can be stored in an area isolated by each client using an authentication encryption method by the KV-cache storage unit (160a). Even if the highest-privilege administrator of the host operating system accesses all stored files, neither side's plaintext can be restored unless the inference context encryption key of each client is known. Furthermore, within the LLM inference runtime (150), the KV-caches of clients undergoing concurrent inference are loaded into different memory areas, so separation can be maintained even on the GPU or accelerator memory. Additionally, since each client's audit log is also stored with separate encryption using a client-specific audit log encryption key, one client's audit log cannot be viewed in plaintext by another client or administrator.

[0095] For example, in a small office environment where five users simultaneously request LLM inference, each user's client device may have a storage of different types of device unique identifiers, such as an Android Keystore, a TPM Endorsement Key, an iOS Secure Enclave, or WebAuthn passkey credentials, and the key derivation module (140) can derive five mutually uncomputable, separate client-specific session keys from these heterogeneous identifiers. In an optional embodiment, five adapter slots are loaded simultaneously, and the adapter is activated according to each user's slot identifier, and the output of each slot can be encrypted by an additional encryption key specific to the user and transmitted. When a user reconnects after ending an inference session, the session random number is updated to derive a new client-specific session key, thereby improving key independence between sessions.

[0096] FIG. 9 is a flowchart illustrating the discovery, pairing, and token stream processing process in a BLE standalone environment according to one embodiment of the present invention.

[0097] Referring to FIG. 9, a host device (100) according to one embodiment of the present invention can operate to perform discovery, pairing, and token streams using an LE Coded PHY option of BLE 5.0 or higher in an environment where Wi-Fi multicast is impossible—e.g., a medical device proximity area in a hospital, an RF shielded area in a factory, an environment where mDNS multicast is blocked because the Wi-Fi guest SSID is set to client isolation, or an outdoor environment where Wi-Fi is temporarily disconnected. The LE Coded PHY uses a symbol rate of 1 Msym / s and is a PHY option that provides an effective data transmission rate of approximately 500 kbps or approximately 125 kbps, respectively, depending on the S=2 or S=8 coding scheme, and can provide characteristics advantageous for long-distance discovery compared to a standard BLE PHY.

[0098] First, the client device (200) initiates a BLE scan with the LE Coded PHY option via the NSD / BLE browser unit (210) (S910) and can determine whether to receive BLE advertisement data (420) from the host device (100) (S920). If the reception of BLE advertisement data (420) is successful (S920-Yes), the client device (200) can verify the authentication method identifier included in the advertisement (S930). If verification is successful (S930-Yes), a GATT Connect is performed using the host's BLE address or rotation identifier (S931), and if verification fails (S930-No), a Wi-Fi fallback is attempted (S933).

[0099] After establishing a GATT connection, the client device (200) can obtain capability specifications in JSON or CBOR format via CAP_CHAR Read (S940). Next, it sends an authentication for the device unique identifier to the host device (100) via ATTEST_CHAR Write (S950), and upon successful authentication, receives a session token signed by HMAC with the session token signing key from the host via ATTEST_CHAR Notify (S960). Subsequently, the client device (200) subscribes to STREAM_CHAR and receives token chunks that are secondarily encrypted with the response channel encryption key via Notify (S970). Each Notify carries a characteristic value of up to 244 bytes excluding protocol overhead when the ATT MTU is negotiated to be 247 bytes, and under the MTU constraint of the BLE GATT, only one or several tokens can be transmitted as a unit chunk at a time. Since the splitting boundary of a token chunk is determined at any one of the Unicode graphim cluster boundary, the subword token boundary, and the byte pair encoding token boundary, users can receive chunk-based progressive streaming responses without broken characters even in low-speed channel environments.

[0100] Meanwhile, as an example of a home environment, a case may be cited in which a laptop in the living room, a smartphone and tablet for each user, and a voice assistant type IoT terminal in the kitchen are connected to a host device (100) installed in the living room via the same home Wi-Fi LAN. In this case, when the advertisement sending unit (110) sends an advertisement payload (400) via mDNS multicast, each client device can receive the advertisement within hundreds of milliseconds without the procedure of entering the host IP or port in advance and discover the host. Each client sends an attest using an attestation mechanism suitable for its platform—for example, Android Key Attestation for Android smartphones, iOS DeviceCheck App Attest for iPadOS tablets, and TPM 2.0 Quote for laptops—and the host device (100) can accept all heterogeneous attestation mechanisms to derive a client-specific session key for each client. The KV-cache plaintext and audit log plaintext of any user are not exposed to the storage area of ​​another user, and access to the plaintext is not allowed even with administrator privileges of the host device (100) without the host master key (510) inside the security processing unit (130).

[0101] The embodiments described above may be implemented as hardware components, software components, and / or combinations of hardware and software components. For example, the devices, methods, and components described in the embodiments may be implemented using one or more general-purpose computing devices or special-purpose computing devices, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications executed on said operating system. Additionally, the processing device may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing device may be described as being used as a single one, but those skilled in the art will understand that the processing device may include multiple processing elements and / or multiple types of processing elements. For example, the processing unit may include multiple processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are also possible.

[0102] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or instruct the processing unit independently or collectively. Software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

[0103] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

[0104] Although the embodiments have been described above with reference to the limited drawings, those skilled in the art can apply various technical modifications and variations based on the above. For example, suitable results may be achieved even if the described techniques are performed in a different order than described, and / or if the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

Claims

Claim 1 An LLM sharing device that provides a Large Language Model (LLM) inference service based on Network Service Discovery (NSD) to one or more client devices, comprising: an ad delivery unit that transmits an ad payload through a first communication channel, the ad payload including metadata regarding LLM inference capability and an authentication method identifier representing a client identification-based key setting method; an authentication verification unit that verifies the validity of client identification information or device-linked authentication information received from the client device; a security processing unit that manages a host master key in a hardware security area; a key derivation module that generates a client-specific session key by performing a key derivation operation including the host master key and the validated client identification information or device-linked authentication information as input values ​​in conjunction with the security processing unit, wherein the key derivation operation is performed such that at least the plaintext of the host master key is not exposed outside the hardware security area; and a context storage unit that protects or isolates LLM inference context data on a client-specific basis using the client-specific session key or a subkey derived from the client-specific session key. An LLM sharing device comprising a channel control unit that transmits an LLM inference response to the client device through a second communication channel distinct from the first communication channel used for transmitting the advertisement payload. Claim 2 An LLM sharing device according to claim 1, wherein the first communication channel comprises at least one of a multicast Domain Name System (mDNS) based channel and a low-power Bluetooth (BLE) based advertising channel. Claim 3 An LLM sharing device according to claim 1, wherein the metadata includes at least one of a model identifier, context window size, token throughput, domain tag, and load indicator loaded into the LLM sharing device, and the authentication method identifier includes a value indicating the use of a key derivation method that takes client identification information or device combined authentication information as input. Claim 4 An LLM sharing device according to claim 1, wherein the key derivation module generates the client-specific session key by operating an HMAC-based key derivation function (HKDF) and derives at least one subkey among an inference context encryption key, an audit log encryption key, and a response channel encryption key from the generated client-specific session key. Claim 5 In claim 4, the context storage unit comprises: a KV-cache storage unit that isolates and encrypts KV-cache data, which is an intermediate result of an attention operation, on a client-by-client basis using the inference context encryption key; and an audit log storage unit that separately encrypts and stores audit logs regarding client-by-client inference requests and responses using the audit log encryption key, wherein the plaintext of the host master key, the client-by-client session key, or the subkey is configured not to be provided to the operating system user area of ​​the LLM sharing device, and plaintext access to the stored KV-cache data and audit logs is restricted. Claim 6 An LLM sharing device according to claim 1, wherein the security processing unit is composed of any one of a Trusted Execution Environment (TEE), a Secure Element, and a Trusted Platform Module (TPM), and wherein the plaintext of the host master key is not exposed to the memory and storage of the operating system user area of ​​the LLM sharing device. Claim 7 An LLM sharing device according to claim 1, characterized in that at least a portion of the key derivation operation is performed within the hardware security area. Claim 8 An LLM sharing device according to claim 1, wherein the channel control unit divides and transmits an LLM inference response in token chunk units through the second communication channel, and the division boundary of the token chunk is determined at any one of a Unicode graphim cluster boundary, a subword token boundary, and a byte pair encoding token boundary. Claim 9 An LLM sharing device according to claim 1, wherein the first communication channel is a low-power Bluetooth advertising channel and the second communication channel includes any one of wireless LAN (Wi-Fi), ultra-wideband (UWB), wired Ethernet, and universal serial bus (USB), and wherein the first communication channel and the second communication channel are mapped to different physical media. Claim 10 An LLM sharing device according to claim 1, wherein the ad transmitting unit provides signature data calculated by a signature key within the hardware security area by including it in the ad payload or a capability inquiry response corresponding to the ad payload, and the client device verifies the signature data so that the authenticity of the LLM sharing device and the integrity of the ad payload can be verified at the reception stage of the ad payload. Claim 11 An LLM sharing device according to claim 4, wherein the key derivation module generates a client-specific session key for each of a plurality of client devices by including different client identification information or device combination authentication information as input values, and the client-specific session keys generated for each of the plurality of client devices are separated into uncomputable ones by the pseudo-random number function attribute of the key derivation function, such that the exposure of any one client-specific session key does not lead to the estimation of another client-specific session key or the corresponding subkey. Claim 12 An LLM sharing device according to claim 4, further comprising an adapter slot management unit that selects and activates one of a plurality of lightweight fine-tuning adapter slots based on a slot identifier derived from the client-specific session key, wherein the output data of the selected adapter slot is encrypted by an additional encryption key derived from the client-specific session key separately from the response channel encryption key and transmitted to the client device. Claim 13 An LLM sharing device according to claim 2, wherein, when the first communication channel includes a low-power Bluetooth-based advertising channel, the advertising payload includes a rotating identifier that is updated at a predetermined period along with the metadata, and the rotating identifier is generated in a privacy-preserving manner that can be identified or verified only by a pre-authenticated client device, thereby reducing the possibility of continuous identification or advertising tracking by unauthorized observers. Claim 14 An LLM sharing method in which an LLM sharing device provides a large-scale language model (LLM) inference service based on network service discovery (NSD) to one or more client devices, comprising: a step of transmitting an advertisement payload through a first communication channel that includes metadata regarding LLM inference capability and an authentication method identifier representing a client identification-based key setting method; a step of verifying the validity of client identification information or device-linked authentication information received from a client device; a step of generating a client-specific session key by performing a key derivation operation that includes a host master key managed in a hardware security area and the validated client identification information or device-linked authentication information as input values, wherein at least the plaintext of the host master key is not exposed outside the hardware security area; a step of protecting or isolating LLM inference context data for each client using the client-specific session key or a subkey derived therefrom; and a step of transmitting an LLM inference response to the client device through a second communication channel distinct from the first communication channel used for transmitting the advertisement payload. Claim 15 An LLM sharing method according to claim 14, wherein, in the transmitting step, the first communication channel comprises at least one of a multicast Domain Name System (mDNS) based channel and a low-power Bluetooth (BLE) based advertising channel. Claim 16 In claim 14, the step of generating a client-specific session key is performed by an HMAC-based key derivation function (HKDF), and the step of protecting or isolating includes: a step of isolating and encrypting KV-cache data by client using an inference context encryption key derived from the client-specific session key; and a step of separating and encrypting and storing a client-specific audit log using an audit log encryption key derived from the client-specific session key. Claim 17 An LLM sharing method according to claim 14, characterized in that if the validity verification of the client identification information or device combination authentication information fails in the verification step, the step of generating the client-specific session key is not performed and a rejection response is sent to the client device. Claim 18 An LLM sharing method according to claim 14, further comprising the step of issuing a session token using the client-specific session key or a session token signing key derived therefrom. Claim 19 In claim 14, the step of transmitting the LLM inference response is characterized by dividing the LLM inference response into token chunk units and transmitting them sequentially, wherein the dividing boundary of the token chunk is determined at any one of a Unicode graphim cluster boundary, a subword token boundary, and a byte pair encoding token boundary, and the token chunk is transmitted in a form capable of progressive output in chunk units. Claim 20 An LLM sharing method according to claim 14, wherein the first communication channel is a low-power Bluetooth advertising channel, and the second communication channel includes any one of wireless LAN (Wi-Fi), ultra-wideband (UWB), wired Ethernet, and universal serial bus (USB), and wherein, after discovery and pairing are completed through the first communication channel, the method switches to the second communication channel to transmit an LLM inference response. Claim 21 In claim 16, the step of generating a client-specific session key is performed by including different client identification information or device combination authentication information as input values ​​for each of a plurality of client devices, and the client-specific session keys generated for each of the plurality of client devices are separated into uncomputable ones by the pseudo-random number function attribute of the HMAC-based key derivation function, such that the exposure of any one client-specific session key does not lead to the estimation of another client-specific session key or the corresponding subkey, characterized by an LLM sharing method.

Images