Dynaseal: A Backend-Controlled LLM API Key Distribution Scheme with Constrained Invocation Parameters

1. Introduction

Large Language Models (LLMs) [1,2], such as ChatGPT [3], GPT-4 [4], and Claude 3 [5], have shown remarkable progress and impact across diverse domains [6]. Current LLM API access relies on Bearer Token authentication, but this faces challenges with growing edge device inference needs. Edge devices include smartphones, PCs, and microcontrollers interfacing with cloud models.

Two common approaches for edge device model invocation are:

• Pre-embedded API Keys: API keys are configured in devices, enabling direct model access.
• Server Relay: Intermediary servers relay requests, requiring persistent device-server connections.

Both approaches have limitations: pre-embedded API keys are vulnerable to security breaches, and server relay introduces latency and bandwidth overhead.

Some attempts have been made by the community to address this issue, but each has its limitations. The OpenAI API [7] does not provide server-side keys and can only use Bearer Tokens on the client side. Zhipu AI’s keys [8] offer both server-side and client-side invocation methods, supporting server-issued keys and expiration control, but they cannot restrict critical parameters, leaving them vulnerable to attacks. Although OneAPI [9] can redistribute keys, the invocation method remains Bearer Token-based, failing to resolve the client-side invocation problem.

We propose Dynaseal, a novel methodology that enforces backend model invocation constraints. Users retain token-based authentication simplicity while the backend enforces strict controls on model selection and token limits, enhancing model security.

2. Related Work

2.1. Bearer Token Authentication

Bearer token authentication is a widely adopted protocol for securing web APIs and services [10]. This mechanism allows clients to access protected resources by presenting a token, which serves as proof of authorization. The token is typically transmitted in the HTTP Authorization header with the "Bearer" scheme.

2.2. JWT Token

JSON Web Token (JWT) represents a compact, URL-safe means of representing claims between parties [11]. A JWT consists of three parts: a header specifying the signing algorithm [12], a payload containing claims, and a signature for verification. The self-contained nature of JWTs eliminates the need for database lookups, making them particularly efficient for stateless authentication. However, this approach also presents challenges in token revocation and session management, requiring additional mechanisms such as blacklisting or short expiration times.

3. Method

The system architecture comprises three primary components: Large Language Model (LLM) service providers, backend servers, and edge devices.

• The LLM service providers are organizations that host and operate large language models, being responsible for all model-generated responses and inference operations.
• The backend servers function as authentication endpoints for edge devices while also handling business logic implementations. The specific implementation details are determined by the engineering requirements of each deployment scenario.
• Edge devices encompass a diverse range of hardware platforms, from sophisticated devices such as smartphones and personal computers to resource-constrained systems like microcontrollers.

3.1. Backend Authentication

Prior to backend server deployment, a kv-pair (comprising user-id and secret-key) must be obtained from the LLM provider. The kv-pair are subsequently integrated into the service configuration for token generation and identity verification purposes.

3.2. Token Structure

The core mechanism of Dynaseal centers on a specially designed JWT (JSON Web Token) [11], with its structural composition illustrated in Figure 1.

• Header: Declare the encryption algorithm and token type.
• Payload: Include key parameters such as model name and maximum token count. The api-key field in payload is configured as user-id of the key-value pair to identify the backend server’s identity with the large model provider. The expiration time is set extremely short (e.g., 1s) to prevent reuse.
• Signature: Sign with a key-value pair secret-key to ensure token integrity, preventing token tampering.

3.3. Interaction Process

As shown in the Figure 2, the backend server issues tokens to edge devices, with each token encapsulating critical model invocation parameters. Edge devices leverage these tokens to initiate model calls, while the LLM service infrastructure enforces strict invocation constraints based on the parameters embedded within the tokens. Upon completion of the model response, the backend system receives relevant notifications through established callback mechanisms, facilitating comprehensive request lifecycle management.

• Request for token: Edge-side devices requests token from backend for subsequent interactions accorfind to business logic.
• Issue token: Backend issues token to edge-side.
• Request response: Edge-side uses token to request response insead of Bearer Token.
• Respond to request: Large model provider responds to edge-side.
• Callback to notify response content: Upon response completion, callback notifies response content.

3.4. Attack Prevention

Our system implements comprehensive security measures to prevent potential attacks:

• Token Tampering: Malicious actors may attempt to modify token contents to gain unauthorized access. We prevent this through robust digital signatures that ensure token integrity, making any unauthorized modifications detectable.
• Token Replay: Attackers might try to reuse previously issued tokens. Our system mitigates this risk by implementing extremely short validity periods, rendering captured tokens unusable after expiration.
• Invalid Model Invocation: To prevent unauthorized model access or parameter manipulation, tokens contain critical execution parameters. The LLM service provider enforces strict invocation constraints based on these embedded parameters, ensuring all calls comply with specified limitations.

4. Experiments

4.1. Security Analysis

As shown in Table 1, we compared the advantages and disadvantages of Dynaseal and three other model invocation methods. We evaluated aspects such as client-side key control, tamper resistance, critical parameter control, and multi-model support, all of which are supported by Dynaseal.

4.2. Traffic Consumption Comparison

We compared the network traffic consumption between LLM service providers and backend servers across different approaches including pre-embedded API keys and server relay, as shown in Table 2. The results demonstrate that our method effectively reduces backend server traffic while maintaining constant LLM service provider traffic, simultaneously ensuring key security.

5. Conclusion

We propose a novel method, Dynaseal, allowing backend constraints on model invocation, effectively addressing existing edge-side model invocation security issues while avoiding server relay waste. We provide a complete design and interaction flow, demonstrating the feasibility of this approach.