Method, system and computer readable storage medium for controlled use of large model service keys based on device-bound access credentials

Abstract

The application relates to the technical field of network security and identity authentication, and discloses a large model service key controlled use method and system based on device binding access credentials and a computer readable storage medium. A client generates a possession proof for a credential operation and a model access request respectively by using a device private key, a proxy server binds an access credential with a device public key and maintains a device state, and only when the credential, the possession proof and the device state are verified, a model service key saved on a server side is called according to a model identifier to access a target model server. The scheme makes the copied access credential difficult to be used without the binding device, blocks the access of the unexpired credential after the device is disabled, avoids the model service key from being sent to the client, reduces the risk of credential replay and model service key leakage while keeping the continuous access.

Description

Technical Field

[0001] This invention relates to the fields of network security, identity authentication, and network access control, and specifically to a method, system, and computer-readable storage medium for the controlled use of a large-scale service key based on device-bound access credentials. Background Technology

[0002] As generative artificial intelligence and large language model services are gradually made available to individual users, enterprise software, and various business applications via network interfaces, an increasing number of clients need to call models deployed by third-party model service providers through application programming interfaces (APIs). Different model service providers typically set up corresponding interface addresses, model identifiers, and authentication methods, and identify the caller through API keys, Bearer tokens, or other service credentials. To enable desktop applications, business software, or other clients to continuously call model services, model service credentials usually need to be configured and stored on the client or in the client-related runtime environment.

[0003] In practice, model service credentials may be stored in application configuration files, environment variables, local databases, or the program's runtime environment. For service credentials that require possession for use, if the credential content is copied due to improper terminal permission configuration, malicious program reading, software debugging, log recording, or other reasons, the party obtaining the credential may bypass the original client and directly initiate model calls from other programs or devices. Especially when the same client needs to access multiple model service providers, it may also configure multiple different sets of interface addresses and service credentials simultaneously, making credential management, updates, and access control on the terminal side more complex.

[0004] To address the issue of service credentials being stored directly on the client side, existing systems already employ centralized access to backend services via proxy servers or API gateways. The client first submits an access request to the proxy server, which performs access control and then uses backend authentication information maintained on the server side to initiate a request to the target service. This approach reduces the likelihood of real backend service credentials being distributed across numerous clients, but a separate authentication and authorization relationship still needs to be established between the client and the proxy server. When this authentication relationship primarily relies on ordinary bearer-based access credentials, as long as the access credentials themselves are still valid, the party obtaining a copy of the credentials may reuse them in other operating environments.

[0005] To shorten the exploitable time after credential leakage, existing technologies employ methods such as short-term access credentials, credential refresh, and periodic rotation to manage client access qualifications. However, excessively short credential validity periods increase re-issuance and authentication operations, while excessively long validity periods extend the exploitable time after credential copying. If the server relies solely on the validity period of already issued credentials to determine whether to grant access after device loss, client deactivation, or changes in access qualifications, already issued and unexpired credentials may still be used. Simultaneously, once refresh credentials are copied, the issue of repeated submissions and their continued use to obtain subsequent access credentials needs to be considered.

[0006] On the other hand, existing terminal devices already possess key protection capabilities such as TPM, TEE, security chips, and operating system security key services. The network authentication field also has technologies that prove the current requester holds a specific private key through private key signatures. However, in actual large-scale model service access environments, client authentication, continuous credential management, device status management, model service routing, and the actual authentication information of different model service providers are often handled by different stages, and the management scope and credential application scope of each stage are not the same.

[0007] Therefore, how to reduce the risk of client access qualifications being copied and used across devices while maintaining continuous user access to model services, and at the same time reduce the exposure of real model service credentials on the client side, remains a problem that needs to be further solved in the process of large model service access and security management. Summary of the Invention

[0008] The technical problem to be solved by this invention is to improve the correlation between device identity and access credentials during continuous client access to large model services, and to reduce the risk of model service keys being exposed on the client side and used without authorization.

[0009] To address the aforementioned technical problems, the first aspect of this invention provides a method for controlled use of a large-scale service key based on device-bound access credentials, comprising the following steps:

[0010] S1. The user completes identity authentication through the client. The client calls the security key module on the user's device to generate or load the device's public and private key pair. The proxy server obtains the authenticated user's identity information and device public key, establishes a device binding relationship between the user's identity information and the device public key, records the device status corresponding to the device public key, and issues an initial device binding access credential bound to the device public key.

[0011] S2. When the device binding access credential needs to be updated or reissued, the client uses the device private key to generate a first holding certificate for the current device binding access credential and the current credential request, and submits the device binding access credential, the current credential request, and the first holding certificate to the proxy server; the proxy server uses the device public key bound to the device binding access credential to verify the first holding certificate, and verifies the device binding relationship and device status. After successful verification, it updates or reissues the device binding access credential bound to the same device public key.

[0012] S3. The client receives the model access request, uses the device private key to generate a second holding certificate associated with the device binding access credential, model identifier and model access request used for this model access, and sends the model access request, device binding access credential and second holding certificate to the proxy server.

[0013] S4. The proxy server verifies the device binding access credential and the second holding proof, and queries the device status corresponding to the device public key; after the device binding access credential, the second holding proof, and the device status are all verified, the target model server and the corresponding model service key information are determined according to the model identifier, and the model service key information stored on the server side is added to the forwarding request sent to the target model server; if any verification fails, the model access request is rejected and the model service key information is not invoked.

[0014] Furthermore, the client generates or loads a device public-private key pair through a Trusted Platform Module (TPM), Trusted Execution Environment (TEE), security chip, or operating system security key service with key protection capabilities. The device private key is stored in the corresponding key protection environment and its export is restricted. During device registration, the client also submits a client identifier to the proxy server. The proxy server generates a registration challenge based on the user identity information, client identifier, and device public key. The client uses the device private key to sign the registration challenge and information related to this device registration to form device verification information. The proxy server verifies the association between the device verification information, the registration challenge, and the device public key. After successful verification, it registers the device binding relationship and marks the registration challenge as used.

[0015] Furthermore, device-bound access credentials include refresh credentials, access credentials, and gateway credentials. The first holding proof includes refresh holding proof and issuance holding proof. After a user completes identity authentication and device registration for the first time, the proxy server issues refresh credentials and access credentials bound to the same device's public key. The client uses the refresh credentials and the refresh holding proof generated for this refresh request to apply for new refresh credentials and access credentials. After the refresh is completed, the original refresh credentials become invalid. Within the validity period of the access credentials, the client uses the access credentials and the issuance holding proof generated for this gateway credential issuance request to apply for gateway credentials. The gateway credential can be used for one or more model access requests within its own validity period, but each model access request generates a new second holding proof. During normal refresh credential rotation, previously issued access credentials and gateway credentials that are still valid remain valid.

[0016] Furthermore, the information to be signed for refreshing the certificate of possession includes the certificate type, the credential operation type indicating the refresh credential update, and the current refresh credential digest; the information to be signed for issuing the certificate of possession includes the certificate type, the credential operation type indicating the gateway credential issuance, and the current access credential digest. The client organizes the corresponding information to be signed according to the preset field order and encoding rules and signs it using the device private key. The proxy server reconstructs the information to be verified according to the same field order and encoding rules and completes the verification using the corresponding device public key.

[0017] Furthermore, the client includes a model application and a local security agent deployed on the same user device. The model application and the local security agent operate independently and communicate through a local communication interface on the user device. The local security agent communicates with both the security key module and the proxy server. The model application submits a model access request and local access information to the local security agent. The local security agent performs local access verification based on at least one of the following: the current user, the local client session, the model application instance, the model application's process identifier, the application signature, the program file digest, or the identity of the local communication peer. Only for model access requests that have passed local access verification, the agent uses device-bound access credentials and calls the security key module to generate a second holding certificate.

[0018] Furthermore, the information to be signed for the second proof of possession includes the proof type representing the model access request, the model identifier, the request content digest, the current gateway credential digest, the issuance time, and a unique identifier. The request content digest is calculated based on the request body of the model access request, and the gateway credential digest is calculated based on the current gateway credential. The proxy server reconstructs the information to be verified according to the same rules based on the received model access request and gateway credential, verifies the second proof of possession using the device public key bound to the gateway credential, and checks whether the unique identifier has already been used.

[0019] Furthermore, when the proxy server detects that an expired refresh credential has been submitted again, it rejects the corresponding credential update request, records the abnormal use of the refresh credential, and suspends the corresponding client or device from applying for new device binding access credentials. When the device status corresponding to the device public key is updated to an expired state, the proxy server stops issuing new gateway credentials bound to that device public key, and continues to query the device status when receiving model access requests. If the device is in an expired state, it refuses to use the gateway credentials bound to that device public key for model access.

[0020] A second aspect of this invention provides a controlled use system for large model service keys based on device-bound access credentials, comprising a user device, a proxy server, and at least one target model server. The user device includes a model application, a local security proxy, and a security key module. The model application connects to the local security proxy via a local communication interface on the user device. The local security proxy connects to the security key module and communicates with the proxy server. The proxy server communicates with the target model server and stores the device binding relationship between user identity information and device public keys, the device status corresponding to the device public key, and the mapping relationship between model identifiers, target model servers, and model service key information. The local security proxy manages device-bound access credentials bound to the device public key and calls the security key module to generate a first holding certificate for credential requests and a second holding certificate for model access requests. The proxy server verifies the first or second holding certificate based on the device public key bound to the device-bound access credential and queries the device status. After the device-bound access credential, second holding certificate, and device status for model access are all verified, the proxy server determines the target model server and the corresponding model service key information based on the model identifier and adds the model service key information to a forwarding request sent to the target model server.

[0021] A third aspect of the present invention provides a computer-readable storage medium storing program instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform the above-described method for controlled use of a large model service key based on device-bound access credentials.

[0022] Compared to access control methods that rely solely on the validity of the access credentials themselves, this invention establishes a persistent association between the device-bound access credentials and the device's public key. Furthermore, it requires the client to generate a second proof of ownership using the device's private key during both the credential update and model access phases. This second proof of ownership is also associated with the model identifier, the model access request, and the current gateway credential. Therefore, even if the access credential is copied, the party obtaining the credential will find it difficult to complete subsequent credential operations or model access without possessing the corresponding device private key. Simultaneously, the proxy server verifies the device status during both credential issuance and model access. When a device is disabled or its status expires, it can stop issuing new gateway credentials and refuse access to gateway credentials that have not yet expired, thereby reducing the risks of cross-device credential use, replay requests, and continued access after device failure.

[0023] Meanwhile, this invention manages the device-bound access credentials used by the client and the model service key information used by the target model server separately. The model service key information is stored on the server side by the proxy server and is only added to the forwarding request according to the authentication requirements of the target model server after the device-bound access credentials, the second proof of possession, and the device status have all been verified. Therefore, the client does not need to directly save or use the real authentication information of the target model server. Combined with local security proxy for local access verification of model applications, it can also restrict unauthorized programs on the same device from calling the device-bound access credentials and device private key, thereby forming a continuous and controlled access relationship between user identity, device key, access credentials, and model service key. This maintains continuous user access to model services while reducing the risk of unauthorized use of client credentials and model service keys.

[0024] The device status corresponding to the device public key is maintained independently of the validity period and normal rotation status of the refresh credential, access credential, and gateway credential. Normal credential rotation is used to maintain continuous access; when the device status is updated to an invalid state, the gateway credential bound to the device public key that has not yet expired also stops being used for model access. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0026] Figure 1 This is a flowchart of the method for controlled use of a large-scale service key based on device-bound access credentials according to the present invention;

[0027] Figure 2 This is a schematic diagram of the structure of the large-scale service key controlled use system based on device-bound access credentials according to the present invention. Detailed Implementation

[0028] Example 1

[0029] This embodiment provides a method for controlled use of large-scale service keys based on device-bound access credentials.

[0030] like Figure 1 As shown, after user authentication, a device public / private key pair is generated or loaded on the user's device. The proxy server establishes a device binding relationship between the user's identity information and the device's public key, and verifies the holding certificate generated by the device's private key during subsequent credential operations and model access. A model access request only accesses the corresponding target model server by invoking the model service key information stored on the server side if the device-bound access credentials, holding certificate, and device status all meet the requirements. The access credentials used on the client side and the model service key information recognized by the target model server are used for different authentication processes; the model service key information does not need to be configured or stored on the user's device.

[0031] When a user accesses the model service for the first time using the client, authentication is completed through the client. Authentication can be performed directly by the proxy server or by an authentication service communicating with the proxy server, as long as the proxy server can obtain the authenticated user's identity information. User identity information may include a unique user identifier, as well as information about the user's organization, role, or other information related to model access permissions. User authentication is used to determine the current access subject, and device registration, based on this, determines the public key of the device currently used by the user, ensuring that subsequent device access qualifications correspond to the authenticated user identity.

[0032] After user authentication, the client invokes the security key module on the user's device to generate a device public-private key pair. If a usable device public-private key pair already exists in the security key module, it can be directly loaded. The security key module can employ a Trusted Platform Module (TPM), a Trusted Execution Environment (TEE), a security chip, or a security key service of an operating system with key protection capabilities. The device private key is stored in the corresponding key protection environment and its direct export is restricted. When the client needs to perform a signing operation, it submits the corresponding information to be signed to the security key module, which then uses the device private key to complete the signing. The corresponding device public key can then be provided to the client, which submits it to the proxy server. Thus, subsequent access actually requires the ability to invoke the device private key, rather than handing the device private key itself over to the model application or the proxy server.

[0033] During device registration, the client can also submit its client identifier to the proxy server. The proxy server generates a registration challenge corresponding to this device registration based on the obtained user identity information, client identifier, and device public key, and sends the registration challenge to the client. The registration challenge may contain random information generated by the proxy server and is associated with the current user authentication process. After receiving the registration challenge, the client invokes the security key module, uses the device private key to sign the registration challenge and information related to this device registration, forming device verification information, and sends the device verification information to the proxy server.

[0034] After receiving the device authentication information, the proxy server verifies it using the device public key submitted by the client. This confirms that the device authentication information corresponds to the current registration challenge and the current device public key, and checks whether the registration challenge is still valid and has already been used. Upon successful verification, the proxy server establishes a device binding relationship between the user's identity information, client identifier, and device public key, records the device status corresponding to the device public key, and marks the current registration challenge as used. Registration challenges marked as used will not be used for further device registration, thus preventing the direct duplicate submission of already generated device authentication information.

[0035] For example, when a user uses the model application for the first time on a user device that has already completed identity authentication, the security key module generates a device public-private key pair. The device private key is always stored in the key protection environment of that user device, while the proxy server stores the corresponding device public key and the mapping between that device public key and the current user's identity. Even if access credentials from that user device are subsequently copied to other devices, those other devices, without accessing the original device private key, will still be unable to complete the subsequent required proof of ownership using the original device public key.

[0036] After device registration is complete, the proxy server issues an initial device binding access credential to the client, which is bound to the device's public key. This binding allows the proxy server to determine the corresponding device public key from the current device binding access credential and use this device public key to verify whether the client can still access the corresponding device private key during subsequent credential operations and model access. Therefore, the proxy server not only checks the validity of the credential itself but also continues to check the possession status of the device private key corresponding to the credential.

[0037] In one implementation, the device-bound access credentials include refresh credentials, access credentials, and gateway credentials. After a user completes authentication and device registration for the first time, the proxy server issues refresh credentials and access credentials bound to the same device public key to the client. Refresh credentials are used to apply for new refresh credentials and access credentials subsequently, access credentials are used to apply for gateway credentials, and gateway credentials are used to actually send model access requests to the proxy server. Gateway credentials themselves do not contain the model service key information used by the proxy server when accessing the target model server. These three types of credentials function according to different usage stages, ensuring that the credentials used to maintain the user's continuous login status are distinguished from the credentials used when actually sending model requests.

[0038] When a refresh credential needs updating, the client does not request a new credential solely based on the current refresh credential. Instead, it generates a refresh holding certificate for both the current refresh credential and the current refresh request. The information to be signed in the refresh holding certificate includes the certificate type, the credential operation type indicating that the current operation is an update of the refresh credential, and a digest of the current refresh credential. The client organizes the information to be signed according to a preset field order and encoding rules, then calls the security key module to complete the signing using the device's private key, and sends the current refresh credential, the current refresh request, and the refresh holding certificate to the proxy server.

[0039] The proxy server determines the public key of the device bound to the current refresh credential and reconstructs the information to be verified according to the same field order and encoding rules as the client. It then uses the corresponding device public key to verify the refresh holding certificate. Simultaneously, the proxy server queries the current device binding relationship and device status. Only when the refresh credential is valid, the refresh holding certificate is verified successfully, the device binding relationship remains valid, and the corresponding device status meets the credential update conditions, will the proxy server issue a new refresh credential and access certificate, and invalidate the original refresh credential. In this way, even if the refresh credential is copied separately, it cannot be continuously exchanged for subsequent credentials without its bound device.

[0040] When a client needs to request a gateway credential, it initiates a gateway credential issuance request using a valid access credential and generates an issuance holding certificate for this request. The signing information for the issuance holding certificate includes the certificate type, the credential operation type indicating that the current operation is a gateway credential issuance, and a digest of the current access credential. The client organizes the relevant information according to a preset field order and encoding rules, calls the security key module to complete the signing using the device's private key, and then sends the access credential, gateway credential issuance request, and issuance holding certificate to the proxy server.

[0041] The proxy server verifies and issues a holding certificate based on the device's public key corresponding to the access credential, and checks the device binding relationship and device status. Upon successful verification, the proxy server issues a gateway credential bound to the same device's public key. The access credential can be used once or multiple times to request gateway credentials within its validity period, but each gateway credential issuance request regenerates a corresponding issuance and holding certificate. Therefore, gateway credential issuance depends not only on existing access credentials but also on the current user device's actual access to the original device's private key.

[0042] Although both refreshing and issuing a holding certificate are generated from the device's private key, they represent different credential operation types and are associated with the current refresh credential digest and the current access credential digest, respectively. The proxy server reconstructs the information to be verified based on the actual credential request received. Therefore, a holding certificate used for refreshing credential updates cannot be directly used for gateway credential issuance, and a holding certificate used for gateway credential issuance cannot directly replace a refreshing holding certificate. Compared to the approach of forming only one generic device signature, each type of credential operation corresponds to the relevant credential and the current operation.

[0043] During normal refresh credential rotation, previously issued and still valid access credentials and gateway credentials can continue to be used, and normal refresh operations will not automatically interrupt previously obtained short-term access privileges. If the proxy server receives the refresh credential again after the original refresh credential has expired, it will reject the current credential update request. Optionally, the proxy server records the abnormal use of the refresh credential and suspends the corresponding client or device from applying for new device binding access credentials, restoring the corresponding credential application permission only after reconfirming the user's identity and device status. Thus, normal rotation and the reappearance of expired credentials can be handled separately.

[0044] When the client is ready to actually access the model service, it can use Figure 2 The user equipment internal structure shown is such that the model application receives model access content submitted by the user or business program and forms a model access request. The local security agent and the model application operate independently. The model application sends the model access request to the local security agent through the local communication interface on the user equipment. The local security agent is responsible for device binding access credential management, security key module invocation, and network communication with the proxy server.

[0045] When a model application connects to the local security agent for the first time or initiates a model access request, it can simultaneously submit local access information to the local security agent. The local security agent performs local access verification based on at least one of the following: the current user, the local client session, the model application instance, the model application process identifier, the application signature, the program file digest, or the identity of the local communication peer. It can also combine operating system file access permissions and local inter-process communication permissions to restrict which programs can connect to the local security agent. Only model access requests that pass local access verification are allowed to continue using the device binding access credentials managed by the local security agent and to call the security key module to generate a second holding certificate. If local access verification fails, the local security agent directly rejects the current model access request and does not call the device private key.

[0046] In one specific implementation, the local security agent uses the local inter-process communication peer credentials provided by the operating system to obtain the initiating process identifier and executable file information, and checks the application signature or program file digest against the pre-registered value; only when the check passes is the process allowed to continue calling the device binding access credentials and security key module.

[0047] After obtaining the currently valid gateway credentials, the local security agent generates a second holding certificate based on the current model access request. The information to be signed in the second holding certificate includes the certificate type representing the model access request, the model identifier, the request content digest, the current gateway credential digest, the issuance time, and a unique identifier. The request content digest is calculated based on the request body of the current model access request, and the gateway credential digest is calculated based on the current gateway credential. The client organizes the above information to be signed according to a preset field order and encoding rules, and calls the security key module to complete the signing using the device's private key. These fields ensure that the second holding certificate simultaneously corresponds to the current device, the current gateway credential, and the current model request.

[0048] For example, when the current gateway credentials are used to send a model access request to a target model, the local security proxy forms a pending signature information based on the model identifier, the request content digest calculated from the current request body, the current gateway credential digest, the issuance time, and the unique identifier. If the model identifier or the content of the model access request is changed after signing, the pending verification information recalculated by the proxy server based on the actual received request will change, and the original second holding certificate will fail verification. If the request content remains unchanged and the second holding certificate is resent, the proxy server can still determine whether the holding certificate has been used based on the unique identifier.

[0049] Optionally, the second proof of possession can be further associated with one or more of the following: request method, request path, target address, client identifier, or device public key fingerprint. The second proof of possession can be in DPoP form or other signature methods that enable the proxy server to verify the device private key possession relationship and associate it with the current model request. Regardless of the specific form, the second proof of possession is used for model access requests, and the first proof of possession is used for credential operations; they have different proof types. During verification, the proxy server combines the proof type, credential operation type, and current request information to determine whether the first proof of possession generated for credential operations can be used for model access, and whether the second proof of possession generated for model access can be used to refresh credentials or request gateway credentials.

[0050] After completing the second proof of possession, the local security agent sends a model access request, the current gateway credential, and the second proof of possession to the proxy server. The proxy server first verifies the gateway credential to obtain the device public key bound to it. Then, based on the current model access request and the gateway credential, it reconstructs the information to be verified corresponding to the second proof of possession according to the same field order and encoding rules. Finally, it verifies the second proof of possession using the device public key bound to the gateway credential.

[0051] The proxy server also checks the issuance time and unique identifier in the secondary holding certificate. The issuance time is used to determine whether the current secondary holding certificate is still within the allowed usage period, and the unique identifier is used to distinguish different model access requests. When the proxy server finds that the current unique identifier has already been used, it rejects the current model access request; for a unique identifier that appears for the first time and is verified, it is recorded as already used after accepting the current model access request. Although the gateway credential can be used for one or more model access requests within its own validity period, a new secondary holding certificate is generated for each model access, therefore the reuse of the gateway credential is distinguished from the reuse of the secondary holding certificate.

[0052] To prevent the same unique identifier from being passed repeatedly in concurrent requests, the server uses atomic processing for checking the unused state and writing the used state of the unique identifier; for the same unique identifier arriving at the same time, only the request that completes verification for the first time is allowed to continue.

[0053] In addition to verifying gateway credentials and second-level proof of ownership, the proxy server also queries the device status corresponding to the public key of the device bound to the gateway credential. When the device is in normal use, the device status remains valid; if the device is lost, disabled, or its access privileges need to be revoked, the proxy server updates the device status to invalid. Once the device status becomes invalid, the proxy server stops issuing new gateway credentials for that device's public key and continues to query the device status when already issued gateway credentials are actually used for model access. Therefore, even if a gateway credential has not yet reached its expiration date, the proxy server will still reject model access requests if the corresponding device is currently invalid.

[0054] The above process makes the validity period of the gateway credential and whether the device is still eligible to access two separate verification conditions. The fact that a gateway credential has not yet expired does not automatically mean that the device it is bound to is still valid; similarly, if a device becomes invalid, there is no need to wait for the already issued gateway credential to expire naturally before stopping the corresponding access.

[0055] Once the gateway credentials, second proof of possession, and device status have all been verified, the proxy server reads the model identifier from the model access request and queries the model service mapping relationship maintained on the server side. The model service mapping relationship records at least the correspondence between the model identifier, the target model server, and the corresponding model service key information. Depending on the actual interface requirements of the target model server, it can also further store information such as the target model server address, request path, or interface format.

[0056] Model service key information may include API Key, Bearer Token, short-term service credentials, or other authentication information recognized by the target model server. This model service key information is stored on the server side by the proxy server, separate from the refresh credentials, access credentials, and gateway credentials held by the client. Gateway credentials are used by the client to prove access rights to the proxy server, while the model service key information is used by the proxy server to complete upstream authentication with the target model server. Therefore, the client does not need to store separate model service key information for different target model servers.

[0057] When a proxy server forwards a model access request to a target model server, it first removes the gateway credentials, second-party proof of ownership, and other information submitted by the client that is only used for authentication between the client and the proxy server. Then, it adds the corresponding model service key information to the forwarding request according to the authentication format required by the target model server. For interface differences between different target model servers, the proxy server can also adapt the request path, model identifier, request header, or interface format based on the model service mapping relationship, sending the adapted request to the target model server while keeping the business content expressed by the model access request unchanged.

[0058] For example, when the same model application requests two different model services sequentially, the user device can continue to use the local security proxy for access without needing to configure two sets of real model service keys separately in the model application. For the first model request, the local security proxy generates a second holding certificate corresponding to the first model identifier, the first model request, and the current gateway credentials. After verification, the proxy server obtains the model service key information corresponding to the first model server. When subsequently requesting the second model, the local security proxy regenerates the second holding certificate for the new model identifier and model access content. The proxy server then verifies the second model server and the corresponding model service key information. The second holding certificate from the previous model request cannot directly replace the second holding certificate from the subsequent model request, and the model service keys of the two target model servers do not need to be sent to the client.

[0059] After receiving the request from the proxy server, the target model server completes authentication and processes the model access request based on the model service key information, and returns the model response to the proxy server. The proxy server then sends the model response to the client; in the implementation using a local security proxy, the model response is first returned to the local security proxy, and then the local security proxy passes it to the model application through the local communication interface.

[0060] When gateway credential verification fails, the second holding certificate cannot be verified by the corresponding device public key, the unique identifier in the second holding certificate is already in use, or the device is in an invalid state, the proxy server directly rejects the current model access request, does not invoke the model service key information corresponding to the model identifier, and does not generate a forwarding request with the model service key information to the target model server. Therefore, the invocation of the model service key information is constrained by the client device access verification result, rather than being directly read and used by the proxy server after receiving any model access request.

[0061] Optionally, the proxy server can also maintain model access permissions for different users, user groups, or models based on the user identity information associated with the gateway credentials. When the model identifier in a model access request does not belong to the range of models that the current user is allowed to access, the proxy server rejects the current model access request. The proxy server can also record audit information such as user identifier, client identifier, device public key fingerprint, model identifier, request time, unique identifier, verification result, replay event, and response status, while device private key, model service key information, and model access business content that does not need to be retained are not required content in the above audit records.

[0062] Encrypted communication connections can be established between the client and the proxy server, and between the proxy server and the target model server. The proxy server, acting as the endpoint for the client's access connection, parses the device-bound access credentials, the second proof of possession, the model identifier, and the information required for routing and authentication, then reorganizes the upstream request in a format acceptable to the target model server. The client's device authentication information is not directly used as the target model server's authentication information, and the target model server's model service key information is not returned to the user device as part of the client's device-bound access credentials.

[0063] Through the above methods, after a user completes identity authentication and device registration, they can maintain continuous access by relying on the normal rotation of refreshed credentials. Each credential operation still requires a corresponding first holding certificate, and each model access still requires the regeneration of a second holding certificate for the current request. If a device fails, the proxy server can stop issuing new gateway credentials and prevent the continued use of gateway credentials that have not yet expired. The model service key information used by the target model server is always stored on the server side and is only used for the corresponding model service access after the device binding access credential, second holding certificate, and device status verification are passed. Thus, user identity, device private key, device binding access credential, and model service key information are managed separately within their respective scopes, while the necessary association verification and request conversion are completed at the proxy server.

[0064] Example 2

[0065] This embodiment provides a large-scale service key controlled use system based on device-bound access credentials.

[0066] like Figure 2 As shown, the system includes a user device, a proxy server, and at least one target model server. The user device is located on the client side, and the proxy server is positioned between the user device and the target model server, establishing communication connections with both the user device and the target model server. When the system accesses multiple model services, the proxy server can simultaneously communicate with target model server 1, target model server 2, up to target model server N, and select the actual target model server to access based on the model identifier in the model access request.

[0067] The user equipment includes a model application, a local security agent, and a security key module. The model application and the local security agent are located on the same user equipment and operate independently. The model application connects to the local security agent through a local communication interface on the user equipment. The model application receives model access content from user input or business programs and sends corresponding model access requests to the local security agent through the local communication interface. Model responses returned by the target model server can also be transmitted to the model application via the proxy server and the local security agent.

[0068] The local security agent connects to both the security key module and the proxy server. The local security agent and the security key module have a device key access relationship, used to obtain the device's public key and request the use of the device's private key for signing. The local security agent and the proxy server have a network communication relationship, used to complete device registration, application and update of device binding access credentials, gateway credential issuance requests, and the sending of actual model access requests. Therefore, the model application mainly handles model business content, while the local security agent centrally manages access credentials and device key access; the model application itself does not need to obtain the device's private key.

[0069] The security key module is located within the user device and can utilize TPM, TEE, a security chip, or the operating system's security key service. The security key module generates or loads the device's public-private key pair. The device's private key is stored in a key-protected environment and its export is restricted, while the device's public key is provided to the local security agent. When a first or second proof of possession is required, the local security agent sends the corresponding information to be signed to the security key module, which then uses the device's private key to complete the signing and returns the signature result. Therefore, in terms of system architecture, the local security agent calls the security key module, while the model application does not directly exchange device private keys with the security key module.

[0070] The local security agent also manages device binding access credentials that are tied to the device's public key. After a user completes authentication and device registration for the first time, the local security agent receives and manages refresh credentials and access credentials issued by the agent server. When refresh credentials need to be updated, the local security agent calls the security key module to generate a refresh holding certificate. When requesting gateway credentials, the local security agent calls the security key module to generate an issuance holding certificate. When a model application initiates model access, the local security agent obtains the current gateway credentials and calls the security key module to generate a second holding certificate.

[0071] To restrict unauthorized programs on the same user device from using the local security agent, the local security agent can also leverage operating system file access permissions and local inter-process communication permissions to restrict programs capable of establishing local connections. Furthermore, it performs local access verification based on at least one of the following: the model application's process identifier, application signature, program file digest, or the identity of the local communication peer. Only when the model application meets the local access requirements will the local security agent allow it to use device-bound access credentials and request the security key module to generate a second proof of possession.

[0072] The proxy server communicates with the local security proxy and with each target model server. The proxy server maintains the device binding relationship between user identity information and device public keys, and maintains the device status corresponding to each device public key. The device binding relationship is used to determine the currently registered device based on the user identity and device public key, and the device status is used to determine whether the device is still allowed to apply for and use the corresponding access credentials.

[0073] The proxy server also maintains model service mapping relationships. These mapping relationships include at least the correspondence between model identifiers, target model servers, and model service key information, and can be further associated with request paths or interface formats as needed for different model service interfaces. These model service mapping relationships, stored and queried by the proxy server, are used to determine the actual target model server and corresponding authentication information to be accessed after verification is completed on the device side, rather than being a separate functional entity located on the user device.

[0074] When the local security agent initiates a credential operation with the proxy server, the proxy server determines the public key of the bound device based on the device-bound access credential, verifies the first proof of possession using the device's public key, and simultaneously queries the device binding relationship and device status. If the corresponding verification requirements are met, the proxy server updates the device-bound access credential or issues a new gateway credential. If the device status has expired, the proxy server will no longer issue a new gateway credential for the corresponding device public key.

[0075] When accessing a model, the model application first sends the model access request to the local security proxy via the local communication interface. The local security proxy performs local access verification, obtains the currently valid gateway credentials, and calls the security key module to generate a second holding certificate associated with the current model access request, model identifier, and gateway credentials. Subsequently, the local security proxy sends the model access request, gateway credentials, and second holding certificate through the communication connection with the proxy server.

[0076] After receiving the above data, the proxy server verifies the second holding certificate using the device public key bound to the gateway credential and queries the corresponding device status. If the gateway credential, the second holding certificate, and the device status all meet the requirements, the proxy server queries the model service mapping relationship based on the model identifier to determine the corresponding target model server and model service key information, and then forms a forwarding request according to the authentication requirements of the target model server. If the device status has expired, even if the user device still retains an unexpired gateway credential, the proxy server will not use that gateway credential to access the target model server by invoking the model service key information.

[0077] When the proxy server sends a forwarding request to the target model server, it removes the device-bound access credentials, secondary proof of possession, and other information submitted by the client that is only used for authentication between the client and the proxy server, and adds the model service key information stored on the server side to the forwarding request. This ensures that the authentication information between the user device and the proxy server is distinguished from the authentication information between the proxy server and the target model server. Figure 2 The communication between the user equipment and the proxy server shown does not serve to issue model service key information to the user equipment.

[0078] For example, when the model application needs to access Figure 2 When accessing target model server 2, the local security agent generates a second holding certificate for the current model access request and sends it to the proxy server. After completing the corresponding device verification, the proxy server determines target model server 2 and its corresponding model service key information from the model service mapping relationship based on the model identifier, and then forms a forwarding request to be sent to target model server 2. When subsequently accessing target model server 1, the local security agent regenerates the second holding certificate based on the new model access request, and the proxy server then selects target model server 1 and its corresponding model service key information based on the new model identifier. The real authentication information between different model services is managed uniformly by the proxy server and does not need to be stored separately in the model application.

[0079] After the target model server completes authentication and processes the model access request, it returns the model response to the proxy server. The proxy server then sends the model response to the local security proxy, which in turn provides it to the model application through a local communication interface. In this process, the model application does not directly obtain the device private key and model service key information. The local security proxy is responsible for local access verification, device binding access credential management, and device private key invocation. The security key module is responsible for storing the device private key and performing the corresponding signature. The proxy server is responsible for verifying the device binding relationship and device status, and after successful verification, determines the target model server and the corresponding model service key information. Therefore, even if the device binding access credential is obtained separately, proof of possession still needs to be completed using the corresponding device private key. When the device status becomes invalid, the proxy server can also refuse existing gateway credentials from being used for model access.

[0080] Example 3

[0081] This embodiment provides a computer-readable storage medium storing program instructions. When these instructions are read and executed by one or more computing devices, they cause the devices to perform the controlled use method for large model service keys based on device-bound access credentials as described in Embodiment 1. The program instructions can be executed by the computing devices corresponding to the user device and the proxy server, respectively, depending on their deployment location. This enables the user device to complete identity authentication interaction, device key invocation, device-bound access credential management, and proof of ownership generation. It also enables the proxy server to maintain device binding relationships, query device status, verify proof of ownership, query model service mappings, and access the target model server.

[0082] The computer-readable storage medium can be a storage medium capable of storing program instructions and allowing a computing device to read and execute them. During program execution, the user device and the proxy server exchange device binding access credentials, possession certificates, and model access requests in the manner described above. After verifying the access qualifications of the corresponding device, the proxy server uses the server-side model service key information to access the target model server, thereby realizing the controlled use process of the model service key corresponding to Embodiments 1 and 2.

Claims

1. A method for controlled use of a large model service key based on device-bound access credentials, characterized in that, Includes the following steps: S1. The user completes identity authentication through the client. The client calls the security key module on the user's device to generate or load the device's public and private key pair. The proxy server obtains the authenticated user's identity information and device public key, establishes a device binding relationship between the user's identity information and the device public key, records the device status corresponding to the device public key, and issues an initial device binding access credential bound to the device public key. S2. When the device binding access credential needs to be updated or reissued, the client uses the device private key to generate a first holding certificate for the current device binding access credential and the current credential request, and submits the device binding access credential, the current credential request, and the first holding certificate to the proxy server; the proxy server uses the device public key bound to the device binding access credential to verify the first holding certificate, and verifies the device binding relationship and device status. After successful verification, it updates or reissues the device binding access credential bound to the same device public key. S3. The client receives the model access request, uses the device private key to generate a second holding certificate associated with the device binding access credential, model identifier and model access request used for this model access, and sends the model access request, device binding access credential and second holding certificate to the proxy server. S4. The proxy server verifies the device binding access credential and the second holding proof, and queries the device status corresponding to the device public key; after the device binding access credential, the second holding proof and the device status are all verified, the target model server and the corresponding model service key information are determined according to the model identifier, and the model service key information stored on the server side is added to the forwarding request sent to the target model server. If any verification fails, the model access request is rejected and the model service key information is not invoked.

2. The method for controlled use of large-scale service keys based on device-bound access credentials according to claim 1, characterized in that: The security key module includes a Trusted Platform Module (TPM), a Trusted Execution Environment (TEE), a security chip, or a security key service of an operating system with key protection capabilities. The security key module stores the device private key and restricts the export of the device private key. In step S1, the client also submits its client identifier to the proxy server, which generates a registration challenge based on the user's identity information, the client identifier, and the device's public key. The client calls the security key module and uses the device private key to sign the registration challenge and information related to this device registration to generate device verification information; The proxy server verifies the association between the device authentication information, the registration challenge, and the device public key. After successful verification, it establishes a device binding relationship between the user identity information, the client identifier, and the device public key, and marks the registration challenge as used.

3. The method for controlled use of large-scale service keys based on device-bound access credentials according to claim 1, characterized in that: The device-bound access credentials include refresh credentials, access credentials, and gateway credentials; the first holding proof includes refresh holding proof and issued holding proof. After a user completes identity authentication and device registration for the first time, the proxy server issues a refresh credential and a pass credential bound to the same device's public key; The client uses the refresh credential and the refresh holding certificate generated for this refresh request to apply for a new refresh credential and access credential. After the refresh is successful, the original refresh credential becomes invalid. Within the validity period of the access credential, the client uses the access credential and the issuance holding certificate generated for this gateway credential issuance request to apply for a gateway credential. The gateway credential is used for one or more model access requests within its own validity period, and a second holding certificate is generated for each model access request. When refreshing credentials, previously issued and still valid access credentials and gateway credentials remain valid.

4. The method for controlled use of large-scale service keys based on device-bound access credentials according to claim 3, characterized in that: The information to be signed for refreshing the certificate of ownership includes the certificate type, the certificate operation type indicating the refresh certificate update, and the current refresh certificate summary; The information to be signed for issuing a certificate of possession includes the certificate type, the credential operation type indicating the issuance of the gateway credential, and the current access credential summary; The client organizes the corresponding information to be signed according to the preset field order and encoding rules, and calls the security key module to sign it using the device private key; the proxy server reconstructs the information to be verified according to the same field order and encoding rules, and verifies the signature using the corresponding device public key.

5. The method for controlled use of large-scale service keys based on device-bound access credentials according to claim 1, characterized in that: The client includes a model application and a local security agent deployed on the same user device. The model application and the local security agent run independently of each other and communicate through the local communication interface on the user device. The local security agent communicates with the security key module and the proxy server respectively. The model application submits a model access request and local access information to the local security agent. The local security agent performs local access verification based on at least one of the following: the current user, the local client session, the model application instance, the model application process identifier, the application signature, the program file digest, or the identity of the local communication peer. Only for model access requests that pass local access verification, the agent uses device-bound access credentials and calls the security key module to generate a second holding certificate.

6. The method for controlled use of large-scale service keys based on device-bound access credentials according to claim 3, characterized in that: The signature information of the second proof of possession includes the proof type, model identifier, request content digest, current gateway credential digest, issuance time and unique identifier; The request content digest is calculated based on the request body of the model access request, and the gateway credential digest is calculated based on the current gateway credential. The client organizes the information to be signed according to a preset field order and encoding rules and signs it using the device private key. The proxy server reconstructs the information to be verified according to the same rules based on the received model access request and gateway credentials, verifies the second holding certificate using the device public key bound to the gateway credentials, and checks whether the unique identifier has been used. If the reconstructed information to be verified does not match the second holding certificate or the unique identifier has been used, the model access request is rejected.

7. The method for controlled use of large-scale service keys based on device-bound access credentials according to claim 3, characterized in that: When the proxy server detects that an expired refresh credential has been submitted again, it rejects the corresponding credential update request, records the abnormal use of the refresh credential, and suspends the corresponding client or device from applying for new device binding access credentials. After the proxy server updates the device status corresponding to the device public key to an invalid state, it stops issuing new gateway credentials bound to the device public key and queries the device status when receiving model access requests. When the device is in an invalid state, it refuses to use the gateway credentials bound to the device public key for model access, even if the gateway credentials are still within their validity period.

8. A large model service key controlled use system based on device binding access credential, characterized in that, Includes user equipment, proxy server, and at least one target model server; The user equipment includes a model application, a local security agent, and a security key module. The model application connects to the local security agent through the local communication interface on the user equipment. The local security agent connects to the security key module and communicates with the agent server. The security key module is used to store the device private key and provide the corresponding device public key to the local security agent. The proxy server communicates with the target model server and stores the device binding relationship between user identity information and device public key, the device status corresponding to the device public key, and the mapping relationship between model identifier, target model server and model service key information; The local security agent is configured to manage device-bound access credentials that are bound to the device's public key, and calls the security key module to generate a first holding certificate for credential requests and a second holding certificate for model access requests; The proxy server is configured to verify the first or second holding certificate based on the device public key bound to the device binding access credential, and query the device status. After the device binding access credential, the second holding certificate, and the device status used for model access are all verified, the corresponding target model server and model service key information are determined based on the model identifier in the model access request, and the model service key information is added to the forwarding request sent to the target model server.

9. The large-scale service key controlled use system based on device-bound access credentials according to claim 8, characterized in that: The model application is used to submit model access requests to the local security agent, which is used to manage device binding access credentials. The model application does not obtain the device private key. The local security agent performs local access verification on the model application that initiates the model access request by using at least one of the following: operating system file access permissions, local inter-process communication permissions, and the process identifier, application signature, program file digest, or identity of the local communication peer of the model application. The model service key information is stored on the server side by the proxy server. When the proxy server forwards the model access request to the target model server, it removes the device binding access credential, the second holding certificate, and the information used only for authentication between the client and the proxy server submitted by the client, and adds the corresponding model service key information to the forwarding request according to the authentication requirements of the target model server.

10. A computer readable storage medium, characterized in that, A computer-readable storage medium stores program instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform the controlled use method of a large model service key based on device-bound access credentials as described in any one of claims 1-7.

Images