A method for secure creation and deployment of DDS security certificates

Abstract

The application discloses a DDS Security certificate security creation and deployment method, a certificate management service (CMS) is initialized, a secure channel with a trusted execution environment (TEE) is established, and a preset DDS identity CA root certificate is loaded from the TEE; an application package manager (APM) parses application configuration information, carries an application identity ID, and initiates a certificate creation request to the CMS; the CMS constructs certificate information, sends the certificate creation request carrying the certificate information and the application identity ID to the trusted execution environment; a public and private key is generated in the TEE, a certificate is created and issued, and the created application identity certificate is returned to the CMS; the certificate management service verifies the certificate and stores the same, and returns the identity certificate and the CA root certificate to the APM; and the APM installs the identity certificate to a specified folder of an application installation directory. The application creates and deploys the identity certificate based on the CMS and the TEE, simplifies a certificate management process and improves deployment efficiency.

Description

Technical Field

[0001] This invention relates to the DDS security mechanism, and more particularly to a method for securely creating and deploying DDS Security certificates. Background Technology

[0002] With the development of intelligent connected vehicles, the security of data communication between in-vehicle systems has become increasingly important. As a key communication middleware, DDS (Data Distribution Service) relies primarily on identity certificates for authentication through its security mechanism (the DDSSecurity specification proposed by OMG).

[0003] If the application uses DDS Security, there is a risk of private key leakage if the certificate and private key are included when the application package is released, which is extremely dangerous. If the certificate and private key are deployed manually after deployment, there is also a risk of private key leakage, and it is very cumbersome and prone to errors.

[0004] CN111031012B proposes managing digital certificates through a microservice for authentication files. The certificate file is downloaded from the microservice to a specified directory through configuration information. However, each node can only have one set of certificates, and it uses the UserDataQosPolicy field in DDS, which loses the universality of DDS.

[0005] To address the aforementioned issues, a secure, flexible, and controllable solution is needed to deploy DDS Security's digital certificates / private keys. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the present invention aims to provide a method for secure creation and deployment of DDS Security certificates.

[0007] To achieve the objectives of this invention, the technical solution adopted is as follows:

[0008] A method for securely creating and deploying DDS Security certificates, comprising the following steps:

[0009] (1) Initialize the Certificate Management Service (CMS), establish a secure channel with the Trusted Execution Environment (TEE), and load the pre-installed DDS identity CA root certificate from the TEE;

[0010] (2) The Application Package Manager (APM) parses the application configuration information, carries the application identity ID, and sends a certificate creation request to the CMS;

[0011] (3) The Certificate Management Service (CMS) constructs certificate information and sends the certificate creation request carrying the certificate information and the application identity ID to the Trusted Execution Environment (TEE);

[0012] (4) Generate RSA public and private keys in the Trusted Execution Environment (TEE), create and issue a certificate, and return the created application identity certificate to the CMS;

[0013] (5) The Certificate Management Service (CMS) verifies and stores the certificate, and returns the identity certificate and CA root certificate to the APM;

[0014] (6) The Application Package Manager (APM) installs the identity certificate and CA root certificate into the specified folder in the application installation directory.

[0015] Further, in step (2), specifically, the access / UnifiedAccess.json configuration file is parsed, the security.dds.enable field is checked to see if it is "on", the security.dds.ID field is extracted as the application identity identifier, a certificate creation request containing the application identity ID is constructed, the CMS interface is called, and the certificate creation request is initiated.

[0016] Furthermore, in step (3), the Certificate Management Service (CMS) constructs certificate information specifically including: generating a unique certificate serial number, constructing certificate subject information, wherein the CN field is set to the application identity ID, setting the certificate validity period and signature algorithm, and setting certificate extension information.

[0017] Further, in step (4), specifically, an exclusive asymmetric public-private key pair is generated for the application identity ID in the TEE, and the generated private key is bound to the application identity ID and stored in the TEE; the public key is embedded in the certificate structure, a certificate is created based on the certificate information, the certificate is signed using the preset CA private key, and the created application identity certificate is returned to the CMS.

[0018] Further, in step (6), specifically, the generated identity certificate is stored in the conf / dds / directory and named identity_app.pem; the identity CA root certificate is stored in the conf / dds / directory and named identity_ca.pem; APM sets the access permissions of the certificate file so that only the application process can read it.

[0019] Furthermore, after the application is installed and deployed, the application identity certificate, DDS permission file, private key, and application identity ID are associated:

[0020] Identity certificate binding: In conf / dds / identity_cert.pem, certificate CN = application identity ID;

[0021] Permissions file binding: In conf / dds / permissions.p7s, the principal information CN = application identity ID;

[0022] Private key access binding: Access via application identity ID.

[0023] Furthermore, when an application with the same application ID undergoes a version update or reinstallation, the system employs a certificate reuse mechanism, specifically:

[0024] The Application Package Manager (APM) parses the UnifiedAccess.json configuration file of the new version of the application, extracts the application identity ID, and sends a certificate creation request to the Certificate Management Service (CMS). The CMS queries the local certificate to check if the corresponding identity certificate exists. If the local certificate exists, it checks the validity of the certificate and whether the corresponding private key binding relationship exists in the TEE. If so, the CMS skips the TEE certificate generation and private key creation steps and directly sends the existing application identity certificate and CA root certificate content to the APM. The APM copies the certificate to the corresponding directory and sets access permissions.

[0025] A DDS Security certificate security creation and deployment system includes an Application Package Manager (APM), a Certificate Management Service (CMS), and a Trusted Execution Environment (TEE).

[0026] The Application Package Manager (APM) is responsible for parsing application configuration information and initiating certificate creation requests.

[0027] Certificate Management Service (CMS) is responsible for constructing and managing certificate information and has a built-in access control module.

[0028] The Trusted Execution Environment (TEE) is responsible for private key generation and certificate signing.

[0029] The beneficial effects of this invention are that, compared with the prior art, this invention, based on CMS and TEE, realizes the creation and deployment of DDS identity certificates / private keys, simplifies the application configuration and deployment process, simplifies the certificate management process, and improves deployment efficiency.

[0030] Based on the flexibility and security features of TEE, this invention ensures that private keys are securely stored and used in TEE, providing a more secure way to use keys and effectively solving the problem of leakage of application DDS identity certificates and private keys during propagation, deployment and use.

[0031] This invention achieves access control by binding application identity IDs to application permission files and application identity certificates, thus preventing the abuse of permission files. Furthermore, this invention utilizes a certificate reuse mechanism to avoid duplicate creation during application updates, enabling rapid deployment. Attached Figure Description

[0032] Figure 1 This is a flowchart of the DDS Security certificate security creation and deployment method described in this invention;

[0033] Figure 2 This is a diagram illustrating the DDS Security identity authentication process. Detailed Implementation

[0034] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of this application.

[0035] The DDS Security certificate security creation and deployment system described in this invention mainly includes the following components: Application Package Manager (APM), Certificate Management Service (CMS), and Trusted Execution Environment (TEE);

[0036] The Application Package Manager (APM) is responsible for parsing application configuration information and initiating certificate creation requests.

[0037] Certificate Management Service (CMS) is responsible for constructing and managing certificate information and has a built-in access control module.

[0038] The Trusted Execution Environment (TEE) is responsible for private key generation and certificate signing.

[0039] like Figure 1 As shown, the present invention provides a method for securely creating and deploying DDS Security certificates, comprising the following steps:

[0040] 1. Initialize the Certificate Management Service (CMS);

[0041] The system pre-configures the DDS identity CA root certificate and private key in the Trusted Execution Environment (TEE) to issue identity certificates for applications, thereby achieving identity authentication for OMG DDS Security.

[0042] When the Certificate Management Service (CMS) initializes, it establishes a secure channel with the TEE and loads the pre-configured DDS identity CA root certificate from the TEE.

[0043] CMS loads the permission configuration, initializes the access control module, and restricts application access to the private key. The permission configuration format is as follows:

[0044] {

[0045] "default": "deny",

[0046] "access_rules": {

[0047] "allow_list": [

[0048] {"7fda6a629a985838bf0caa1e6219b860": { "interval": "1s"}},

[0049] {"64d5e4b6d2ecb7ab299fe43466fb63c5": { "interval": "1s"}},

[0050] {"1521ec3185c35e445174a55686ebb45b": {"interval": "1s"}}

[0051] ],

[0052] "deny_list": []

[0053] }

[0054] The default permission policy is to deny all access requests, only allow application identity IDs under access_rules.allow_list to access the corresponding private key, and restrict the access interval of the private key.

[0055] 2. The Application Package Manager (APM) sends a certificate creation request to the CMS;

[0056] When an application is installed, the application package manager (APM) will call the CMS interface to initiate a certificate creation request based on the application configuration information, carrying the application's unique application identity ID (AppID).

[0057] Specifically, the access / UnifiedAccess.json configuration file is parsed, the security.dds.enable field is checked to see if it is "on", the security.dds.ID field is extracted as the application identity identifier, and a certificate creation request containing the application identity ID is constructed.

[0058] In access / UnifiedAccess.json, specify DDS security requirements using the following configuration:

[0059] {

[0060] "security": {

[0061] "dds": {

[0062] "enable": "on",

[0063] "ID": "7fda6a629a985838bf0caa1e6219b860"

[0064] }

[0065] }

[0066] }

[0067] The ID field "7fda6a629a985838bf0caa1e6219b860" is the application's unique identifier and is used as a key parameter for certificate creation.

[0068] 3. The Certificate Management Service (CMS) constructs certificate information and sends the application identity ID carrying the certificate creation request to the Trusted Execution Environment (TEE).

[0069] The Certificate Management Service (CMS) constructs certificate information by: generating a unique certificate serial number, constructing certificate subject information, where the CN field is set to the application identity ID, setting the certificate validity period and signature algorithm, and setting certificate extension information.

[0070] The certificate structure is designed based on the application identity ID. The certificate adopts the X.509 v3 standard and is constructed in combination with application configuration information. The specific fields are as follows:

[0071] 1. Basic Information

[0072] Version number: X.509 v3

[0073] Serial Number: Generated based on the hash value of the application identity ID "7fda6a629a985838bf0caa1e6219b860"

[0074] Signature algorithm: RSA-SHA256

[0075] Issuer: Pre-installed DDS Identity CA Root Certificate

[0076] 2. Subject Information

[0077] CN (Common Name): Application Identity ID "7fda6a629a985838bf0caa1e6219b860"

[0078] O (Organization): The organization name that is the same as the CA root certificate.

[0079] OU (Organizational Unit): DDS application type identifier

[0080] C (Country): The same country code as the CA root certificate.

[0081] 3. Extended Information

[0082] Basic Constraints: CA=FALSE, identified as the terminal entity certificate.

[0083] Key Usage:

[0084] Digital Signature: Used for signing DDS messages

[0085] Key Encipherment: Used for key exchange

[0086] 4. Generate RSA public and private keys in the Trusted Execution Environment (TEE), issue a certificate, and return the created application identity certificate to the CMS;

[0087] In the TEE, a 2048-bit RSA key pair, including a public key and a private key, is generated for the application identity. The generated private key is bound to the application identity ID and stored in the TEE. The public key is embedded in the certificate structure. A certificate is created based on the certificate information. The certificate is signed using a pre-set CA private key. The created application identity certificate is returned to the CMS.

[0088] 5. CMS verifies the validity of the certificate and stores it, while returning the identity certificate and CA root certificate to APM;

[0089] CMS establishes a mapping relationship between application identity ID and application certificate / private key, stores it in the internal permission database, generates access control rules for the application, and restricts the certificate / private key to be accessible only to the bound application.

[0090] 6. APM installs the identity certificate and CA root certificate into a specified folder within the application's installation directory;

[0091] APM stores the generated identity certificate in the conf / dds / directory and names it identity_app.pem; APM stores the identity CA root certificate in the conf / dds / directory and names it identity_ca.pem; APM sets the access permissions for the certificate files so that only the application process can read them.

[0092] The application installation directory uses a standardized structure and contains the following key directories and files:

[0093] app_install_dir /

[0094] ├── access /

[0095] │ └── UnifiedAccess.json # Application permission configuration information

[0096] ├── bin /

[0097] │ └── app_run # Application executable file

[0098] ├── conf /

[0099] │ ├── app.json # Basic application configuration

[0100] │ └── dds / # DDS Security Configuration Directory

[0101] │ ├── governance.p7s # DDS Security permissions configuration file

[0102] │ ├── perm_ca.pem # DDS Security Permission CA Certificate

[0103] │ └── permissions.p7s # DDS Security permissions configuration file

[0104] └── lib /

[0105] └── libapp.so # Application library file

[0106] The `conf / dds` directory only exists when the application has DDS Securty configured. After certificate creation, the APM module will deploy the application identity certificate to the `conf / dds` directory.

[0107] When creating the `conf / dds / permissions.p7s` file, the application identity ID is written as the `CN` field in the main information. The binding between `permissions.p7s` and the application identity ID is completed during the application development and packaging phases, not dynamically during installation. The content of the permission file is fixed during application packaging; any tampering with the permission file will cause DDSSecurity to fail to load.

[0108] After the application is installed and deployed, the following relationships are established between the application identity ID, application identity certificate, DDS permission file, and private key:

[0109] Identity certificate binding: In conf / dds / identity_cert.pem, certificate CN = application identity ID;

[0110] Permissions file binding: In conf / dds / permissions.p7s, the principal information CN = application identity ID;

[0111] Private key access binding: Access via application identity ID.

[0112] When an application with the same application identity ID "7fda6a629a985838bf0caa1e6219b860" undergoes a version update or reinstallation, the system employs a certificate reuse mechanism to avoid duplicate creation of certificates and private keys.

[0113] 1. Application update detection;

[0114] APM parses the UnifiedAccess.json configuration file of the new version application, extracts the application identity ID, and sends a certificate creation request to the CMS.

[0115] 2. Certificate existence verification;

[0116] CMS queries the local certificate to check if the corresponding identity certificate exists. If the local certificate exists, it checks the validity of the certificate and whether the corresponding private key binding relationship exists in the TEE.

[0117] 3. Certificates can be reused directly;

[0118] By skipping the TEE certificate generation and private key creation steps, CMS directly sends the existing application identity certificate and CA root certificate content to APM. APM then copies the certificate to the corresponding directory and sets access permissions.

[0119] OMG DDS Security's authentication process requires using a private key to sign data and prove identity. The private key signing process is as follows: Figure 2 As shown:

[0120] The application starts the DDS Security plugin and verifies the consistency between the principal information in the permission file and the principal information of the application's identity certificate. If they do not match, the application process is terminated.

[0121] When DDS session negotiation requires calculating message signatures, it requests a private key signing operation through the CMS interface, carrying the application identity ID.

[0122] CMS extracts the application identity identifier from the request, verifies the application identity through the access control module, and determines whether it has permission to access the corresponding private key. If the application permission is valid, CMS calls the TEE Client API, which generates a signature for the application and returns it to CMS. CMS then returns the signature to DDS, and DDS continues the session negotiation upon receiving it. If the permission is invalid, CMS returns a signature failure message, and DDS terminates the session negotiation.

[0123] The beneficial effects of this invention are that, compared with the prior art, this invention, based on CMS and TEE, realizes the creation and deployment of DDS identity certificates / private keys, simplifies the application configuration and deployment process, simplifies the certificate management process, and improves deployment efficiency.

[0124] Based on the flexibility and security features of TEE, this invention ensures that private keys are securely stored and used in TEE, providing a more secure way to use keys and effectively solving the problem of leakage of application DDS identity certificates and private keys during propagation, deployment and use.

[0125] This invention achieves access control by binding application identity IDs to application permission files and application identity certificates, thus preventing the abuse of permission files. Furthermore, this invention utilizes a certificate reuse mechanism to avoid duplicate creation during application updates, enabling rapid deployment.

[0126] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

Claims

1. A method for securely creating and deploying DDS Security certificates, characterized in that, Including the following steps: (1) Initialize the Certificate Management Service (CMS), establish a secure channel with the Trusted Execution Environment (TEE), and load the pre-installed DDS identity CA root certificate from the TEE; (2) The Application Package Manager (APM) parses the application configuration information, carries the application identity ID, and sends a certificate creation request to the CMS; (3) The Certificate Management Service (CMS) constructs certificate information and sends the certificate creation request carrying the certificate information and the application identity ID to the Trusted Execution Environment (TEE); (4) Generate RSA public and private keys in the Trusted Execution Environment (TEE), create and issue a certificate, and return the created application identity certificate to the CMS; Specifically, a unique asymmetric public-private key pair is generated for the application identity ID in the TEE, and the generated private key is bound to the application identity ID and stored in the TEE. The public key is embedded in the certificate structure, a certificate is created based on the certificate information, the certificate is signed using a pre-set CA private key, and the created application identity certificate is returned to the CMS. (5) The Certificate Management Service (CMS) verifies and stores the certificate, and returns the identity certificate and CA root certificate to the APM; (6) The Application Package Manager (APM) installs the identity certificate and CA root certificate into the specified folder in the application installation directory; After the application is installed and deployed, the application identity certificate, DDS permission file, private key, and application identity ID are associated: Identity certificate binding: In conf / dds / identity_cert.pem, certificate CN = application identity ID; Permissions file binding: In conf / dds / permissions.p7s, the principal information CN = application identity ID; Private key access binding: Access via application identity ID.

2. The DDS Security certificate secure creation and deployment method according to claim 1, characterized in that, In step (2), specifically, the access / UnifiedAccess.json configuration file is parsed, the security.dds.enable field is checked to see if it is "on", the security.dds.ID field is extracted as the application identity identifier, a certificate creation request containing the application identity ID is constructed, the CMS interface is called, and the certificate creation request is initiated.

3. The DDS Security certificate secure creation and deployment method according to claim 1, characterized in that, In step (3), the Certificate Management Service (CMS) constructs certificate information specifically including: generating a unique certificate serial number, constructing certificate subject information, where the CN field is set to the application identity ID, setting the certificate validity period and signature algorithm, and setting certificate extension information.

4. The DDS Security certificate secure creation and deployment method according to claim 1, characterized in that, In step (6), specifically, the generated identity certificate is stored in the conf / dds / directory and named identity_app.pem; the identity CA root certificate is stored in the conf / dds / directory and named identity_ca.pem; APM sets the access permissions of the certificate file so that only the application process can read it.

5. The DDS Security certificate secure creation and deployment method according to claim 1, characterized in that, When an application with the same application ID undergoes a version update or reinstallation, the system employs a certificate reuse mechanism, specifically: The Application Package Manager (APM) parses the UnifiedAccess.json configuration file of the new version of the application, extracts the application identity ID, and sends a certificate creation request to the Certificate Management Service (CMS). The CMS queries the local certificate to check if the corresponding identity certificate exists. If the local certificate exists, it checks the validity of the certificate and whether the corresponding private key binding relationship exists in the TEE. If so, the CMS skips the TEE certificate generation and private key creation steps and directly sends the existing application identity certificate and CA root certificate content to the APM. The APM copies the certificate to the corresponding directory and sets access permissions.

6. A DDS Security certificate secure creation and deployment system, used to implement the DDS Security certificate secure creation and deployment method according to any one of claims 1-5, characterized in that, This includes Application Package Manager (APM), Certificate Management Service (CMS), and Trusted Execution Environment (TEE). The Application Package Manager (APM) is responsible for parsing application configuration information and initiating certificate creation requests. Certificate Management Service (CMS) is responsible for constructing and managing certificate information and has a built-in access control module. The Trusted Execution Environment (TEE) is responsible for private key generation and certificate signing.

Images