Conference data security management method, device and equipment and readable storage medium

Abstract

The application discloses a conference data security management method and device, equipment and a readable storage medium. The method comprises the following steps: the conference data is divided into text data and audio and video data; based on the identification of the first key encryption key, the text encryption data, the text authentication data, the first encapsulation field and the first integrity check value, the text ciphertext is generated, and the text ciphertext is stored in correspondence with the conference identification; based on the identification of the second key encryption key, the index information, each encryption block, each audio and video authentication data, the second encapsulation field and each second integrity check value, the audio and video ciphertext is generated, and the audio and video ciphertext is stored in correspondence with the conference identification. It can be seen that the application can effectively resist the data leakage risk caused by library backup leakage through two-level key encapsulation and differential encryption key encryption of the text and the audio and video.

Description

Technical Field

[0001] This application relates to the field of information security technology, and more specifically, to a method, apparatus, device, and readable storage medium for secure management of conference data. Background Technology

[0002] With the deployment of meeting minutes systems in enterprise private environments, these systems store a large amount of meeting data. This data typically involves various private information, including customer information, business decisions, project risks, R&D plans, personnel arrangements, and business plans. To protect customer privacy and security, current technology allows access to the backend to view relevant video data through business login or page permissions, thus preventing privacy data leaks.

[0003] However, for private clients, meeting data may be leaked through database backups, and relying solely on regular business logins and page permissions is insufficient to meet security requirements. Therefore, a new method for managing meeting data security is urgently needed to ensure the security of meeting data. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, device and readable storage medium for secure management of conference data, which addresses the shortcomings of existing conference data management technologies in that conference data is easily leaked.

[0005] To achieve the above objectives, the following solution is proposed: A method for managing the security of meeting data includes: In response to a meeting encryption command, the system acquires the meeting data that needs to be stored privately and decomposes the meeting data into text data and audio / video data. Determine the meeting identifier corresponding to the meeting data; Generate a text encryption key and text authentication data for locating the text data; obtain a first key encryption key that is active throughout its lifecycle; encrypt the text data using the text encryption key and the text authentication data to generate encrypted text data; encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field; generate a first integrity check value using the encrypted text data and the text authentication data; generate ciphertext based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity check value, and store the ciphertext corresponding to the meeting identifier; Generate an audio / video encryption key; obtain a second encryption key with an active lifecycle; encapsulate the audio / video encryption key using the second encryption key to obtain a second encapsulation field; divide the audio / video data into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video authentication data for locating each plaintext block; encrypt the corresponding plaintext block using the audio / video encryption key and each audio / video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and corresponding audio / video authentication data; construct index information based on the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video ciphertext based on the identifier of the second encryption key, the index information, each encrypted block, each audio / video authentication data, the second encapsulation field, and each second integrity check value, and store the audio / video ciphertext corresponding to the conference identifier.

[0006] Optional, also includes: In response to an access request from a user to a target meeting file, verify the user's access permissions to the target meeting file. After successful verification, a short-term authorized access token is issued to the accessing subject. The short-term authorized access token includes any one or more of the following: binding file identifier, access purpose, subject type, subject identifier, meeting identifier, task identifier, calling application identifier, issuance time, and expiration time.

[0007] Optionally, after issuing a short-term authorized access token to the accessing subject, the method further includes: In response to a decryption request carrying the short-term authorized access token, token verification, subject authentication, and permission scope verification are performed based on the short-term authorized access token. The permission scope verification is used to confirm whether the meeting identifier or task identifier bound to the short-term authorized access token is consistent with the meeting or task associated with the target meeting file. If token verification fails, principal authentication fails, and / or permission scope verification fails, an alert will be issued; If the token verification, subject authentication, and permission scope verification all pass, then the target audio / video ciphertext and target text ciphertext corresponding to the target meeting file are determined. The target audio and video ciphertext is decrypted to obtain the audio and video plaintext; The target text ciphertext is decrypted to obtain the plaintext text.

[0008] Optionally, the target audio and video ciphertext is decrypted to obtain the audio and video plaintext, including: Extract the first target identifier and audio / video encapsulation field from the target audio / video ciphertext, and decrypt the audio / video encapsulation field using the audio / video key encryption key corresponding to the first target identifier to obtain the audio / video decryption key; The audio and video decryption key and each target audio and video authentication data are used to decrypt the matched target encrypted block to obtain multiple target decryption blocks; Based on the target index information in the target audio and video ciphertext, each target decryption block is concatenated to obtain the audio and video plaintext.

[0009] Optionally, the target text ciphertext is decrypted to obtain plaintext text, including: Extract the second target identifier and text encapsulation field from the target text ciphertext, and decrypt the text encapsulation field using the text key encryption key corresponding to the second target identifier to obtain the text decryption key; The target text encrypted data in the target text ciphertext is decrypted using the text decryption key and the target text authentication data to obtain the plaintext text.

[0010] Optional, also includes: In response to a key encryption key leak event, create a new key encryption key and set its lifecycle state to active. Change the lifecycle status of the historical key encryption key to a decryption-only status; Scan all historically encapsulated fields encrypted with the historical key encryption key; The encryption key for each historical encapsulation field is recovered using the historical key encryption key, and each recovered encryption key is recapsulated as the corresponding new encapsulation field using the new key encryption key.

[0011] Optional, also includes: In response to a historical encryption key leak, a new encryption key body is created; Decrypt each historical encapsulation field and scan all ciphertext data encrypted using the historical encryption key; Each ciphertext data is recovered using the historical encryption key to obtain plaintext data, and each ciphertext data is re-encrypted using the new encryption key body as the corresponding new ciphertext data.

[0012] A conference data security management device, comprising: The acquisition module is used to respond to the conference encryption command, acquire the conference data that needs to be privately stored, and decompose the conference data into text data and audio / video data; The determination module is used to determine the meeting identifier corresponding to the meeting data; A generation module is used to generate a text encryption key and text authentication data for locating the text data; obtain a first key encryption key that is active in its lifecycle; encrypt the text data using the text encryption key and the text authentication data to generate encrypted text data; encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field; generate a first integrity check value using the encrypted text data and the text authentication data; and generate ciphertext based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity check value, and store the ciphertext corresponding to the meeting identifier. An encryption module is used to generate an audio / video encryption key; obtain a second encryption key with an active lifecycle; encapsulate the audio / video encryption key using the second encryption key to obtain a second encapsulation field; divide the audio / video data into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video authentication data for finding each plaintext block; encrypt the corresponding plaintext block using the audio / video encryption key and each audio / video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and corresponding audio / video authentication data; construct index information based on the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video ciphertext based on the identifier of the second encryption key, the index information, each encrypted block, each audio / video authentication data, the second encapsulation field, and each second integrity check value, and store the audio / video ciphertext corresponding to the conference identifier.

[0013] A conference data security management device, including a memory and a processor; The memory is used to store programs; The processor is used to execute the program to implement the various steps of the above-described meeting data security management method.

[0014] A readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the various steps of the above-described conference data security management method.

[0015] As can be seen from the above technical solution, this application provides a method for secure management of meeting data. This method first decomposes meeting data into audio / video data and text data, distributing the data and increasing the difficulty of obtaining complete meeting data. Audio / video and text are encrypted using encryption keys, authentication data, and key encryption keys, ensuring that even if an attacker bypasses front-end permissions and directly retrieves the database or backup files, they will only obtain multi-layered encrypted ciphertext. Without a key system, this data is meaningless; furthermore, the encryption keys, authentication data, and key encryption keys used for audio / video and text are different, further increasing the difficulty of cracking. Simultaneously, this application generates independent encryption keys for both text and audio / video data, ensuring data key isolation and preventing single-point key leakage from spreading to the entire meeting. The keys are physically isolated from business data; backups only contain the encapsulated encrypted key ciphertext, not the raw key. During encryption, authentication data can be used to find the corresponding text data, and the ciphertext is strongly bound to the data's metadata, preventing ciphertext migration, tampering, and splicing attacks. This fundamentally eliminates the risk of malicious misappropriation of ciphertext. By segmenting large audio and video files into independent encrypted blocks and attaching sequence and byte offset indexes, this application supports segmented reading and partial verification. Tampering with any audio or video segment can be quickly identified by integrity verification. By storing integrity verification values ​​in the ciphertext, this application does not need to rely on business service verification logic; tampering can be detected even with only the ciphertext data. Moreover, the encryption key used in this application has a lifecycle state, and the lifecycle state is active. After the ciphertext is leaked, the valid encryption key can be lost by adjusting the lifecycle state of the encryption key, making it impossible to decrypt the encryption key, let alone the audio / video ciphertext and text ciphertext. It can be seen that this application, through two-level key encapsulation, differentiated encryption keys for text and audio / video, binding of metadata and authentication data, segmented indexing, and independent integrity verification, prevents attackers who only obtain database backups from decrypting data keys and decrypting meeting plaintext, effectively resisting the risk of data leakage caused by database breaches and database backup leaks. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 This is a flowchart of a meeting data security management method disclosed in an embodiment of this application; Figure 2 This is a structural block diagram of a conference data security management device disclosed in an embodiment of this application; Figure 3 This is a hardware structure block diagram of a conference data security management device disclosed in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] This application provides a method for managing conference data security. This method can be applied to various conference data management systems or conference minutes systems, as well as to various computer terminals or smart terminals. The executing entity can be the processor or server of the computer terminal or smart terminal.

[0020] Next, combine Figure 1 The meeting minutes method described in this application is detailed, including the following steps: Step S1: In response to the meeting encryption command, obtain the meeting data that needs to be privately stored, and decompose the meeting data into text data and audio / video data.

[0021] Specifically, private encryption can be deployed in advance before the first use of this application. The system reads and verifies the encryption during the startup phase, and the initialized and health-verified key level is used directly when writing meeting data.

[0022] Private encryption deployment includes: EncConfig={enabled,provider,root_material_ref,kek_store_ref,token_secret_ref,chunk_size,service_signature_policy,file_access_mode} "enabled" indicates whether encryption is enabled; The term "provider" refers to the provider of encryption, such as local software encryption, customer KMS, cryptographic machines, or commercial cryptographic SDKs. root_material_ref represents a non-sensitive reference, handle, or controlled path to the root material, rather than the root key plaintext itself; in software keystore mode, the key encryption key KEK is generated by a cryptographically secure random number generator and stored in a private keystore; in KMS or HSM mode, the key material is always kept inside the device. kek_store_ref represents a reference to a key object and its metadata in a KEK keystore, KMS, or HSM. It is used to locate active and historical KEKs and does not carry plaintext key material. token_secret_ref represents a controlled reference to the signing key of a short-term authorization token, and the signing key does not appear in plaintext in business requests and logs; hunk_size represents the size of the plaintext blocks in the file; The service_signature_policy represents the signature policy for internal service calls. It specifies at least the rules for generating and verifying the caller's application identifier, timestamp, nonce, request method, request path, and message signature, and prevents replay through time windows and nonce. file_access_mode indicates the access mode for encrypted files; this application adopts a backend authorized proxy decryption mode, which prohibits the direct acquisition of plaintext files through public addresses of object storage or pre-signed URLs.

[0023] When a meeting ends in a private environment or a meeting is stored in a private environment, it can be determined that `enabled=true`, indicating the presence of a meeting encryption command. At this point, it can verify whether the encryption provider is available; whether the root material is readable; whether an active KEK exists; whether the token signing key length meets security requirements; whether the file block size is within the allowed range; whether the service signing configuration is enabled; whether the file access mode prohibits pre-signed direct plaintext access; and whether the decryption entry point is included in the authentication and authorization chain.

[0024] The verification will fail if any one or more of the following conditions exist: the activeKEK is missing, the root material is unreadable, the token signing key is missing or too short, a pre-signed direct-connect object store is used as the plaintext access point, the decryption entry point is not included in the service signature protection, and the encryption algorithm library is unavailable but the system still allows plaintext writing.

[0025] Once the verification is successful, the corresponding meeting data can be obtained.

[0026] Text data may include meeting minutes, original subtitle segments, corrected subtitle segments, snapshot text of minutes, parsed document text, document page text, segmented text, JSON evidence packages, chat content, meeting notes, and other meeting-related text content.

[0027] Audio and video data may include meeting recordings, uploaded attachments, online recording and composite files, final audio from automatic speech recognition, voiceprint audio, speaker segments, original files from document parsing, and exported files, as well as other content related to meeting audio and video.

[0028] Step S2: Determine the meeting identifier corresponding to the meeting data.

[0029] Specifically, a unique meeting identifier can be generated based on the timestamp of the meeting data and a random number.

[0030] Step S3: Generate a text encryption key and text authentication data for locating the text data; obtain a first key encryption key that is active in its lifecycle; encrypt the text data using the text encryption key and the text authentication data to generate encrypted text data; encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field; generate a first integrity check value using the encrypted text data and the text authentication data; generate ciphertext based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity check value, and store the ciphertext corresponding to the meeting identifier.

[0031] Specifically, a text encryption key can be generated using GenerateRandomKey().

[0032] The database table identifier, column identifier, and primary key identifier of the text data are concatenated to form the text authentication data.

[0033] The key encryption key can be derived from the root material or read from the active state as the first key encryption key.

[0034] Each key encryption key (KEK) contains at least: key_id: A stable, non-sensitive identifier for the KEK, used for reference in the ciphertext header and file manifest; version: KEK rotation version number, used to distinguish keys from different generations for the same purpose; algorithm: Identifier of the algorithm used when wrapping and unwrapping DEK using KEK; status: The current lifecycle status of the KEK, with values ​​including generated, active, decrypt_only, retired, or revoked; created_at: The time when the KEK was generated or registered to the key management module; activated_at: The time when the KEK begins to be used to wrap the new DEK; deactivated_at: The time when the KEK stops wrapping the new DEK and transitions to an inactive state such as decrypt_only; retired_at: The official retirement date of KEK; if it is revoked due to a security incident, it can be recorded separately as revoked_at.

[0035] The lifecycle status of a KEK can be generated but not enabled, active, only allows unpacking old encryption keys but not allowing new writing, retired, or revoked.

[0036] Randomly generated initialization vector; The text data, initialization vector, and text authentication data are encrypted using a text encryption key to generate encrypted text data. The first key can be used to encrypt the key and Wrap() to encapsulate the text encryption key, thereby obtaining the first encapsulation field; The encrypted text data and the authenticated text data can be used to generate a first integrity verification value.

[0037] The ciphertext may include a ciphertext format version, encryption and integrity algorithm, KEK identifier, KEK version, first encapsulation field, initialization vector, ciphertext text, first integrity check value, and text authentication data.

[0038] Step S4: Generate an audio / video encryption key; obtain a second key encryption key that is active in its lifecycle; encapsulate the audio / video encryption key using the second key encryption key to obtain a second encapsulation field; divide the audio / video data into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video authentication data for finding each plaintext block; encrypt the corresponding plaintext block using the audio / video encryption key and each audio / video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and the corresponding audio / video authentication data; construct index information based on the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video ciphertext based on the identifier of the second key encryption key, the index information, each encrypted block, each audio / video authentication data, the second encapsulation field, and each second integrity check value, and store the audio / video ciphertext corresponding to the conference identifier.

[0039] Specifically, both the first key encryption key and the second key encryption key are KEKs that are active in their lifecycle. Generally, the first key encryption key and the second key encryption key are different KEKs. However, when there is only one active KEK in the root material, the first key encryption key and the second key encryption key can be the same.

[0040] Based on the private encryption deployment, the audio and video data can be divided into blocks to obtain multiple file blocks, and the sequence number, plaintext start byte position, plaintext byte count, ciphertext start byte position, and number of bytes of necessary authentication data for each plaintext block can be determined.

[0041] The audio and video ciphertext may include the identifier of the second key encryption key, index information, each encryption block, audio and video authentication data corresponding to each encryption block, second encapsulation fields, and each second integrity check value.

[0042] Each plaintext block can correspond to one audio / video authentication data.

[0043] Each audio / video authentication data may include a unique file identifier, the corresponding plaintext block sequence number, the plaintext start byte position, and the plaintext block size; A file's unique identifier can be a unique identifier for the file within the system, a unique number for the meeting to which the file belongs, or a unique number for an asynchronous task associated with the file, such as a speech recognition or document parsing task.

[0044] The Manifest and various encrypted blocks can be combined to form audio and video ciphertext.

[0045] in, Manifest={file_key,meeting_id,task_id,content_type,plain_size,cipher_size,chunk_size,chunk_count,key_id,kek_version,wrapped_dek,chunks}.

[0046] The manifest can be formed by merging file context and size information, KEK identifier, WrappedDEK_file, and the index, offset, length, IV, and MAC generated by block looping. The manifest provides the metadata required for key recovery and range positioning, both of which are indispensable for decryption access.

[0047] Object storage only stores encrypted objects, not plaintext objects. Manifests are stored in a database or a controlled metadata store, and plaintext DEKs are not stored.

[0048] To ensure the validity of storage, the ciphertext can be verified for integrity based on the first integrity check value before storage; similarly, the ciphertext can be verified for integrity based on the second integrity check value, and the ciphertext can be stored only after passing the integrity check.

[0049] You can refuse to automatically read fields that fail validation and add them to the failure list.

[0050] As can be seen from the above technical solution, this application provides a method for secure management of meeting data. This method first decomposes meeting data into audio / video data and text data, distributing the data and increasing the difficulty of obtaining complete meeting data. Audio / video and text are encrypted using encryption keys, authentication data, and key encryption keys, ensuring that even if an attacker bypasses front-end permissions and directly retrieves the database or backup files, they will only obtain multi-layered encrypted ciphertext. Without a key system, this data is meaningless; furthermore, the encryption keys, authentication data, and key encryption keys used for audio / video and text are different, further increasing the difficulty of cracking. Simultaneously, this application generates independent encryption keys for both text and audio / video data, ensuring data key isolation and preventing single-point key leakage from spreading to the entire meeting. The keys are physically isolated from business data; backups only contain the encapsulated encrypted key ciphertext, not the raw key. During encryption, authentication data can be used to find the corresponding text data, and the ciphertext is strongly bound to the data's metadata, preventing ciphertext migration, tampering, and splicing attacks. This fundamentally eliminates the risk of malicious misappropriation of ciphertext. By segmenting large audio and video files into independent encrypted blocks and attaching sequence and byte offset indexes, this application supports segmented reading and partial verification. Tampering with any audio or video segment can be quickly identified by integrity verification. By storing integrity verification values ​​in the ciphertext, this application does not need to rely on business service verification logic; tampering can be detected even with only the ciphertext data. Moreover, the encryption key used in this application has a lifecycle state, and the lifecycle state is active. After the ciphertext is leaked, the valid encryption key can be lost by adjusting the lifecycle state of the encryption key, making it impossible to decrypt the encryption key, let alone the audio / video ciphertext and text ciphertext. It can be seen that this application, through two-level key encapsulation, differentiated encryption keys for text and audio / video, binding of metadata and authentication data, segmented indexing, and independent integrity verification, prevents attackers who only obtain database backups from decrypting data keys and decrypting meeting plaintext, effectively resisting the risk of data leakage caused by database breaches and database backup leaks.

[0051] In some embodiments of this application, considering that the encrypted meeting data needs to be retrieved after storage, but not everyone has the permission to retrieve it, this application attempts to add a short-term token issuance process to clarify retrieval permissions and further ensure the security of meeting data. The short-term token issuance process will be described in detail below, with the following steps: S5. Respond to the access request of the accessing subject to the target meeting file and verify the access permission of the accessing subject to the target meeting file.

[0052] Specifically, an access request may include a file identifier, the purpose of access, the subject type such as user or service, the subject identifier, the meeting identifier, the task identifier, and the calling application identifier.

[0053] The purpose of access is to retrieve audio for browser playback, browser download, automatic speech recognition service, voiceprint recognition service, speaker separation service, voiceprint registration or verification, or document parsing service.

[0054] Based on the access subject's permission scope, it can be determined whether the access request exceeds the permission scope. If not, step S6 is executed; if so, a reminder or alarm is issued.

[0055] S6. After verification, a short-term authorized access token is issued to the accessing subject. The short-term authorized access token includes any one or more of the following: binding file identifier, access purpose, subject type, subject identifier, meeting identifier, task identifier, calling application identifier, issuance time, and expiration time.

[0056] Specifically, a short-term authorized access token may include any one or more of the following data: bound file identifier, access purpose, subject type, subject identifier, meeting identifier, task identifier, calling application identifier, issuance time, and expiration time.

[0057] The expiration period of the token should be short and can be set according to its purpose. For example, browser playback tokens and service processing tokens can have different expiration times.

[0058] Token fingerprints can be generated for auditing: token_fingerprint=Hash(token_id||file_key||purpose||expires_at) The audit records the token fingerprint, but not the complete token.

[0059] As can be seen from the above technical solution, this embodiment adds a short-term token issuance process. Through this process, this application can bind access permissions to specific access subjects, access purposes, and target meeting files, and set a short validity period, avoiding the risk of unauthorized access after permission leakage. Even if the token is accidentally leaked, it will expire in a short time and cannot be continuously used by attackers. At the same time, the auditing method of recording the token fingerprint rather than the complete token can also meet the security audit requirements while avoiding the leakage of complete authorization information in the audit log, further improving the security protection capabilities of the access process.

[0060] After a short-term authorized access token is issued, the access subject can use this token to request the decryption of the target ciphertext. The decryption process will be explained in detail below: S7. In response to the decryption request carrying the short-term authorized access token, perform token verification, subject authentication, and permission scope verification based on the short-term authorized access token. The permission scope verification is used to confirm whether the meeting identifier or task identifier bound to the short-term authorized access token is consistent with the meeting or task associated with the target meeting file.

[0061] Specifically, the input is an authorization decryption request carrying a short-term authorization access token. Browser users and internal services use different authentication contexts; user_session and service_signature are mutually exclusive, rather than requiring both to be submitted simultaneously.

[0062] BrowserDecryptReq={file_key,Token,user_session,range_header,request_id}

[0063] ServiceDecryptReq={file_key,Token,service_signature,range_header,request_id}

[0064] Among them, file_key is usually located in the request path and is used to specify the file to be accessed; user_session is the browser user's authenticated session; service_signature at least contains the application identifier, timestamp, nonce and message signature, and is bound to the request method and path; range_header is an optional HTTPRange range, which means full reading if not provided; request_id is used for tracing and security auditing.

[0065] Therefore, browser requests use a token and user session to prove "who is accessing"; internal service requests use a token and service signature to prove "which trusted service is accessing for what purpose". After their respective authentications are successful, both types of requests are merged into the same token, scope, file_key, meeting_id, and task_id binding and verification process.

[0066] For browser access, the following can be verified: whether unified authentication is passed, token signature verification, whether the token has expired, whether the token's purpose allows the browser to play or download, whether the current user matches the token's subject_id, whether the user can access the meeting file based on meeting visibility, creator, participants, sharing relationship, resource permissions or management backend permissions, whether the meeting_id in the manifest matches the meeting_id in the token, and whether the file_key matches the file_key bound to the token.

[0067] For inter-service access, in addition to verifying the short-term token, the system also verifies the validity of the service signature, whether the service caller's app_id is correct, whether the signed app_id matches the token caller_app_id, whether the purpose matches the service type, whether the task_id and meeting_id match the manifestownerscope, and whether the service is allowed to access this type of file.

[0068] If all corresponding verifications pass, it can be determined that the token verification, subject authentication, and permission scope verification have all passed; if any verification fails, it can be determined that the token verification, subject authentication, and / or permission scope verification have failed.

[0069] S8. If the token verification fails, the subject authentication fails, and / or the permission scope verification fails, an alert is issued; if the token verification, subject authentication, and permission scope verification all pass, the target audio / video ciphertext and target text ciphertext corresponding to the target meeting file are determined; the target audio / video ciphertext is decrypted to obtain the audio / video plaintext; the target text ciphertext is decrypted to obtain the text plaintext.

[0070] Specifically, if it is determined that the token verification fails, the subject authentication fails, and / or the permission scope verification fails, a warning or alert will be issued. If token verification, subject authentication, and permission scope verification all pass, the target audio / video ciphertext and target text ciphertext corresponding to the target meeting file can be determined. Decryption technology is then used to decrypt the target audio / video ciphertext to obtain the audio / video plaintext; the target text ciphertext is decrypted to obtain the text plaintext. The text plaintext and audio / video plaintext are then combined to restore the meeting data containing playable text content and audio / video.

[0071] As can be seen from the above technical solution, this embodiment provides a decryption process. Through the above process, it can be ensured that each decryption access is strictly bound to the access subject's permission scope and access purpose, avoiding unauthorized data reading; at the same time, combined with the time-limited nature of short-term tokens, the operable window for unauthorized access is further compressed. Even if token leakage or unauthorized access occurs, it can be intercepted in time through rapid verification, and the access subject can be quickly traced and located through audit information, effectively reducing the risk of data leakage and ensuring the security of meeting data.

[0072] For browser Range playback requests, let the plaintext range of the request be: Range=[r_start,r_end] The system calculates the set of blocks covering the plaintext range based on the manifest: BlockSet={chunk_i|chunk_i.plaintext_offset<=r_end∧chunk_i.plaintext_offset+chunk_i.plaintext_size-1>=r_start} It reads only the ciphertext blocks corresponding to the BlockSet from the object storage, and performs the following on each block: MAC verification, decryption, trimming plaintext fragments according to the target Range, and returning an HTTP 206 response or an equivalent range stream in sequence.

[0073] This method supports drag-and-drop audio playback, but neither the browser nor object storage accesses the complete plaintext file.

[0074] Furthermore, this application can record audit events such as key generation, key activation, key deactivation, key revocation, DEK encapsulation, unpacking failure, field encryption, field decryption, file encryption, file decryption, token issuance, token verification failure, scope mismatch, range decryption failure, service signature failure, field migration, file migration, and key rotation.

[0075] To ensure security, the real key, plaintext encrypted key, complete token information, complete text content, and complete audio and video content must not be recorded.

[0076] Full-text search indexes, evidence fragments, intermediate results of document parsing, logs, error responses, and caching should all be included in one of the following strategies: encrypted persistence, de-identified persistence, short-term retention, disabling persistence, placing in a controlled encrypted volume, or saving only hashes, summaries, or fingerprints.

[0077] To ensure security, complete plaintext summaries, complete subtitles, complete audio clips, or complete key materials cannot be output in ordinary logs.

[0078] In some embodiments of this application, the process of decrypting the target audio and video ciphertext in step S8 to obtain the audio and video plaintext is described in detail, and the steps are as follows: S80. Extract the first target identifier and audio / video encapsulation field from the target audio / video ciphertext, and decrypt the audio / video encapsulation field using the audio / video key encryption key corresponding to the first target identifier to obtain the audio / video decryption key.

[0079] Specifically, the KEK identifier can be extracted from the target audio and video ciphertext as the first identifier, and the encapsulation field can be extracted as the audio and video encapsulation field. The key encryption key found based on the KEK identifier can be used as the audio and video key encryption key, and the audio and video encapsulation field can be decrypted using the audio and video key encryption key corresponding to the first target identifier to obtain the audio and video decryption key, and then DEK=Unwrap(KEK,WrappedDEK) can be executed.

[0080] S81. Use the audio and video decryption key and each target audio and video authentication data to decrypt the matched target encryption block to obtain multiple target decryption blocks.

[0081] Specifically, the audio / video decryption key and each target audio / video authentication data can be used to decrypt the corresponding target encrypted block to obtain multiple target decrypted blocks.

[0082] S82. Based on the target index information in the target audio and video ciphertext, each target decryption block is concatenated to obtain the audio and video plaintext.

[0083] Specifically, based on the target index information, the decrypted blocks of each target can be spliced ​​and combined to obtain the plaintext audio and video.

[0084] As can be seen from the above technical solution, this embodiment provides an optional method for decrypting the target audio and video ciphertext to obtain the audio and video plaintext. This method can further improve the effectiveness of decrypting audio and video data in this application.

[0085] In some embodiments of this application, the process of decrypting the target text ciphertext in step S8 to obtain plaintext is described in detail, and the steps are as follows: S80. Extract the second target identifier and text encapsulation field from the target text ciphertext, and decrypt the text encapsulation field using the text key encryption key corresponding to the second target identifier to obtain the text decryption key.

[0086] Specifically, the second target identifier, target text authentication data, and text encapsulation fields can be extracted from the target text ciphertext.

[0087] The text encapsulation field can be decrypted using the text key encryption key corresponding to the second target identifier to obtain the text decryption key.

[0088] S81. Use the text decryption key and target text authentication data to decrypt the target text encrypted data in the target text ciphertext to obtain the plaintext text.

[0089] Specifically, the text decryption key and the target text authentication data can be used to decrypt the target text encrypted data in the target text ciphertext, and the decrypted text is obtained as plaintext.

[0090] As can be seen from the above technical solution, this embodiment provides an optional method for decrypting the target text ciphertext to obtain plaintext text. This method can further improve the effectiveness of decrypting text data in this application.

[0091] Considering that keys may need to be rotated, a new KEK can be created during normal rotation: KEK_new.status=active; Change the status of the old KEK to: KEK_old.status=decrypt_only; Newly written data uses a new KEK to wrap the DEK.

[0092] Old data can be rotated using the rewrap method: DEK=Unwrap(KEK_old,WrappedDEK_old) WrappedDEK_new=Wrap(KEK_new,DEK) It can update the key_id, version, and wrapped_dek in the ciphertext header or manifest.

[0093] Normal rotation does not require immediate re-encryption of business field ciphertext or large file ciphertext, reducing rotation costs.

[0094] Furthermore, when changing the database, historical plaintext fields and objects can be scanned to generate a migration job: MigrationJob = {job_id, batch_scope, target_key_id, status, created_at}

[0095] Each migration item record: MigrationItem = {item_id, target_type, target_id, status, attempts,error_code, target_key_id} in: target_type can be a field or a file; status can be pending, running, success, failed, skipped; attempts indicates the number of retries; error_code indicates the reason for failure.

[0096] The migration task supports batching by meeting, batching by time range, batching by field type, batching by file type, failure retry, idempotent continuation, and audit logs.

[0097] During migration, the read path can support mixed reading of old plaintext and new ciphertext; after migration is complete, a policy to prohibit reading of old plaintext can be enabled.

[0098] After encryption is enabled, access should be denied and a stable error code should be returned in the following scenarios: missing key, KEK state does not allow decryption, wrapped DEK integrity failure, AAD mismatch, corrupted manifest, expired token, incorrect token signature, scope mismatch, service signature mismatch, accessing decrypted stream via public path, direct connection to plaintext in object storage, unavailable encryption provider, missing algorithm library, and configuration conflict.

[0099] Health status can include: disabled: encryption is not enabled; enabled_ready: encryption is enabled and working properly; enabled_degraded: encryption is enabled but some capabilities are degraded, allowing only limited read-only diagnostics; enabled_blocked: encryption is enabled but critical capabilities are abnormal, denying encryption-related read, write and decryption access.

[0100] Considering the risk of key leakage in encryption keys, a key leakage handling process can be added. The following is a detailed explanation of this process, with the steps outlined below: S9. In response to a key encryption key leakage event, create a new key encryption key and set its lifecycle state to active.

[0101] Specifically, in response to the detection of a key encryption key leakage event, a brand new key encryption key can be generated immediately, and the lifecycle status of the newly added key encryption key can be set to active.

[0102] When the encryption key is accessed by an unauthorized entity, it can be considered a key encryption key leakage event.

[0103] S10. Change the lifecycle status of the historical key encryption key to decryption-only status.

[0104] Specifically, the lifecycle status of the previously leaked encryption keys will be synchronously adjusted to a decryption-only status.

[0105] S11. Scan all historical encapsulated fields encrypted with the historical key encryption key.

[0106] Specifically, each historical encapsulated field can be identified by the identifier of the historical key encryption key.

[0107] S12. Use the historical key to encrypt the key to recover the encryption key of each historical encapsulation field, and use the new key to encrypt the key to re-encapsulate each recovered encryption key as the corresponding new encapsulation field.

[0108] Specifically, the historical key can be used to encrypt the corresponding historical encapsulation field to perform an unpacking operation and recover the original encryption key; then, the newly generated active state key can be called to perform a repackaging operation on each recovered encryption key, replacing the original historical encapsulation field and obtaining the corresponding new encapsulation field.

[0109] As can be seen from the above technical solution, this embodiment provides a new key encryption key leakage handling process. Through the above process, the corresponding encapsulation fields can be processed in a timely manner when the key is encrypted, thus ensuring the security of meeting data.

[0110] Considering the risk of encryption key leakage, a procedure for handling encryption key leakage can be added. The following is a detailed explanation of the encryption key leakage handling procedure, with the following steps: S9. In response to a historical encryption key leak, create a new encryption key subject.

[0111] Specifically, a new encryption key can be created as the encryption key body according to a pre-set encryption key generation method.

[0112] S10. Decrypt each historical encapsulation field and scan all ciphertext data encrypted using the historical encryption key.

[0113] Specifically, each historical encapsulated field can be decrypted using the generated encryption key to obtain the encryption key corresponding to each ciphertext data. The leaked historical encryption key can be matched with each decrypted encryption key. By combining the correspondence between each encryption key and each ciphertext data, all ciphertext data encrypted using the leaked historical encryption key can be identified, thus completing the full scan and location of the target ciphertext data.

[0114] S11. Use the historical encryption key to recover each ciphertext data to obtain plaintext data, and use the new encryption key body to re-encrypt each ciphertext data as the corresponding new ciphertext data.

[0115] Specifically, the leaked historical encryption key can be used to decrypt the ciphertext data and restore the original plaintext data; then, the newly generated encryption key is called to re-encrypt all the restored plaintext data to generate corresponding new ciphertext data, which replaces the original historical ciphertext data to complete the data update.

[0116] As can be seen from the above technical solution, this embodiment provides a process for handling encryption key leakage. Through the above process, the security and privacy of meeting data can be further guaranteed.

[0117] Next, we will combine Figure 2 This application provides a detailed description of the conference data security management device. The conference data security management device described below can be compared with the conference data security management method described above.

[0118] See Figure 2 It can be observed that the conference data security management device may include: The acquisition module 10 is used to acquire the meeting data that needs to be privately stored in response to the meeting encryption command, and decompose the meeting data into text data and audio and video data; The determining module 20 is used to determine the meeting identifier corresponding to the meeting data; The generation module 30 is used to generate a text encryption key and text authentication data for locating the text data; obtain a first key encryption key whose lifecycle is active; encrypt the text data using the text encryption key and the text authentication data to generate encrypted text data; encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field; generate a first integrity check value using the encrypted text data and the text authentication data; and generate ciphertext based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity check value, and store the ciphertext corresponding to the meeting identifier. The encryption module 40 is used to generate an audio / video encryption key; obtain a second key encryption key whose lifecycle is active; encapsulate the audio / video encryption key using the second key encryption key to obtain a second encapsulation field; divide the audio / video data into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video authentication data for finding each plaintext block; encrypt the corresponding plaintext block using the audio / video encryption key and each audio / video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and the corresponding audio / video authentication data; construct index information based on the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video ciphertext based on the identifier of the second key encryption key, the index information, each encrypted block, each audio / video authentication data, the second encapsulation field, and each second integrity check value, and store the audio / video ciphertext corresponding to the conference identifier.

[0119] Furthermore, the meeting data security management device may also include: The first token issuing unit is used to respond to the access request of the access subject to the target meeting file and verify the access subject's access rights to the target meeting file. The second token issuing unit is used to issue a short-term authorized access token to the access subject after verification. The short-term authorized access token includes any one or more of the following: binding file identifier, access purpose, subject type, subject identifier, meeting identifier, task identifier, calling application identifier, issuance time, and expiration time.

[0120] Furthermore, the meeting data security management device may also include: The token verification unit is used to respond to a decryption request carrying the short-term authorized access token by performing token verification, subject authentication, and permission scope verification based on the short-term authorized access token. The permission scope verification is used to confirm whether the meeting identifier or task identifier bound to the short-term authorized access token is consistent with the meeting or task associated with the target meeting file. If the token verification fails, the subject authentication fails, and / or the permission scope verification fails, an early warning is issued. If the token verification, subject authentication, and permission scope verification all pass, the encrypted decryption unit is invoked. The ciphertext decryption unit is used to determine the target audio / video ciphertext and target text ciphertext corresponding to the target meeting document; decrypt the target audio / video ciphertext to obtain the audio / video plaintext; and decrypt the target text ciphertext to obtain the text plaintext.

[0121] Furthermore, the ciphertext decryption unit may include: The audio / video decryption key generation subunit is used to extract a first target identifier and an audio / video encapsulation field from the target audio / video ciphertext, and to decrypt the audio / video encapsulation field using the audio / video key encryption key corresponding to the first target identifier to obtain the audio / video decryption key; The target decryption block generation subunit is used to decrypt the matched target encryption block using the audio and video decryption key and each target audio and video authentication data to obtain multiple target decryption blocks; The audio / video plaintext generation subunit is used to concatenate each target decryption block based on the target index information in the target audio / video ciphertext to obtain the audio / video plaintext.

[0122] Furthermore, the ciphertext decryption unit may also include: The text decryption key generation subunit is used to extract the second target identifier and text encapsulation field from the target text ciphertext, and decrypt the text encapsulation field using the text key encryption key corresponding to the second target identifier to obtain the text decryption key; The plaintext acquisition subunit is used to decrypt the encrypted target text data in the ciphertext of the target text using the text decryption key and the target text authentication data to obtain the plaintext.

[0123] Furthermore, the meeting data security management device may also include: The status setting unit is used to create a new key encryption key and set its lifecycle status to active in response to a key encryption key leakage event. The state change unit is used to change the lifecycle state of the historical key encryption key to a decryption-only state. The historical encapsulation field scanning unit is used to scan all historical encapsulation fields encrypted with the historical key encryption key. The encapsulation field construction unit is used to recover the encryption key of each historical encapsulation field using the historical key encryption key, and to re-encapsulate each recovered encryption key as the corresponding new encapsulation field using the new key encryption key.

[0124] Furthermore, the meeting data security management device may also include: The encryption key body creation unit is used to create a new encryption key body in response to a historical encryption key leakage event; The encrypted data identification unit is used to decrypt each historical encapsulation field and scan all encrypted data encrypted using the historical encryption key; The plaintext data decryption unit is used to recover each ciphertext data using the historical encryption key to obtain plaintext data, and to re-encrypt each ciphertext data using the new encryption key body as the corresponding new ciphertext data.

[0125] The meeting data security management device provided in this application embodiment can be applied to meeting data security management equipment, such as PC terminals, cloud platforms, servers, and server clusters. Optionally, Figure 3 The hardware structure block diagram of the conference data security management device is shown below. Figure 3 The hardware structure of the conference data security management device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4; In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4; Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device; The memory stores a program, which the processor can call. The program is used for: In response to a meeting encryption command, the system acquires the meeting data that needs to be stored privately and decomposes the meeting data into text data and audio / video data. Determine the meeting identifier corresponding to the meeting data; Generate a text encryption key and text authentication data for locating the text data; obtain a first key encryption key that is active throughout its lifecycle; encrypt the text data using the text encryption key and the text authentication data to generate encrypted text data; encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field; generate a first integrity check value using the encrypted text data and the text authentication data; generate ciphertext based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity check value, and store the ciphertext corresponding to the meeting identifier; Generate an audio / video encryption key; obtain a second encryption key with an active lifecycle; encapsulate the audio / video encryption key using the second encryption key to obtain a second encapsulation field; divide the audio / video data into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video authentication data for locating each plaintext block; encrypt the corresponding plaintext block using the audio / video encryption key and each audio / video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and corresponding audio / video authentication data; construct index information based on the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video ciphertext based on the identifier of the second encryption key, the index information, each encrypted block, each audio / video authentication data, the second encapsulation field, and each second integrity check value, and store the audio / video ciphertext corresponding to the conference identifier.

[0126] Optionally, the refined and extended functions of the program can be referred to the above description.

[0127] This application embodiment also provides a readable storage medium that can store a program suitable for execution by a processor, the program being used for: In response to a meeting encryption command, the system acquires the meeting data that needs to be stored privately and decomposes the meeting data into text data and audio / video data. Determine the meeting identifier corresponding to the meeting data; Generate a text encryption key and text authentication data for locating the text data; obtain a first key encryption key that is active throughout its lifecycle; encrypt the text data using the text encryption key and the text authentication data to generate encrypted text data; encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field; generate a first integrity check value using the encrypted text data and the text authentication data; generate ciphertext based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity check value, and store the ciphertext corresponding to the meeting identifier; Generate an audio / video encryption key; obtain a second encryption key with an active lifecycle; encapsulate the audio / video encryption key using the second encryption key to obtain a second encapsulation field; divide the audio / video data into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video authentication data for locating each plaintext block; encrypt the corresponding plaintext block using the audio / video encryption key and each audio / video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and corresponding audio / video authentication data; construct index information based on the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block; generate audio / video ciphertext based on the identifier of the second encryption key, the index information, each encrypted block, each audio / video authentication data, the second encapsulation field, and each second integrity check value, and store the audio / video ciphertext corresponding to the conference identifier.

[0128] Optionally, the refined and extended functions of the program can be referred to the above description.

[0129] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0130] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0131] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. The various embodiments of this application can be combined with each other. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for managing the security of conference data, characterized in that, include: In response to a meeting encryption command, the system acquires the meeting data that needs to be stored privately and decomposes the meeting data into text data and audio / video data. Determine the meeting identifier corresponding to the meeting data; Generate a text encryption key and text authentication data for locating the text data; obtain a first key encryption key that is active in the lifecycle; encrypt the text data using the text encryption key and the text authentication data to generate encrypted text data; encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field; A first integrity verification value is generated using the encrypted text data and the authenticated text data; Based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity verification value, a text ciphertext is generated, and the text ciphertext is stored in correspondence with the meeting identifier; Generate audio and video encryption keys; obtain the second key encryption key that is active in the lifecycle; The second key is used to encrypt the audio and video encryption key, which is then encapsulated to obtain a second encapsulation field. The audio and video data is then divided into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block. Generate audio and video authentication data for locating each plaintext block; encrypt the corresponding plaintext block using the audio and video encryption key and each audio and video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and the corresponding audio and video authentication data. An index is constructed based on the sequence number of each plaintext block, the position of the first byte of the plaintext, the number of plaintext bytes, and the position of the first byte of the ciphertext. Based on the identifier of the second key encryption key, the index information, each encryption block, each audio and video authentication data, the second encapsulation field, and each second integrity check value, audio and video ciphertext is generated, and the audio and video ciphertext is stored in correspondence with the conference identifier.

2. The meeting data security management method according to claim 1, characterized in that, Also includes: In response to an access request from a user to a target meeting file, verify the user's access permissions to the target meeting file. After successful verification, a short-term authorized access token is issued to the accessing subject. The short-term authorized access token includes any one or more of the following: binding file identifier, access purpose, subject type, subject identifier, meeting identifier, task identifier, calling application identifier, issuance time, and expiration time.

3. The meeting data security management method according to claim 2, characterized in that, After issuing a short-term authorized access token to the accessing subject, the process also includes: In response to a decryption request carrying the short-term authorized access token, token verification, subject authentication, and permission scope verification are performed based on the short-term authorized access token. The permission scope verification is used to confirm whether the meeting identifier or task identifier bound to the short-term authorized access token is consistent with the meeting or task associated with the target meeting file. If token verification fails, principal authentication fails, and / or permission scope verification fails, an alert will be issued; If the token verification, subject authentication, and permission scope verification all pass, then the target audio / video ciphertext and target text ciphertext corresponding to the target meeting file are determined. The target audio and video ciphertext is decrypted to obtain the audio and video plaintext; The target text ciphertext is decrypted to obtain the plaintext text.

4. The meeting data security management method according to claim 3, characterized in that, The target audio and video ciphertext is decrypted to obtain the audio and video plaintext, including: Extract the first target identifier and audio / video encapsulation field from the target audio / video ciphertext, and decrypt the audio / video encapsulation field using the audio / video key encryption key corresponding to the first target identifier to obtain the audio / video decryption key; The audio and video decryption key and each target audio and video authentication data are used to decrypt the matched target encrypted block to obtain multiple target decryption blocks; Based on the target index information in the target audio and video ciphertext, each target decryption block is concatenated to obtain the audio and video plaintext.

5. The meeting data security management method according to claim 3, characterized in that, The target text ciphertext is decrypted to obtain the plaintext text, including: Extract the second target identifier and text encapsulation field from the target text ciphertext, and decrypt the text encapsulation field using the text key encryption key corresponding to the second target identifier to obtain the text decryption key; The target text encrypted data in the target text ciphertext is decrypted using the text decryption key and the target text authentication data to obtain the plaintext text.

6. The meeting data security management method according to claim 1, characterized in that, Also includes: In response to a key encryption key leak event, create a new key encryption key and set its lifecycle state to active. Change the lifecycle status of the historical key encryption key to a decryption-only status; Scan all historically encapsulated fields encrypted with the historical key encryption key; The encryption key for each historical encapsulation field is recovered using the historical key encryption key, and each recovered encryption key is recapsulated as the corresponding new encapsulation field using the new key encryption key.

7. The meeting data security management method according to claim 1, characterized in that, Also includes: In response to a historical encryption key leak, a new encryption key body is created; Decrypt each historical encapsulation field and scan all ciphertext data encrypted using the historical encryption key; Each ciphertext data is recovered using the historical encryption key to obtain plaintext data, and each ciphertext data is re-encrypted using the new encryption key body as the corresponding new ciphertext data.

8. A conference data security management device, characterized in that, include: The acquisition module is used to respond to the conference encryption command, acquire the conference data that needs to be privately stored, and decompose the conference data into text data and audio / video data; The determination module is used to determine the meeting identifier corresponding to the meeting data; A generation module is used to generate a text encryption key and text authentication data for finding the text data; obtain a first key encryption key whose lifecycle is active; encrypt the text data using the text encryption key and the text authentication data to generate text encryption data; and encapsulate the text encryption key using the first key encryption key to obtain a first encapsulation field. A first integrity verification value is generated using the encrypted text data and the authenticated text data; Based on the identifier of the first key encryption key, the encrypted text data, the text authentication data, the first encapsulation field, and the first integrity verification value, a text ciphertext is generated, and the text ciphertext is stored in correspondence with the meeting identifier; The encryption module is used to generate audio and video encryption keys and obtain the second key encryption key whose lifecycle is active. The second key is used to encrypt the audio and video encryption key, which is then encapsulated to obtain a second encapsulation field. The audio and video data is then divided into blocks to obtain multiple plaintext blocks and the sequence number, plaintext start byte position, plaintext byte count, and ciphertext start byte position of each plaintext block. Generate audio and video authentication data for locating each plaintext block; encrypt the corresponding plaintext block using the audio and video encryption key and each audio and video authentication data to generate an encrypted block; generate a second integrity check value using each encrypted block and the corresponding audio and video authentication data. An index is constructed based on the sequence number of each plaintext block, the position of the first byte of the plaintext, the number of plaintext bytes, and the position of the first byte of the ciphertext. Based on the identifier of the second key encryption key, the index information, each encryption block, each audio and video authentication data, the second encapsulation field, and each second integrity check value, audio and video ciphertext is generated, and the audio and video ciphertext is stored in correspondence with the conference identifier.

9. A conference data security management device, characterized in that, Including memory and processor; The memory is used to store programs; The processor is used to execute the program to implement the various steps of the conference data security management method as described in any one of claims 1-7.

10. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements each step of the conference data security management method as described in any one of claims 1-7.

Images