Method for hiding and dynamically decrypting encrypted data in instant messaging text

Abstract

The invention discloses a method for hiding and dynamically decrypting encrypted data in an instant messaging text, and belongs to the technical field of encrypted communication and steganography. In the scheme, a sending end retrieves an AES key corresponding to a Key ID through a Bluetooth module, after AES-CBC encryption is carried out on a plaintext, encrypted data, the Key ID and a check code are packaged and mapped into a zero-width character sequence, the zero-width character sequence is spliced into a visible camouflage text to form a hidden text, and the hidden text is transmitted through an instant messaging platform. And the receiving end extracts the zero-width character sequence, analyzes the zero-width character sequence to obtain the Key ID, and retrieves the corresponding AES key through the Bluetooth module to complete decryption of the encrypted data. A Key Record stored in the Bluetooth module comprises information such as Key ID, authority, expiration timestamp and the like, and supports dynamic management of keys in multiple scenes.

Description

Technical Field

[0001] The present invention relates to the field of encrypted communication and steganography technology, and in particular to a method for hiding encrypted data in instant messaging text and dynamically decrypting the data. Background Art

[0002] In existing instant messaging applications, the ciphertext sent is usually "garbled code after Base64" (Note: Base64 is an encoding method that converts binary data into ASCII printable characters. It is mainly used to maintain data integrity and readability when binary content (such as pictures, audio, encrypted data) needs to be transmitted or stored in text form.), which is easily identified as encrypted content, lacks concealment, and is easily exposed after being screenshot or forwarded.

[0003] Traditional steganographic methods using spaces, abbreviations, and other text have limited capacity, and many platforms merge spaces or remove special characters, resulting in the loss of steganographic data. A single symmetric key is used for a long time. Once leaked, all historical messages will be at risk, and flexible rotation cannot be achieved in one-to-one, group, or multi-party sharing scenarios. Symmetric keys are pre-written into each user's Bluetooth security chip. Apps read the keys via BLE during encryption and decryption, preventing keys from being stored in plain text at the app level. This improves security and supports fast offline retrieval. Existing technologies do not yet simultaneously meet the requirements for "large-capacity steganography," "key IDs carried in messages and local multi-key retrieval," and "dynamic key management in multiple scenarios." Summary of the Invention

[0004] The purpose of this invention is to provide a method for hiding encrypted data in instant messaging texts and dynamically decrypting it. This method aims to combine the local multi-key storage of the Bluetooth module with the Key ID indexing mechanism to achieve rapid offline retrieval at the receiving end and use the correct AES symmetric key for decryption, meeting the security, concealment and dynamic management requirements in one-to-one, group and multi-party sharing scenarios.

[0005] The present invention is implemented as follows: a method for hiding encrypted data in instant messaging text and dynamically decrypting the data, comprising the following steps: (1) The sender retrieves the AES key corresponding to the Key ID through the Bluetooth module; (2) The sender uses the AES key to perform AES-CBC encryption on the plaintext to generate encrypted data containing the initialization vector IV and the ciphertext; (3) The sender performs Base64 encoding on the encrypted data, calculates the first 4 bytes of the SHA256 hash value of the encoded data as a check code and performs Base64 encoding on it, concatenates the encoded check code, the hexadecimal string of the Key ID, and the Base64 encoded data into a Package, then converts the Package into a zero-width character sequence and concatenates it with the visible disguised text to form the hidden text; (4) The hidden text is transmitted to the receiving end via the instant messaging platform; (5) The receiving end extracts the zero-width character sequence from the hidden text, parses it to obtain the Package and separates the Key ID from it; (6) The receiving end retrieves the AES key corresponding to the Key ID through the Bluetooth module; (7) The receiving end uses the retrieved AES key and the IV in the encrypted data to perform AES-CBC decryption on the ciphertext to obtain the plaintext.

[0006] Preferably, the step of the transmitting end retrieving the AES key through the Bluetooth module includes: sending the Key ID to the Bluetooth module, the Bluetooth module queries the KeyRecord and verifies that its status is valid, not expired and the permission is allowed, and then returns the corresponding 16-byte AES key.

[0007] Preferably, the step of converting the Package into a zero-width character sequence includes: converting each character in the Package into ASCII binary, using zero-width space (U+200B) to represent "0" and zero-width non-hyphen (U+200C) to represent "1", to generate a zero-width character sequence.

[0008] Preferably, the step of extracting the zero-width character sequence from the hidden text includes: separating the visible disguised text and the zero-width character sequence by a zero-width separator (U+2063), converting the zero-width space to "0", converting the zero-width non-hyphen to "1", and restoring each 8-bit binary to ASCII characters to obtain a Package.

[0009] Preferably, the receiving end recalculates the first 4 bytes of the SHA256 hash value of the Base64-encoded data, compares it with the checksum after Base64 decoding, and continues the decryption operation if they are consistent.

[0010] Preferably, the KeyRecord contains a 2-byte Key ID, a 1-byte permission, a 4-byte expiration timestamp, a 16-byte AES key, a 1-byte version number, a 1-byte status and a 4-byte CRC32 check code. The Bluetooth module verifies the validity of the KeyRecord by checking the CRC32 and comparing the current time with the expiration timestamp.

[0011] Compared with the prior art, the present invention has the following beneficial effects: The present invention has high concealment: it utilizes large-capacity steganography with zero-width characters, is imperceptible to the naked eye, and is compatible with all plain text IM platforms.

[0012] The present invention has large capacity support: zero-width mapping can carry several KB to tens of KB of ciphertext, and the steganographic content is not easily lost after copying / forwarding.

[0013] The present invention has flexible multi-key management: multiple AES keys are pre-set in the Bluetooth module, dynamically indexed by a short Key ID, supporting one-to-one, group, and three-party sharing, and realizing flexible rotation and single revocation.

[0014] The present invention has the function of offline fast decryption: the receiving end can retrieve the AES-Key from the local Bluetooth module and complete the decryption at a speed of milliseconds even when the receiving end is offline.

[0015] The present invention has security isolation and integrity verification: the AES-Key only exists in plain text in the Bluetooth module, the Package layer passes the CHK64 integrity verification, and the KeyRecord layer verifies the storage integrity through CRC32.

[0016] The present invention is easy to expand and comply with regulations: the BLE GATT interface can remotely insert / update / revoke KeyRecord, complies with commercial encryption regulations, and is suitable for various high-security communication scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic diagram of the overall flow of the system of the present invention; Figure 2 Schematic diagram of the KeyRecord search process of the system of the present invention; Figure 3 It is a timing diagram of the encryption hiding process of the system of the present invention; Figure 4 It is a timing diagram of the decryption recovery process of the system of the present invention; DETAILED DESCRIPTION

[0018] In the present invention, unless otherwise expressly specified or limited, the terms "mounted," "connected," "connect," "fixed," etc. should be understood broadly. For example, they may refer to fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two components or interaction between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0019] The following is a further description with reference to the accompanying drawings and specific embodiments: Example 1 like Figure 1-4 As shown, the specific usage is as follows: 1. Local key retrieval on the sender: The user selects the Key ID in the app, calls GetAESKeyFromBLE(KeyID), confirms that the KeyID is valid (status = 0x00 and not expired, permissions allowed) through the BLE GATT service "Query KeyRecord", and then "Read AES Key Characteristics" to obtain the 16-byte AES key Ke.

[0020] 2. The sender encrypts and generates hidden text A 16-byte IV is randomly generated, and the plaintext is padded with PKCS#7 before being encrypted with AES-CBC to obtain raw=IV‖ciphertext.

[0021] Base64 encodes raw to get B64; calculates the first 4 bytes CHK of SHA256 (B64), and then Base64 encodes CHK into 8 characters CHK64.

[0022] Convert the Key ID to a 4-byte hexadecimal string KeyID_str and assemble Package=CHK64+":"+KeyID_str+":"+B64.

[0023] Convert each character in Package to ASCII binary, use zero-width space (U+200B) to represent "0", and zero-width non-hyphen (U+200C) to represent "1", generating a zero-width sequence ZW.

[0024] Select the visible disguised text, insert a zero-width separator (U+2063) at the end, and then concatenate ZW to form the hidden text.

[0025] The app writes Hidden to the output box and copies it to the clipboard, which the user then pastes into any IM interface to send.

[0026] 3. Network transmission: "Hidden" only contains visible disguised text and zero-width character sequences. The receiver will only see the visible text and will not notice the steganographic data.

[0027] 4. The receiving end extracts and retrieves the key The receiver pastes Hidden in the App, searches for the zero-width delimiter, treats the first part as visible disguised text, and treats the second part as a zero-width sequence ZW.

[0028] Restore every 8 bits of U+200B→"0" and U+200C→"1" in ZW to a character to get Package.

[0029] Split out CHK64, KeyID_str, and B64, recalculate SHA256 on B64 and take the first 4 bytes, compare with Base64Decode (CHK64), if they do not match, prompt "Verification failed" and exit.

[0030] Base64Decode (B64) gets raw=IV‖ciphertext and converts KeyID_str into integer KeyID.

[0031] Call Ke=GetAESKeyFromBLE (KeyID) and read the AES-Key after confirming that the KeyID is valid. If it fails, it will prompt "Invalid key".

[0032] 5. The receiving end decrypts and outputs the plaintext: Use Ke and the IV extracted from the raw to perform AES-CBC decryption on the ciphertext and remove the padding to obtain the plaintext, which is displayed by the App and copied to the clipboard.

[0033] Bluetooth module key management (1) KeyRecord structure (32B): contains 2 bytes of key_id, 1 byte of permission, 1 byte of reserved, 4 bytes of expire_timestamp, 16 bytes of aes_key, 1 byte of version, 1 byte of status, 4 bytes of mac, and 2 bytes of padding.

[0034] (2)Storage Organization: Each 4KB sector of the SPI Flash can store 128 KeyRecords. A total of 8 sectors (32KB) are used, which can store 1024 records.

[0035] (3)Insert / Update / Revoke Insert / Update: Write a complete 32B KeyRecord through BLE. The module verifies the mac. If the KeyID already exists and status = 0x00, it will overwrite and update, and version++. Otherwise, it will be written into blank or invalid entries.

[0036] Revoke: Write 4B [KeyID || management signature] through BLE. After the module verifies the signature, it sets the status of the corresponding record to 0xFF and version++. It will not be erased immediately and will be cleaned up during subsequent garbage collection.

[0037] (4)Search and Retrieval Sequential Scan: Traverse all records. If rec.key_id == KeyID and rec.status = 0x00, verify CRC32 (the first 28B of rec) and rec.mac. If they are consistent, the current time < expire_timestamp, and the permission bit allows, then return rec.aes_key. Otherwise, continue or return NULL.

[0038] Optional Hash Index: Perform CRC16 hash on the KeyID to locate the initial slot, and linearly probe until found or an empty slot to improve efficiency.

[0039] BLE GATT Interface: Includes KeyMgmt service, Write KeyRecord characteristic, Revoke KeyRecord characteristic, Query KeyRecord characteristic, Read AES Key characteristic; For example: one-on-one private chat Party B agrees that KeyID = 0x0010. Party A selects this KeyID, retrieves the corresponding AES key, encrypts it using AES-CBC, hides the ciphertext as "The Peach Blossom Pool is a thousand feet deep [ZW]" and sends it. After Party B pastes it, it extracts the KeyID, retrieves the same AES key, and decrypts to restore the plaintext; Three-party group A, B, and C share KeyID = 0x0030. Party A selects this KeyID for encryption, hiding, and then sends it to the group. After Party B or C pastes it, they extract the KeyID, retrieve the same AES key, and decrypt to obtain the plaintext.

[0040] The above is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that the present invention is susceptible to various modifications and variations. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A method for hiding encrypted data in instant messaging text and dynamically decrypting it, characterized in that: The following steps are involved: (1) The sender retrieves the AES key corresponding to the Key ID through the Bluetooth module; (2) The sender uses the AES key to perform AES-CBC encryption on the plaintext to generate encrypted data containing the initialization vector IV and the ciphertext; (3) The sender performs Base64 encoding on the encrypted data, calculates the first 4 bytes of the SHA256 hash value of the encoded data as a check code and performs Base64 encoding on it, concatenates the encoded check code, the hexadecimal string of the Key ID, and the Base64 encoded data into a Package, then converts the Package into a zero-width character sequence and concatenates it with the visible disguised text to form the hidden text; (4) The hidden text is transmitted to the receiving end via the instant messaging platform; (5) The receiving end extracts the zero-width character sequence from the hidden text, parses it to obtain the Package and separates the KeyID from it; (6) The receiving end retrieves the AES key corresponding to the Key ID through the Bluetooth module; (7) The receiving end uses the retrieved AES key and the IV in the encrypted data to perform AES-CBC decryption on the ciphertext to obtain the plaintext.

2. A method for hiding encrypted data in instant messaging text and dynamically decrypting it according to claim 1, characterized in that: The step of the transmitting end retrieving the AES key through the Bluetooth module includes: sending the Key ID to the Bluetooth module, the Bluetooth module queries the KeyRecord and verifies that its status is valid, not expired and the permission is allowed, and then returns the corresponding 16-byte AES key.

3. A method for hiding encrypted data in instant messaging text and dynamically decrypting it according to claim 2, characterized in that: The step of converting the Package into a zero-width character sequence includes: converting each character in the Package into ASCII binary, using a zero-width space (U+200B) to represent "0" and a zero-width non-hyphen (U+200C) to represent "1", and generating a zero-width character sequence.

4. The method for hiding encrypted data in instant messaging text and dynamically decrypting the data according to claim 1, characterized in that: The step of extracting the zero-width character sequence from the hidden text includes: separating the visible disguised text and the zero-width character sequence by using a zero-width separator (U+2063), converting the zero-width space to "0", converting the zero-width non-hyphen to "1", and restoring each 8-bit binary to ASCII characters to obtain a Package.

5. The method for hiding encrypted data in instant messaging text and dynamically decrypting the data according to claim 1, characterized in that: The receiving end recalculates the first 4 bytes of the SHA256 hash value of the Base64-encoded data and compares it with the checksum after Base64 decoding. If they are consistent, the decryption operation continues.

6. The method for hiding encrypted data in instant messaging text and dynamically decrypting the data according to claim 2, characterized in that: The KeyRecord contains a 2-byte Key ID, a 1-byte permission, a 4-byte expiration timestamp, a 16-byte AES key, a 1-byte version number, a 1-byte status, and a 4-byte CRC32 checksum. The Bluetooth module verifies the validity of the KeyRecord by checking the CRC32 and comparing the current time with the expiration timestamp.

Images