Method and system for protecting the authenticity of images generated by a machine learning model

Abstract

The claimed group of inventions relates to digital data protection means for confirming the authenticity of digital data. The technical result is that of providing more efficient protection of AI-generated images in order to determine the authenticity thereof. A method for protecting the authenticity of images generated by a machine learning model in response to a text query comprises the steps of: receiving user input data for the generation of an image, generating an image with the aid of a machine learning model, registering the user input data containing: the time of input, the user ID and the text query, generating an insertion for protecting the generated image, said insertion consisting of the aforesaid data, generating an encrypted sequence by encrypting the insertion data, embedding the encrypted sequence in the discrete cosine transform coefficients of the generated image, and presenting the protected image to the user.

Description

METHOD AND SYSTEM FOR PROTECTING THE AUTHENTICITY OF IMAGES GENERATED BY A MACHINE LEARNING MODEL AREA OF TECHNOLOGY

[0001] The claimed solution relates to the field of information technology, namely to means of protecting digital data for the purpose of confirming their authenticity. LEVEL OF TECHNOLOGY

[0002] With the widespread use of artificial intelligence (AI) and various machine learning models that can generate images based on user text queries, there is a need to apply mechanisms to protect the generated images for the purpose of subsequent confirmation of their authenticity.

[0003] One of the needs for this type of mechanism is to prevent attribution of AI-generated images. Another concern is protecting images from third-party modifications that could distort the original AI-generated image, which could subsequently be used as false information discrediting the creators of such models for their ability to generate images of prohibited or obscene content.

[0004] One example of image protection in the prior art involves the use of digital signatures embedded in generated images. These signatures are invisible to the human eye and can only be obtained by subsequent decryption of the protected images using algorithmic extraction (see the article "Copyright Protection of Images Using Robust Digital Signatures" / / N. Nikolaidis et al., 1996). According to this prior art solution, the signature is generated in the spatial domain by slightly varying the intensity level of randomly selected image pixels. The signature is determined by comparing the average intensity of the marked pixels with that of the unmarked pixels. Statistical hypothesis testing is used for this purpose. The signature can be constructed to be resistant to JPEG compression and low-pass filtering.

[0005] This approach was the basis for the declared solution in terms of the use of the implementation of protective information in the brightness coefficients of the JPEG format, as well as a number of improvements that allow not only more efficient labeling of generated images, but also detection of possible future changes. ESSENCE OF THE INVENTION

[0006] The present invention is aimed at solving the technical problem of creating a new, effective method for protecting digital images with the possibility of subsequent confirmation of their authenticity and possible changes.

[0007] The technical result is to increase the efficiency of protecting AI-generated images for the purpose of determining their authenticity.

[0008] An additional technical result is the ability to determine the immutability of images based on embedded security information.

[0009] In a preferred embodiment of the invention, a method is claimed for protecting the authenticity of images generated based on a text query by a machine learning model, comprising the steps of: a) receiving user input data for generating an image; b) generating an image in JPG format using a machine learning model; c) recording user input data containing: the input time, the user ID and the text query; d) extracting blocks of discrete cosine transform (DCT) coefficient values ​​for the luminance (Y) and color (CL- and Cr) components of the image from the file data of the generated image in JPG format; e) receiving a sequence of low-frequency DCT coefficients (DC- coefficients) and high-frequency DCT coefficients (AC- coefficients) for all blocks of the luminance component, and calculating a hash function based on at least one AC- coefficient and / or at least one DC- coefficient;f) using a given key, determine the blocks of DCT coefficients and the positions of the DCT coefficients within the blocks, excluding the DC DCT coefficients used in step e) in the blocks; g) form an embedding for protecting the generated image, consisting of a sequence including: the input time, the user ID, the text query, the value of the hash function obtained in step e), and additional text information; h) generate an encrypted sequence by encrypting the data obtained in step g) with a private key; i) embed the values ​​of the hash function obtained in step e) and the encrypted sequence obtained in step h) into the DCT coefficients of the generated image, determined in step f); j) provide the secure image to the user.

[0010] In one particular example of implementation, at step d), blocks are extracted for embedding information of at least one of the Y-, Ь- and Сг- components of the image.

[0011] In another particular example of implementation, at step e), the sequence of DC coefficients consists of the DCT coefficients of one of the Y, Cb, and Cr components of the image.

[0012] In another particular example of implementation e) the hash function is calculated using the DCT coefficients of at least one of the Y-, Cb- and Cr-components of the image.

[0013] In another particular example of implementation, at step f), blocks of DCT coefficients and positions of DCT coefficients within the blocks are determined using a given key, including any AC coefficients and DC coefficients of the DCT of at least one of the Y-, Cb- and Cr-components of the image.

[0014] In another particular embodiment, at step c), a compressed image is additionally formed based on the generated image.

[0015] In another particular example of implementation, a sequence of bytes is formed based on the compressed image, which is added to the data at step g) when forming the embedding.

[0016] In another preferred embodiment, a system is claimed for protecting the authenticity of images generated based on a text query by a machine learning model, comprising at least one processor and at least one memory associated with the processor and containing machine-readable instructions that, when executed by the processor, allow it to: receive user input data for generating an image; generate an image in JPG format using a machine learning model; record user input data containing: the input time, the user ID and the text query; extract from the file data of the generated image in JPG format blocks of values ​​of the discrete cosine transform (DCT) coefficients for the luminance (Y) and color (CL and Cr) components of the image; obtain a sequence of low-frequency DCT coefficients (DC coefficients) and high-frequency DCT coefficients (AC coefficients) by all blocks of the brightness component, and calculate the hash function based on at least one AC coefficient and / or at least one DC coefficient; using a given key, determine the blocks of DCT coefficients and the positions of the DCT coefficients within the blocks, excluding the DC DCT coefficients in the blocks, to calculate the hash function; form an embedding for protecting the generated image, consisting of a sequence including: input time, user ID, text query, the value of the calculated hash function, and additional text information; generate an encrypted sequence by encrypting the embedding data with a private key; embed the obtained hash function value and the encrypted sequence into the selected DCT coefficients of the generated image; provide the protected image to the user. BRIEF DESCRIPTION OF DRAWINGS

[0017] Fig. 1 illustrates a general view of the method for protecting images.

[0018] Fig. 2 illustrates a block diagram of the claimed method.

[0019] Fig. 3A illustrates an example of blocks with DCT coefficients associated with blocks of image pixels.

[0020] Fig. ЗБ illustrates the positions of the DCT coefficients in the block.

[0021] Fig. ЗВ illustrates an example of the values ​​of the DCT coefficients at different positions in the block.

[0022] Fig. 4 illustrates an example of determining the DCT coefficients for embedding security information.

[0023] Fig. 5 illustrates an example of the change in DCT coefficients after embedding security information.

[0024] Fig. 6 illustrates an example of an attachment and its parts as a byte sequence.

[0025] Fig. 7 illustrates the general diagram of the computing device. IMPLEMENTATION OF THE INVENTION

[0026] Fig. 1 shows a general diagram of the claimed solution, which is implemented by processing incoming user requests (UR), which are textual descriptions of the generated image. In the field of AI, such textual requests, describing the generated object for the machine learning model, are also called "prompts." The user request (UR) can be transmitted via an API (120) implemented in a web browser or messenger (e.g., Telegram), which subsequently facilitates data exchange directly with the image generation model (130) (e.g., Kandinsky) by the user (110) and the image protection module (140).

[0027] The image protection module (140) can be implemented using an external hardware and software system, such as a server or remote workstation, providing functionality for processing incoming images (121) generated by the model (130). The module (140) can also be located in the same execution loop as the model (130), such as a server or cloud computing node.

[0028] Upon completion of the image protection module (140), security information containing an encrypted attachment is embedded into the initially generated images (121). This information allows for at least the image's authorship to be established as having been created using the model (130), as well as the identifier of the user who generated the request and the request text itself. The protected image (141) is subsequently transmitted to the user (110) via the API (120), for example, by displaying the image (141) in a web browser or instant messenger.

[0029] Data exchange within the framework of the system implementation is based on standard principles of data exchange, in particular with the help of the Internet computing network, which can be implemented using any known principles known from the state of the art.

[0030] Fig. 2 shows an example of implementing the claimed method (200) for protecting generated images. At the first stage (201), user input is received for image generation by the model (130). The user input includes a user text query, a user ID (e.g., IP address, MAC address, registration ID, etc.), and the time of the text query. This data is recorded by the image protection module (140) for subsequent generation of security information for embedding in the image.

[0031] Next, at step (202), the model (130) generates an image (121) according to the user request and transmits it to the image protection module (140). The image is generated in JPG (or JPEG) format [1-3]. Upon receipt by the module (140) of the generated image (121) in JPG format, at step (203), blocks of discrete cosine transform (DCT) coefficient values ​​are extracted from the JPG file for the luminance (Y) and color (CL (relative blueness) and CR (relative redness) components of the image.

[0032] Fig. 3A shows an example of obtaining blocks with discrete cosine transform (DCT) coefficients. When encoding the original image (represented as RGB pixels) into JPEG, these coefficients are obtained as follows. The resulting image is divided into color channels. The resulting image channels (121) are divided into blocks (3001 - 300 п) 8x8 pixels in size. Number of blocks (3001 - 300 п ) depends on the resolution of the generated image (121) or the size of the raster image. For example, for an image measuring 1920x1080 pixels, the number of blocks will be 240 horizontally and 135 vertically.

[0033] Each block (3001 - 300 п ) is subjected to a discrete cosine transform (DCT), which is a type of discrete Fourier transform. In this case, each of the blocks (3001 - 300 п ) contains one DC coefficient (ZON) at position (0,0) within the block and 63 AC coefficients (ZON - 30164) at other positions within the block. The DC coefficient is the average value of all values ​​within the block, as roughly shown in Fig. ЗВ.

[0034] Fig. 3B shows an example of positioning the DCT coefficients within a block. DC coefficients are also called low-pass coefficients. In the current description, the position within a block (0,0) is also designated as the 1st position. Positions (Y1, Y2), Y1 = 0.7, Y2 = 0.7, (El, Y2) (0,0) are designated from the 2nd to the 64th positions.

[0035] The JPEG image file itself ("<file_name>.jpg") is a compressed storage of the aforementioned DCT coefficients. Thus, step (203) extracts these blocks of DCT coefficients directly from the JPEG file.

[0036] At step (204), the hashing of the sequence of DC coefficients is performed; for this, all values ​​in the blocks are taken and the selected hashing algorithm is applied to them, for example, SHA-256, SHA-512, etc.

[0037] As shown in Fig. 4, at step (205), the AC coefficients in blocks (3001 - 300n) are determined using the selected key (seed) for subsequent implementation protective information. The initial ordered sequence (401) of DCT coefficient blocks (X1, X2) and the positions of the coefficients themselves within the blocks (Y1, Y2) is taken: {(X1, X2) - (Y1, Y2)}. Where (X1, X2) is the coordinate of the DCT coefficient block within the image. images, ^images is the image width; (Y1, Y2) are the coordinates of the positions of the DCT coefficients inside the blocks: Y1 = 0.7, Y2 = 0.7, (Y1, Y2) #= (0.0). Fig. 3B shows an example of such positions. Next, the selected sequence (401) of AC coefficients is mixed using a given key, subsequently forming a new sequence (402) of AC coefficients.

[0038] At step (206), a security attachment is generated. The attachment consists of a public (unencrypted) part and an encrypted part. The encrypted part is an encrypted data sequence, including the following data: the entry time, the user ID, the text query (prompt request), the hash value obtained at step (204), and additional text information (e.g., the designation "I am a Sber model"). The public part may include information such as a verification digit, a hash sequence of the selected DCT coefficients, and a check digit of the integrity of the encrypted attachment. An example of such an attachment is shown in Fig. 6.

[0039] In one particular embodiment of the invention, arbitrary data of arbitrary size, changing depending on the request or its conditions, is subject to embedding. In this case, when extracting data, their quantity and their size are initially unknown. To enable their extraction, the following data is inserted at the beginning of the data of the encrypted part: the quantity of different data in a fixed number of the first bits, the size of each of the attachments in a fixed number of subsequent bits. An example of such an attachment is shown in Fig. 6. At the beginning of the encrypted part of the attachment, the amount of data is located - 3 data: the image hash; text information, including a fixed text phrase, user ID, request time, request "prompt"; compressed original image. The first 32 bits of the encrypted part of the attachment are allocated for the quantity of data. Next come the sizes of the data - 64 bytes for the hash; 163 bytes for the text information, 3756 bytes for the compressed original image.Each size is allocated the next 32 bits of the encrypted portion of the attachment.

[0040] Additionally, the protective attachment may include a compressed generated image (121), which is translated into a sequence of bytes appended to byte sequences of the remaining data. The resulting attachment at step (206) is signed with the private key at step (207), thereby forming part of the secure attachment. The resulting encrypted byte sequence is represented as a sequence of bits.

[0041] Next, at step (208), information is embedded into the sequence of DCT coefficients obtained at step (205).

[0042] First, the plaintext (unencrypted) information is embedded. This information may include a data sequence such as a check digit, a hash of the DC coefficient sequence (obtained in step (204)), or a security embedding integrity check digit, such as one calculated using CRC16, CRC32, CRC64, or any other checksum or hashing algorithm. This information is represented as a bit sequence.

[0043] Next, the secure attachment obtained at step (207) is embedded. The secure image (141) with the information embedded at step (208) is displayed at step (209) on the user's device.

[0044] The embedding at step (208) is built directly into the AC block coefficients (3001 - 300) selected at step (205) п ), included in the shuffled sequence (402).

[0045] An example of encoding an embedding within a JPG file is shown in Fig. 5. During this step, a shuffled sequence of DCT coefficient blocks and the positions of the coefficients within the blocks is formed. In Fig. 5, the first bit is embedded in block (31, 70) in the coefficient at position (1, 0). The second bit is embedded in block (8, 69) in the coefficient at position (0, 2), and so on. Embedding is performed as the remainder from dividing the DCT coefficient value by 2. In other words, if the remainder from dividing by 2 is 0, this means that a bit with the value 0 is embedded in the coefficient. If the remainder from dividing by 2 is 1, this means that a bit with the value 1 is embedded in the coefficient. If the current value of the DCT coefficient does not produce the desired remainder, this value is increased or decreased by 1.

[0046] As shown in the example in Fig. 5, the first bit of the embedded information is 1. The value of the coefficient in the block (31, 70) at position (1, 0) is 17. The remainder of dividing 17 by 2 is 1. The remainder is the same as the value of the embedded bit. The second bit of the embedded information is 0. The value of the coefficient in the block (8, 69) at position (0, 2) is 23. The remainder of dividing 23 by 2 is 1. The remainder is not the same as the value The embedded bit. We change the value of 23 by subtracting 1 from it. The value now equals 22. The remainder of dividing 22 by 2 is now 0, which matches the value of the embedded bit.

[0047] Information embedding can be achieved by encoding information into the least significant bit (LSB) in blocks of DCT coefficients. The LSB is the last bit in the bitmap whose change least significantly alters the value itself.

[0048] An example of coding in the DCT block of coefficients in Fig. ЗВ: 15 - 00010101 (no change required). NZB=1 4 - 00000100 (change). NZB=0 6 - 00000110 (change). NZB=0 3- 00000011 (change). NZB=1

[0049] Let's look at an example of embedding text information. The text to be embedded is: SBER - 01010011 01000010 01000101 01010010. Let's consider embedding the letter "S" - 01010011. The value 4 is taken in bit form - 01010011. The embedding proceeds from left to right: 0-1-0-1, etc. - Step 1. The first bit of "S" = 0 and is embedded in the DCT coefficient with the value 4. The LSB for 4 is 0 (00000100). It is necessary to embed the 0 from "S" and the LSB for 4 is also 0. Therefore, the value does not change. - Step 2. The second bit of "S" = 1 and is embedded in the DCT coefficient with the value 6. The LSB for 6 is 0 (00000110). We need to embed the 1 from "S", and for 6 the LSB = 0. Therefore, the value changes to 1 and takes the bit form 00000111. In other words, 6 is replaced by 7. - Step 3. The third bit of "S" is 0 and is embedded in the DCT coefficient with the value 3. The LSB for 3 is 1 (00000011). We need to embed the 0 from "S", and for 3 the LSB = 1. Therefore, this value is changed to 0 and takes the bit form 00000010. In other words, 3 is replaced by 2. This process continues until all required bits are embedded. Ultimately, a DCT matrix of coefficients is formed with encoded information regarding the change in the selected AS coefficients.

[0050] The final embedded security data sequence may look like this: [check value (e.g. 537), DC hash, encrypted attachment integrity check value, encrypted attachment]. The data in the encrypted attachment may be the following sequence: [number of attachments (e.g. 3), size of 1st attachment, size of 2nd attachment, size of 3rd attachment, hash of DC coefficients, text (“I am a Sber model...”), thumbnail of original image (highly compressed original image)].

[0051] In byte form it will look like this: 00000219ac3eb891bc32652a83b4ff62cc2e49de3293d99e24ae8907e90c96b55cb5578a78d78e88 7f5f436f6b9b989c6896b689e986s64a3509ee90fca..., where 00000219 is the byte form of the number 537, ac3eb891bc32652a83b4ff62cc2e49de32 is the byte form of the hash, 93d99e24 is the byte form of the CRC32 check digit value equal to 2480512548, then comes the encrypted data. Figure 6 shows an example of a byte sequence to be embedded. This sequence is represented as a bit sequence.

[0052] The obtained new values ​​of the DCT coefficients (Fig. 5) are compressed (encoded) according to the JPEG standard and saved as a new image file.

[0053] When embedding this sequence into the selected DCT coefficients, the resulting image (141) remains visually indistinguishable from the originally generated image (121). Even small changes to the pixels of this image lead to changes in the DCT coefficients, which destroys the embedded embedding. This fact allows for subsequent integrity verification of the embedded security information to confirm that image (141) is genuine, i.e., created using model (130), and that its content has not been altered.

[0054] Next, we will consider the process of extracting embedded information when checking a protected image (141).

[0055] Similar to steps (203) - (205), the hash value of the DC coefficients (image hash) and the sequence of DCT coefficients into which information embedding was potentially performed are obtained.

[0056] The following algorithm is then executed.

[0057] Step 1. The first 4 bytes are extracted to obtain a check digit. This check digit is verified to be the original check digit. If the check digit matches, extraction continues. If not, a message is generated indicating that the digital signature was not found or was corrupted.

[0058] Step 2. The next 64 bytes are extracted. This is the hash of the DC coefficients. The resulting value is checked against the actual hash of the DC coefficients. If the hash matches, extraction continues. If not, a message is displayed indicating that the digital signature was not found or was corrupted.

[0059] Step 3: The next 4 bytes are extracted, which allows us to obtain the checksum of the encrypted attachment.

[0060] Step 4. The encrypted attachment is extracted. All subsequent bits in the attachment refer to the encrypted attachment. At this stage, the size of the attachment is unknown. However, in the first block of the encrypted attachment—256 bytes for RSA—the lengths of the attachments are found. The first 256 bytes are extracted and decrypted using the public key. The first 4 bytes in this block are the number of attachments—in the example in Fig. 6, there are 3 attachments. Each subsequent 4 bytes is the size of each of these attachments. They contain the numbers 64, 163, and 3756. If the size of any attachment is greater than 30,000 (the maximum attachment limit), the ciphertext block has been modified, and a message is generated indicating that the digital signature was not detected or was corrupted. Otherwise, the potential sizes of the attachments are obtained and extraction continues.

[0061] Next, the size of the encrypted attachment is determined. According to the example in Fig. 6, the obtained 64 bytes are the size of the first attachment, which is the hash of the DC coefficients, then 163 bytes are the size of the second attachment - this is the text size. The size of the third attachment is 3756 bytes - this is the image thumbnail (compressed image). Then the total size of the encrypted attachment is: 64 + 163 + 3756 = 3983 (the attachment itself); 4 bytes are added for the number of attachments and 3 more times 4 bytes for their lengths. The result is as follows: 64 + 163 + 3756 + 4 + 3 * 4 = 3999 bytes. Since the encryption block has a size of 256, then in the given example 3999 / / 256 = 16 entire encryption blocks, which is equal to 4096 bytes of encrypted attachment.

[0062] 4096 bytes are extracted and used to calculate the CRC32 checksum. If the value matches the checksum obtained in step 3, extraction continues. If not, a message is generated indicating that the digital signature was not found or was corrupted.

[0063] Decryption of 4096 bytes. From the first block, as noted above, the number of attachments, their lengths, and the attachments themselves are obtained. The decrypted byte sequence is broken down by the number of bytes in each attachment. The original attachments are obtained.

[0064] The hash from the decrypted data is verified against the hash from the attachment (which was already compared with the actual hash in step 2). If the hashes match, a message is displayed confirming the digital signature has been verified, along with the extracted information—the hash of the DC coefficients, the text, and a thumbnail of the generated image. If not, a message is displayed indicating the digital signature was not detected or was corrupted.

[0065] Fig. 7 shows a general view of a computing device (500) suitable for performing the method (200). The device (500) may be, for example, a server or another type of computing device that can be used to implement the claimed technical solution, including: a smartphone, tablet, laptop, computer, etc. The device (500) may also be part of a cloud computing platform.

[0066] In general, the computing device (500) comprises one or more processors (501), memory means such as RAM (502) and ROM (503), input / output interfaces (504), input / output devices (505), and a device for network interaction (506), connected by a common information exchange bus.

[0067] The processor (501) (or several processors, multi-core processor) can be selected from a range of devices that are widely used at the present time, for example, from Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™, etc. A graphics processor can also be used as a processor (401), for example, from Nvidia, AMD, Graphcore, etc.

[0068] RAM (502) is random access memory (RAM) and is designed to store machine-readable instructions executed by the processor (501) to perform the necessary logical data processing operations. RAM (502) typically contains executable instructions from the operating system and corresponding software components (applications, software modules, etc.).

[0069] ROM (503) represents one or more permanent data storage devices, such as a hard disk drive (HDD), a solid-state drive (SSD), flash memory (EEPROM, NAND, etc.), optical storage media (CD-R / RW, DVD-R / RW, BlueRay Disc, MD), etc.

[0070] To organize the operation of the device components (500) and to organize the operation of external connected devices, various types of I / O interfaces (504) are used. The choice of the appropriate interfaces depends on the specific design of the computing device, which may include, but are not limited to: PCI, AGP, PS / 2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS / Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0071] To ensure user interaction with the computing device (500), various means (505) of I / O information are used, for example, a keyboard, a display (monitor), a touch display, a touchpad, a joystick, a mouse, a light pen, a stylus, a touch panel, a trackball, speakers, a microphone, augmented reality tools, optical sensors, a tablet, light indicators, a projector, a camera, biometric identification tools (retinal scanner, fingerprint scanner, voice recognition module), etc.

[0072] The network interaction means (506) ensures the transmission of data by the device (500) via an internal or external computer network, for example, an Intranet, the Internet, a LAN, etc. One or more means (506) may be, but are not limited to: an Ethernet card, a GSM modem, a GPRS modem, an LTE modem, a 5G modem, a satellite communication module, an NFC module, a Bluetooth and / or BLE module, a Wi-Fi module, etc.

[0073] Additionally, satellite navigation tools included in the device (500) can also be used, for example, GPS, GLONASS, BeiDou, Galileo.

[0074] The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be interpreted as limiting other, particular examples of its implementation that do not go beyond the scope of the requested legal protection, which are obvious to specialists in the relevant field of technology. Sources of information: 1. Hamilton, Eric: JPEG File Interchange Format, Version 1.02. 1 September 1992; 2. Recommendation ITU-T T.871: Information technology - Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF). Approved 14 May 2011; posted 11 September 2012; 3. Recommendation ITU-T T.81 : Information technology - Digital compression and coding of continuous-tone still images - Requirements and guidelines. Approved 18 September 1992; posted 14 April 2004.

Claims

FORMULA 1. A method for protecting the authenticity of images generated based on a text query by a machine learning model, comprising the steps of: a) receiving user input data for generating an image; b) generating an image in JPG format using a machine learning model; c) recording user input data containing: the input time, the user ID and the text query; d) extracting blocks of discrete cosine transform (DCT) coefficient values ​​for the luminance (Y) and color (CL- and Cr) components of the image from the file data of the generated image in JPG format; e) receiving a sequence of low-frequency DCT coefficients (DC- coefficients) and high-frequency DCT coefficients (AC- coefficients) for all blocks of the luminance component, and calculating a hash function based on at least one AC- coefficient and / or at least one DC- coefficient;f) using a given key, determine blocks of DCT coefficients and positions of DCT coefficients within the blocks, excluding in the blocks the AC coefficients and / or DC coefficients of the DCT used in step e); g) form an embedding for protecting the generated image, consisting of a sequence including: the input time, the user ID, the text query, the value of the hash function obtained in step e), and additional text information; h) generate an encrypted sequence by encrypting the data obtained in step g) with a private key; i) embed the values ​​of the hash function obtained in step e) and the encrypted sequence obtained in step h into the DCT coefficients of the generated image determined in step i); j) provide the protected image to the user.

2. The method according to claim 1, wherein step d) comprises extracting blocks for embedding information of at least one of the Y-, Ь- and Сг- components of the image.

3. The method according to claim 1, wherein at step e) the sequence of DCT coefficients consists of the DCT coefficients of one of the Y-, Cb- and Cr- components of the image.

4. The method according to claim 1, wherein at step e) the hash function is calculated using the DCT coefficients of at least one of the Y-, Cb- and Cr-components of the image.

5. The method according to claim 4, wherein at the stage wherein at stage f), using a given key, blocks of DCT coefficients and positions of DCT coefficients within the blocks are determined, including AC coefficients and DC coefficients of the DCT of at least one of the Y-, Cb- and Cr-components of the image.

6. The method according to claim 1, wherein, at step c), a compressed image is additionally formed based on the generated image.

7. The method according to claim 6, wherein a sequence of bytes is formed based on the compressed image, which is added to the data in step g) when forming the attachment.

8. A system for protecting the authenticity of images generated based on a text query by a machine learning model, comprising at least one processor and at least one memory associated with the processor and containing machine-readable instructions that, when executed by the processor, allow it to: receive user input data for generating an image; generate an image in JPG format using a machine learning model; record user input data containing: the input time, the user ID, and the text query; extract from the file data of the generated image in JPG format blocks of values ​​of the discrete cosine transform (DCT) coefficients for the luminance (Y) and color (CL- and Cr) components of the image;receive a sequence of low-frequency DCT coefficients (DC coefficients) and high-frequency DCT coefficients (AC coefficients) for all blocks of the luminance component, and calculate a hash function based on at least one AC coefficient and / or at least one DC coefficient; based on a given key, determine blocks of DCT coefficients and positions of DCT coefficients within the blocks, excluding DC DCT coefficients in the blocks, to calculate the hash function; form an embedding for protecting the generated image, consisting of a sequence including: input time, user ID, text query, value of the calculated hash function and additional text information; generate an encrypted sequence by encrypting the embedded data with a private key; embed the obtained hash value and encrypted sequence into the selected DCT coefficients of the generated image; and provide the secure image to the user.

Images