Verification of image processing device configuration

Abstract

The imaging system provider 110 provides updates to the imaging facility 120. These updates are called configurations, and each configuration has an associated date and time. The provider stores each configuration and its date and time in the blockchain 130. When the imaging facility acquires an image of a patient, the image is watermarked 125 with the identity of the imaging system configuration at the time the image was acquired. When a patient 150 wants to verify that an image was taken using the most recent configuration, the patient sends the image's identity to the verification system 140. The verification unit sends a request for attestation from the imaging facility. The imaging facility compares the watermarked information with information in the blockchain and provides the attestation to the verification system, which verifies the attestation. To ensure privacy and security, zk-SNARKs are used in the attestation and verification process.

Description

[Technical Field]

[0001] The present invention relates to the field of medical imaging technology, and more particularly to an automated system for verifying that imaging equipment in a medical facility is operated using the most current available security configurations. [Background technology]

[0002] In 2018, clinics and hospitals suffered numerous attacks, resulting in significant data breaches and disruptions to medical services. Attackers with access to medical records can do more than hold the data for ransom or sell it on the black market. Attackers could use these actions to thwart political candidates, disrupt research, commit insurance fraud, commit acts of terrorism, or even commit murder (CT-GAN: Malicious Tampering of 3D Medical Imagery using Deep Learning, Mirsky et al., 28th USENIX Security Symposium, 2019).

[0003] To combat these malicious attacks, improvements to security protocols are continually being made. Most notably, new releases of imaging software and related components are periodically released as new security threats are identified. However, protection against these new threats can only be achieved if clinics or hospitals continually update their imaging systems with these new security releases.

[0004] In 2016, Stites and Pianykh conducted a survey of networked computers and devices across the World Wide Web and found that there were 2,774 unsecured radiology or DICOM servers worldwide, most of which were located in the United States. (The Potential Dangers of Artificial Intelligence for Radiology and Radiologists, Chu et al., Journal of the American College of Radiology: JACR vol. 17, 10 (2020): 1309-1311) Summary of the Invention [Problem to be solved by the invention]

[0005] It would be beneficial to provide a system and method that allows for efficient and effective verification that an image processing device had the most current security configuration installed when a particular image or group of images was generated. As used herein, "security configuration" includes identification of the version of image processing software and the configuration of components associated with the image processing system that are provided by the software provider for security improvements. [Means for solving the problem]

[0006] In an embodiment of the present invention, when a software provider releases a new security configuration for an image processing system, a timestamp of the configuration release is stored on the blockchain. At the image processing facility, each time an image is generated, the image is watermarked with a watermark that includes the image timestamp and the security configuration of the imaging device at the time the image was generated.

[0007] The verification system receives verification requests from users requesting verification that an image processing system was operating with the latest security configuration at the time a particular image was generated by the image processing system. The user can submit a hash of the user's image to the verification system to identify the image of interest. The verification system then transmits the verification request to the image processing facility, which provides "proof" that the image processing system was properly configured by comparing the image's timestamp with a configuration release record recorded on the blockchain. Upon receipt, the verification system evaluates the proof in light of the record in the blockchain and provides proof to the user that the image processing system was operating with the latest security configuration.

[0008] In a preferred embodiment, a zero-knowledge succinct non-interactive proof-of-knowledge (zk-SNARK) system is used to provide proofs by the image processing facility and to verify the proofs by the verification system. A third party, typically the image processing system provider, generates the prover keys used by the prover and image processing facility, and the verifier keys used by the verifier and verification system.

[0009] Use of the present invention will improve the security of medical imaging technology by enabling rapid assessment of image processing facility security measures to keep image processing system security configurations up to date. In addition to verifying image security configuration requests from individual users, the image security verification system of the present invention can also be used by government and insurance agencies, for example, by using random images over time to assess an image processing facility's compliance with security regulations.

[0010] As previously mentioned, use of the present invention may also improve the security of individual images by notifying patients that a particular image may have been compromised due to a lack of sufficient security configuration updates at the medical facility. Upon receiving such notification, the patient may choose to have a new image taken using a more secure configuration of the imaging system.

[0011] Similarly, in embodiments using zk-SNARK provers and verifiers, the security of an image processing facility is enhanced by eliminating disclosure of the specific security configuration in place at any given time. This can be very important in "sensitive" facilities such as military field hospitals, as knowledge of the facility's security configuration can facilitate the development and / or deployment of attacks targeting such security configuration.

[0012] These and other advantages can be achieved with minimal operational overhead by implementing the verification system as a "smart contract" that automates the entire image security configuration verification process in response to a verification request from a user or authorized agent. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 illustrates an exemplary security feature image verification system. [Figure 2] FIG. 2 shows an exemplary flow chart for verifying the security configuration of an image. [Figure 3] FIG. 3 shows an exemplary flow chart for determining whether the security configuration of an image processing system was up to date when an image was captured. [Figure 4A] FIG. 4A illustrates an exemplary zk-SNARK system. [Figure 4B] FIG. 4B illustrates an exemplary zk-SNARK system. [Figure 5A] FIG. 5A shows an example flowchart of a security configuration image verification system using a zk-SNARK system. [Figure 5B] FIG. 5B shows an exemplary flowchart of a security configuration image verification system using a zk-SNARK system. [Figure 6] FIG. 6 shows a flowchart of a smart contract embodiment of a security configuration image verification system using a zk-SNARK system. DETAILED DESCRIPTION OF THE INVENTION

[0014] The invention will now be described in more detail, by way of example, with reference to the accompanying drawings, in which:

[0015] Throughout the drawings, the same reference numbers indicate similar or corresponding features or functions. The drawings are included for illustrative purposes and are not intended to limit the scope of the invention.

[0016] In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular architectures, interfaces, techniques, etc., to provide a thorough understanding of the concepts of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. Likewise, the text of this description is directed to the exemplary embodiments set forth in the figures and is not intended to limit the claimed invention beyond the limitations expressly contained in the claims. For purposes of brevity and clarity, detailed descriptions of well-known devices, circuits, and methods have been omitted so as not to obscure the description of the present invention with unnecessary detail.

[0017] FIG. 1 illustrates an exemplary security component image verification system 100 including an image processing system provider 110 , an image processing facility 120 , and a verification system 140 .

[0018] Image processing system provider 110 provides updates related to the image processing system to various image processing facilities that use the provider's image processing system. While one such image processing facility 120 is shown in Figure 1, there may be hundreds or thousands of such image processing facilities. These updates include, for example, software updates to be applied to image processing devices 122 at facility 120, as well as configuration updates for image processing devices 122 and other elements (not shown) at the facility to facilitate effective, efficient, and safe deployment of the provided image processing devices.

[0019] As previously mentioned, medical imaging facilities have been targets of malicious attacks, with attackers gaining unauthorized access to the imaging equipment itself or the images generated by the equipment. Such unauthorized access can lead to harm to patients whose images are accessed, including, for example, altering the images to add lesions that do not actually exist, delete actual lesions from the images, or both. These alterations can mislead medical professionals treating the patients, potentially harming or killing the patients if steps are taken to treat added lesions that do not exist or to ignore treatment for deleted lesions. Other consequences of unauthorized access to medical images are also possible.

[0020] Similarly, the operation of medical imaging equipment in an imaging facility can be tampered with, again through the possibility of spurious additions and deletions to images as they are being created.

[0021] The updates provided by the image processing system provider in response to threats of unauthorized access to either the image processing device or the stored images may include updates in response to known or suspected threats to the security of the image processing system. Vulnerabilities to software attacks may be addressed by providing updated software that provides increased protection from such vulnerabilities. Vulnerabilities to other attacks may be addressed by modifying components that interact with the image processing system, such as the operating system and / or network system on which the image processing system operates.

[0022] For ease of reference, the term "security configuration" is used herein to identify any and all revisions to the image processing system and components that interact with the image processing system that the image processing system provider 110 provides to the image processing facility 120.

[0023] According to aspects of the present invention, each time image processing system provider 110 creates and releases a new security configuration, the image processing system provider 110 enters the new security configuration and the release time into blockchain 130. The stored security configuration 130 may, for example, identify a series of "version numbers" associated with the hardware and / or software that represent the most recent configuration identified by the image processing system provider at the time of release of a particular security configuration. Storing these configuration settings and the time of each release in the blockchain ensures a secure record, as any attempts to change the stored information are immediately recognizable.

[0024] Correspondingly, each time the imaging facility 120 creates an image of a patient, the image 125 is "watermarked" with an identification of the date and time the image was taken and an identification of the security configuration of the imaging system at that time. The watermark may also include other identifying information, including, for example, a patient identifier, an imaging facility identifier, etc. The watermarking process is typically provided by the imaging system provider 110 and may be integrated into the imaging device 122. The imaging facility 120 may provide the patient with a copy of the watermarked image at the time the image is taken or at a later time upon request.

[0025] Some time after an image was taken, a patient and / or other authorized representative may have reason to question whether the imaging facility was operating with the most current security configuration at the time the image was created. If the patient provides the image to a medical professional at another facility, the medical professional may seek assurance that the particular medical image is trustworthy, where trust is based on whether the particular imaging system was operating with the proper (i.e., most current) security configuration.

[0026] Similarly, if the use of a particular image could result in malicious acts harming a patient, an imaging facility would want to prove that it was operating its imaging system in the latest security configuration to avoid liability.

[0027] Of particular note, the ability to easily and / or automatically determine whether an image processing facility was operating with the most current security configuration when each image was captured would provide an operator of the image processing facility with a (self-interested) incentive to ensure that new security configurations are promptly applied to the image processing system whenever they are provided by the image processing system provider. Also, the ability to easily and / or automatically determine whether an image processing facility was operating with the most current security configuration when each image was captured may facilitate determining an image processing facility's consistent compliance with security regulations or standards by requiring verification of the security configuration of random images over time.

[0028] As previously mentioned, system 100 includes verification system 140. Verification system 140 receives requests from user systems 150 to verify watermarked images 155. Verification system 140 can be located at image processing facility 120, although an independent verification system 140 can also perform image security verification on images from multiple image processing facilities. A verification system 140 that is independent from image processing facility 120 can also provide users with confidence that the resulting verification is trustworthy.

[0029] 2 shows an exemplary flowchart of an image security verification process in an embodiment of the present invention. Each column represents an action by a user, a verification system, an image processing facility, and a blockchain. Time is represented by the occurrence of each action in the vertical direction.

[0030] At 210, the user communicates a request 210 to the verification system, the request including the identity of the image for which security verification is requested.

[0031] At 220, the verification system requests "proof" from the imaging facility that its imaging system was using the most current security configuration when the identified image was captured.

[0032] The image processing facility's attestation unit 124 accesses the blockchain to access the provider's records of the date and time of each release of updated security configuration 230 and decodes the watermark of the identified image 125 to determine the date and time of the image and the security configuration that was present in the image processing system when the image 125 was acquired. The attestation unit compares the image security configuration at the image date and time with the provider's record of security configurations to determine whether the image security configuration at the image date and time was the most recent provider security configuration.

[0033] The proving unit 124 provides this proof 240 to the verifying unit 144. Depending on the nature of this proof 240, the verifying unit 144 may also have access to the provider's security configuration record in the blockchain, as described in more detail below.

[0034] Based on the verification of the certificate from the image processing facility, the verification system notifies the user of the result of the image security verification 250 .

[0035] Returning to the exemplary embodiment of FIG. 1 , in embodiments of the present invention, a user (patient and / or authorized representative) 150 identifies a particular image 155 of interest to the verification system. This identification can take a variety of forms, depending on tradeoffs regarding ease of use, authentication, clarity, communication resources, etc. In some implementations, for example, the user need only provide the identification of the imaging facility, the date of image capture, the patient's name, etc., and the verification facility (verification system) 140 forwards this information to the particular imaging facility 120. In other embodiments, the user may be required to provide a copy of the watermarked image 155 to the verification system 140 for forwarding to the medical facility.

[0036] In a preferred embodiment, user 150 can provide a hash of the watermarked image 155 to verification system 140 for transmission to image processing facility 120. Providing a hash of the image 155 has several advantages. Typically, the hash of an image is significantly smaller than the image itself, reducing communication resource requirements. Also, medical imaging facilities often use the hash of each image to index each image in their storage, and providing the hash of the user's image 155 facilitates retrieval of the image at the imaging facility. A matching hash also ensures that the user's image 155 has not been altered and is therefore identical to the image 125 at the imaging facility 120.

[0037] Upon receiving an image security verification request from verification system 140, image processing facility certification unit 124 provides "certification" to verification system 140 that the image processing system was operating with the most current security configuration.

[0038] Flowchart 300 of FIG. 3 illustrates one example of how a verification unit can determine whether an image processing system was using the most current security configuration at the time a particular image was captured.

[0039] At 310, the verifier decodes the watermark information in the image to extract the date and time the image was taken and the security configuration in place when the image was taken.

[0040] At 320, the attesting unit accesses the blockchain. At 330, the attesting unit determines the most recent security configuration released to the imaging facility prior to the date and time of the image, as recorded by the imaging system provider on the blockchain.

[0041] There may be multiple latest configurations associated with the date and time of the image because, for example, it is likely that an image processing system will not be able to incorporate the latest release of a security configuration immediately upon release from a provider. That is, each release will have a period during which it is considered "latest," and that period may overlap with at least a portion of the date and time of a subsequent release. For ease of reference, the term "valid" security configuration is used herein to define a security configuration that is considered latest at a given date and time.

[0042] The end time of the "validity period" of each security configuration can be included in the blockchain information of the subsequent release (e.g., "The validity of the previous security configuration ends on date and time xxx"), or it can be a predetermined relative end time (e.g., "Each security configuration is valid from the release date and time until n days after the release of the next security configuration"). Other methods of defining the validity period of each security configuration can also be used.

[0043] At 340, the verifier compares the image security configuration from the watermark information with the valid provider security configuration from the blockchain. If the image security configuration matches the valid provider security configuration for the date and time of the image, the verifier determines that the image processing system was operating with the latest security configuration (360, true); otherwise, the verifier determines that the image processing system was not operating with the latest security configuration (350, false).

[0044] Returning to FIG. 1 , image processing facility 120 provides this determination to verification system 140, which notifies user 150 of the determination. Verification system 140 preferably includes a verifier 144 that functions to assure user 150 that the determination is valid. This verification can take a variety of forms, depending, for example, on the level of trust between verification system 140 and image processing facility 120. In some embodiments, for example, image processing facility 120 may be part of a "trusted network" of image processing facilities, where each image processing facility operates in accordance with a set of standards and operating conditions, including, for example, conducting regular inspections and monitoring. In such cases, verifier 144 need only verify that the image processing facility's credentials in the trusted network are valid.

[0045] In other embodiments, the certifying unit 124 may be required to disclose the date, time, and security configuration of the image to the verifying unit 144, while the verifying unit 144 verifies that the security configuration of the image matches the provider security configuration in effect at the date and time of the image. In some embodiments, the certifying unit 124 may be required to certify to the verifying unit 144 that the date, time, and security configuration of an identified image accurately reflects the watermark information in the image.

[0046] Exemplary embodiments that address these potential trust issues between the verification system 140 and the image processing system 120 are presented below based on a zk-SNARK prover and verifier.

[0047] The acronym zk-SNARK stands for Zero-Knowledge Succinct Non-Interactive Theory of Knowledge. In a zk-SNARK protocol, a prover determines whether a statement is true or false, and a verifier verifies that the prover has presented sufficient proof of that determination. The zero-knowledge aspect of the zk-SNARK process means that the proof does not provide information about the basis for the determination.

[0048] In the context of the present invention, the statement to be proven might be, "The image processing system was operating with its most recent security configuration at the time the image of interest was taken." If the proving unit provides "proof" that the statement is true, this proof will not reveal anything about the particular security configuration that existed at the time the image was taken. However, the "proof" will be sufficiently secure that the verifying unit can verify that the proving unit performed the appropriate processes to make this determination, as described in more detail below.

[0049] A zk-SNARK system includes three components, namely, a generator, a prover, and a verifier, as shown in Figures 4A-4B. These components are typically provided by a trusted third party. In the context of the present invention, these components are provided by an image processing system provider.

[0050] Generator 420 receives secret parameters (SNARK key 415) and program 410 (such as program 300 in FIG. 3 ) and generates prover 430 and verifier 440. Prover 430 corresponds to securely encoding a given program 410 in a manner that provides verifier 440 with proof that the program was properly executed. Generator 420 also creates a corresponding prover key 435 and a corresponding verifier key 445 for use by the prover and verifier, respectively. SNARK key 415 ensures that the generated programs 430, 440 and keys 435, 445 are unique to program 410; therefore, proofs based on other programs (e.g., modifications of program 410) will not be verified by verifier 440. In most cases, a trusted third party will revoke key 415 immediately after generator 420 executes.

[0051] Any of a number of commercially available zk-SNARK generation systems (compilers) can be used as generator 420, such as Groth16, Circom, VOProof, Fractal, Halo, SuperSonic, Marlin, and ZoKrates.

[0052] 4B, when a request for proof is subsequently presented, the prover 430 receives as input a prover key 435, some private data 450, and some public data 460. The private information is commonly referred to as information from a "witness." The private data 450 and public data 460 are the information required by the encoding process of the statement proof program 410 to prove or disprove the validity of the subject statement.

[0053] Prover 430 executes a process corresponding to encoded program 410 using prover key 435 and specific parameters provided in secret data 450 and public data 460 to generate proof 470. As previously described, proof 470 is generated so that verifier 440 can verify that prover 430 properly executed the encoded version of statement proof program 410, returning a result of "TRUE" if the statement was proven to be true, or a result of "FALSE" if the statement was not proven to be true. However, proof 470 does not reveal any of secret data 450 used in this TRUE / FALSE determination.

[0054] Verifier 440 performs its process using verifier key 445, proof 470, and public data 460. Proof 470 does not reveal any information about secret data 450, but proves to verifier 440 that prover 430 possessed the particular secret data 450 that, when run through the encoding of statement proving program 410, caused the true / false decision to be returned.

[0055] 5A-5B illustrate an exemplary zk-SNARK embodiment of an image security configuration verification system according to aspects of the present invention, using the exemplary components of FIG. 1 and the exemplary statement proving program 300 of FIG. 3.

[0056] 5A, zk-SNARK generator 420, described in detail above, receives as input statement proof program 300 and SNARK key 515, and generates prover 124 and verifier 144, and prover key 535 and verifier key 545. The operations of generator 420 using SNARK key 515 are typically performed by image processing system provider 110.

[0057] As detailed above, SNARK key 515 ensures that prover 124, verifier 144, prover key 535, and verifier key 545 are unique to the particular encoding of statement proof program 300 in prover 124 and corresponding verifier 144. This key 515 is preferably discarded after generator 420 has been executed.

[0058] The provider 110 provides each image processing facility 120 with a certifier 124 and a certifier key 535 , and provides the verification system 140 with a verifier 144 and a verifier key 545 .

[0059] 1-2, a user (e.g., a patient or representative) 150 transmits a request for verification of an image security configuration to the verification system 140. In this case, the request identifies images of interest at a particular image processing facility 120. The verification system 140 transmits the request to the image processing facility 120.

[0060] Image processing facility 120 retrieves a watermarked image 125 of the subject from its image database and provides the watermarked image to verification unit 124 .

[0061] 5B, the verifier 124 receives the watermarked image 125 (private data) and the verifier key 535 and accesses the blockchain data 130 (public data) to obtain the record of the release of the security configuration from the image processing system provider 110. The verifier 124 uses this received data to perform its processes and provides proof 570 that the security configuration of the image processing system at the date and time of the image (obtained from the watermark on the image) matches (or does not match) the valid (i.e., most recent) security configuration released by the image processing system provider 110 as recorded on the blockchain 130.

[0062] The verifier 144 receives this proof 570 and its verifier key 545 and accesses the blockchain (public data) 130 to obtain the record of the release of the security configuration from the image processing system provider 110. As previously described, the generator 420 generates the proof 124, verifier 144, proof key 535 and verifier key 545 in such a way that it is effectively impossible for the image processing facility 120 to generate a positive proof 570 unless the security configuration of the image processing system at the time of capture of the watermarked image, as recorded in the blockchain 130 by the image processing system provider 110, actually corresponds to the security configuration in effect at that time.

[0063] In a preferred embodiment, the verification system 140 can be embodied as a "smart contract." As defined by IBM, "A smart contract is simply a program stored on the blockchain that runs when predetermined conditions are met. These smart contracts are typically used to automate the execution of an agreement so that all participants can see the results immediately, without any intermediary involvement or time loss. These smart contracts can also automate workflows and trigger subsequent actions when conditions are met." (What are smart contracts, www.ibm.com / topics / smart-contracts.)

[0064] 1, 5B, and 6, the smart contract is configured to receive (610) an identification of a user of a watermarked image 125 at an image processing facility 120 and automatically generate (620) a request for image security configuration verification to the image processing facility 120 using the identification of the watermarked image 125. In response, the image processing facility 120 executes the certifier 124 using the certifier key 535, the watermarked image 125, and the record of the released security configuration on the blockchain 130 to generate a proof 570. The smart contract receives (630) the proof 570 and executes (640) the verifier 144 using the verifier key 545, the proof 570, and the record of the released security configuration on the blockchain 130. The smart contract returns (650) a resulting image security verification, such as, "The identified image was acquired using the 'latest' (or 'old') security configuration of the image processing system."

[0065] Of particular note is that the use of zk-SNARK embodiments coupled with smart contracts eliminates most, if not all, of the human intervention (and associated costs) involved in operating the image security configuration verification process of the present invention.

[0066] While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive, i.e., the invention is not limited to the disclosed embodiments.

[0067] Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, by studying the drawings, the disclosure, and the appended claims. In the claims, the word "comprises" does not exclude other elements or steps, and the singular does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage. A computer program can be stored / distributed on a suitable medium, such as an optical storage medium or a solid-state medium, provided together with or as part of other hardware, as well as in other forms of distribution, such as via the Internet or other wired or wireless communication systems. Reference signs in the claims should not be construed as limiting the scope.

Claims

1. A verification system having a user interface for receiving a verification request from a user and a verification processor, the verification request includes an image and an identification of an image processing facility; the verification request includes a user request to verify that the image processing facility was using image processing software with a current security configuration when the image was generated; the provider of the image processing software providing a record of a timestamp of the release of each of a plurality of security configurations of the image processing software to the blockchain; The verification processor: requiring the image processing facility to attest that the security configuration of the image processing software was up to date when the image was generated; verifying, based on the attestation, whether the security configuration of the image processing software at the image processing facility was up to date when the image was generated; and notifying the user of the verification; Verification system.

2. the verification processor has a zk-SNARK verifier and an associated verifier key provided by the provider system; the attestation from the image processing facility is a zk-SNARK attestation; The verification system of claim 1 .

3. The verification system of claim 1 , wherein the identification information of the image comprises a hash of the image.

4. 10. The verification system of claim 1, wherein the verification processor executes a smart contract to request and verify the proof.

5. An image processing system at an image processing facility and a system having the processing system at the image processing facility, the image processing facility receiving from a provider system a plurality of security configurations of image processing software for use in the image processing system; each security configuration having a timestamp associated with the release of the security configuration from the provider system; the provider system communicating a timestamp of each security configuration to a storage system; The storage system stores a timestamp for each security configuration in a blockchain; the image processing system adding a watermark to an image of a patient as the image is acquired to generate a watermarked image; the watermark includes an image timestamp and a security configuration of the image processing software used to acquire the image; the processing system receives a certification request from a verification system; the verification request includes an identification of the particular image; the certification request is a request for certification from the image processing facility that the most recent security configuration of the image processing software was used when the particular image was generated; the processing system comprising: Decoding the watermark to determine the image timestamp and the security configuration used to generate the particular image; comparing the image timestamp and security configuration to multiple security configuration timestamps in the blockchain to determine if the security configuration of the image processing software was up to date when the particular image was generated; and providing the verification system with proof that the security configuration of the image processing software was up to date when the particular image was generated; system.

6. 6. The system of claim 5, wherein the processing system provides the proof to the verification system using a zk-SNARK prover and associated prover key provided by the provider system.

7. The system of claim 5 , wherein the identification information of the particular image comprises a hash of the particular image.

8. a compilation system that generates image processing software for multiple security configurations over time; a distribution system that provides each security configuration of the image processing software to at least one image processing facility; and a storage system for storing, on a blockchain, a security configuration timestamp corresponding to a release of each security configuration of the image processing software to the image processing facility; A system having:

9. the system includes a zk-SNARK setup system that processes a security configuration verification algorithm and that generates a zk-SNARK prover, a zk-SNARK prover key, a zk-SNARK verifier, and a zk-SNARK verifier key; the zk-SNARK attestor and the zk-SNARK attestor key are provided to the image processing facility to provide proof that the security configuration of the image processing software was up to date when the particular image was generated; the zk-SNARK verifier and the zk-SNARK verifier key are provided to a verification system that verifies the certificate provided by the image processing facility; The system of claim 8.

10. 10. The system of claim 9, wherein the system provides a smart contract to the verification system to facilitate verification that the security configuration of the image processing software at the image processing facility was up to date when the particular image was generated.

Images