WO2025094184A1 - Method for long-term media sealing - Google Patents

Abstract

There is provided a computer-implemented method of signing a digital media asset for verification of originally, comprising: accessing a digital media asset, in at least two iterations, for a current iteration: computing a current digital signature of the digital media asset, verifying that a current date of creation of the current digital signature is prior to an expiration date of a preceding digital signature, in response to the verifying, creating a current metadata including the current digital signature, the current date of creation of the current digital signature, and an expiration date of the current digital signature, and embedding the current metadata within the digital media asset, wherein the current metadata is embedded in addition to preceding metadata generated in at least one preceding iteration.

Description

METHOD FOR LONG-TERM MEDIA SEALING

RELATED APPLICATION

This application claims the benefit of priority of U.S. Provisional Patent Application No. 63/596,274 filed on November 5, 2023, the contents of which are incorporated herein by reference in their entirety.

BACKGROUND

The present invention, in some embodiments thereof, relates to security of digital media assets and, more specifically, but not exclusively, to a verification of authenticity of digital media assets.

Digital media assets, such as videos, images, audio files, and documents, are prone to manipulation, for example, by deepfake technologies and/or by other approaches. A certain digital media asset may be the original version, or it may have been manipulated.

SUMMARY

According to a first aspect, a computer-implemented method of signing a digital media asset for verification of originally, comprises: accessing a digital media asset, in at least two iterations, for a current iteration: computing a current digital signature of the digital media asset, verifying that a current date of creation of the current digital signature is prior to an expiration date of a preceding digital signature, in response to the verifying, creating a current metadata including the current digital signature, the current date of creation of the current digital signature, and an expiration date of the current digital signature, and embedding the current metadata within the digital media asset, wherein the current metadata is embedded in addition to preceding metadata generated in at least one preceding iteration.

In a further implementation form of the first aspect, the current iteration is automatically triggered prior to the expiration date of a preceding digital signature.

In a further implementation form of the first aspect, the expiration date is automatically selected to be earlier than a date predicted by a prediction model indicating likelihood of breaking a cryptographic process used for computing the current digital signature.

In a further implementation form of the first aspect, the expiration date of the current digital signature precedes the expiration date of the preceding digital signature.

In a further implementation form of the first aspect, the current iteration is automatically triggered in response to a prediction that at least one preceding cryptographic process used for computing the at least one preceding digital signature of at least preceding metadata generated in at least one preceding iteration, wherein a current cryptographic process for computing the current digital signature for the current iteration is stronger than the at least one preceding cryptographic process.

In a further implementation form of the first aspect, further comprising: accessing a dataset of cryptographic processes used for computing digital signatures known to have been broken, and strength of the process and/or strength of a key, and selecting a combination of a cryptographic process and/or a key strength for computing the current digital signature that does not appear in the dataset.

In a further implementation form of the first aspect, further comprising monitoring a plurality of data sources for an indication of a certain combination of a certain cryptographic process and/or a certain key strength that has been broken, and automatically updating the dataset for indicating the combination of the cryptographic process and/or the key strength that has been broken.

In a further implementation form of the first aspect, the metadata further including parameters indicating strength of a combination of a cryptographic process and/or a key strength used to compute the current digital signature.

In a further implementation form of the first aspect, the current metadata further includes a unique identifier of a current entity performing the signing, wherein the current entity is verifiable using the unique identifier.

In a further implementation form of the first aspect, the unique identifier includes a private or public key that enables authenticating the entity that performed the signing.

In a further implementation form of the first aspect, the unique identifier is used for searching for the current entity in a central dataset hosting identifiers of verified entities.

In a further implementation form of the first aspect, the digital media asset selected from: video, frame, image, audio file, and document.

In a further implementation form of the first aspect, the digital media asset is automatically created by a generative model.

In a further implementation form of the first aspect, the generative model is implemented as part of a digital human.

In a further implementation form of the first aspect, a process for signing each current digital signature is based on quantum-safe cryptography.

In a further implementation form of the first aspect, the current metadata includes at least one of: the preceding digital signature of the preceding metadata, the preceding metadata, a sequence of the preceding digital signatures of a plurality of preceding metadata, and a sequence of the preceding metadata.

According to a second aspect, a computer-implemented method of verifying originally of a digital media asset, comprises: extracting a plurality of metadata instances from a digital media asset, each metadata instance including a digital signature of a plurality of digital signatures of the plurality of metadata instances, a date of creation of the digital signature, and an expiration date of the digital signature, for each respective metadata instance, verifying that the date of creation of the respective digital signature is prior to the expiration date of the corresponding preceding digital signature, and in response to verifying dates of creation, verifying originality of the digital media asset.

In a further implementation form of the second aspect, further comprising: wherein each of the plurality of metadata instances includes a temporal identifier within a temporal sequence indicating date of creation relative to other metadata instances, for each respective metadata instance, verifying that the date of creation of the respective metadata instance is after a preceding metadata instance and prior to a subsequent metadata instance according to the temporal sequence.

In a further implementation form of the second aspect, further comprising: for each respective metadata instance: obtaining an indication of a process used for generating the signature of the respective metadata instance, accessing a dataset storing a plurality of records, wherein a record is for a process used for computing digital signatures, indicating a date when the process was broken, and verifying that the process used for generating the signature is not in the dataset or the date when the process was broken is after creation of a subsequent signature of a subsequent metadata instance using a stronger process.

In a further implementation form of the second aspect, each respective metadata instance includes a unique identifier of an entity that sealed the respective metadata instance, and further comprising verifying integrity of each entity that sealed each respective metadata instance.

In a further implementation form of the second aspect, further comprising: for each respective metadata instance: obtaining a respective public key, and verifying each digital signature of the respective metadata instance using the respective public key.

In a further implementation form of the second aspect, further comprising: for each respective metadata instance: extracting a respective unique identity of an entity that generated the signature, and validating the entity using the respective unique identity.

In a further implementation form of the second aspect, further comprising validating that the date of creation of the respective signature falls within a date interval during which the entity was determined to be valid. Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

In the drawings:

FIG. 1 is a block diagram of components of a system for sealing a digital media asset and/or verifying the originally of the digital media asset, in accordance with some embodiments of the present invention;

FIG. 2 is a flowchart of a method of signing a digital media asset using a sequence of metadata instances that follow a set of rules, in accordance with some embodiments of the present invention; and

FIG. 3 is a flowchart of a method of verification of originally of a digital media asset using a sequence of metadata instances that follow a set of rules, in accordance with some embodiments of the present invention.

DETAILED DESCRIPTION

The present invention, in some embodiments thereof, relates to security of digital media assets and, more specifically, but not exclusively, to a verification of authenticity of digital media assets.

As used herein, the term “seal” refers to the process of generating and embedding metadata for verification of originally of a digital media asset. The metadata includes a digital signature and other data as described herein. As used herein, the term “verification” refer to the process of extracting embedded metadata from the digital media asset, and analyzing the metadata (e.g., using a set of verification rules) to verify originally of the digital media asset.

As used herein, the term original with reference to the digital media asset refers to a version of the digital media asset which is desired to be preserved, by sealing it and making it immutable. The term original is not meant to be restricted to the very first version of the digital media asset, but rather to the version which is to be preserved.

An aspect of some embodiments of the present invention relates to systems, methods, computing devices and/or code instructions (stored on a data storage device and executable by one or more processors) for sealing a digital media asset for enabling verification of originally, based on a sequence of signatures and/or other data included in metadata which may be embedded in the digital media asset. A digital media asset for sealing is accessed, for example, a video, an image, an audio file, a document, and the like. Two or more iterations are performed, for creating the sequent of signatures and/or other data included in the metadata. Each iteration is performed at a different date, optionally different years. For each iterations currently being performed, a current digital signature of the digital media asset is computed. The current digital signature is computed using a certain cryptographic process and/or certain key strength. A verification may be performed that a current date of creation of the current digital signature is prior to an expiration date of a preceding digital signature (computed in a prior iteration). In response to the verification, a current metadata is created, i.e., a new instance of the metadata. The metadata includes the current digital signature, the current date of creation of the current digital signature, and an expiration date of the current digital signature. The expiration date represents the date of expiration of the current digital signature, i.e., after the expiration date the digital media asset cannot be considered secure from having been manipulated. The current metadata may be embedded within the digital media asset, and/or stored on an external storage such as within a central database. Each current instance of the metadata is embedded in addition to preceding instances of the metadata generated in at least one preceding iteration. A sequence of instances of the metadata is created in the multiple iterations.

An aspect of some embodiments of the present invention relates to systems, methods, computing devices and/or code instructions (stored on a data storage device and executable by one or more processors) for verifying originally of a digital media asset, by analyzing a sequence of instances of metadata associated with the digital media asset. Each metadata instance includes a digital signature, a date of creation of the digital signature, and an expiration date of the digital signature. Verification is performed for each metadata instance, that the date of creation of the respective digital signature of the respective metadata instance is prior to the expiration date of the corresponding preceding digital signature of the sequence of instances of metadata. Originality of the digital media asset is verified in response to verifying dates of creation. Alternatively or additionally, the metadata includes one or more parameters of the process (e.g., cryptographic process) used to create the digital signature, for example, the type of process and/or length of key. The digital media asset may be further verified in response to verifying that the process (e.g., cryptographic process) and optionally the key length used to create the digital signature has not been broken. A dataset, such as a database, hosting indications of processes and optionally key lengths that have been broken, may be accessed to determine whether the current process and optionally the key length has been broken.

At least one embodiment addresses the technical problem of sealing digital media assets, to enable verification of originally of the digital media asset. At least one embodiment improves the technology of sealing digital media assets. At least one embodiments improves upon prior approaches of sealing digital media assets. At least one embodiment provides a practical application of sealing digital media assets with the goal of making them immutable, and/or of verifying that the sealed digital media asset has not been manipulated.

With the progress made in video digital manipulation techniques, especially using deepfake technologies, there is a need to be able to “seal” digital media assets. For example, to “stamp” the digital media assets using cryptography with information that can be used later to show that this is an “original” video and was not modified after the stamping. In other words, to make the digital media asset immutable.

One example of an existing approach for making a digital media asset immutable is described with reference to Nadia Kanwal, Mamoona N. Asghar, Mohammad S. Ansari, Martin Fleury, et al., "Preserving Chain-of-Evidence in Surveillance Videos for Authentication and Trust- Enabled Sharing", IEEE Access, volume 8, IEEE, USA, 2020, pp. (153413 - 153424), ISSN 2169- 3536, DOI: 10.1109/ ACCESS.2020.3016211, incorporated herein by reference in its entirety. Kanwal et al relate to how to use a combination of hashing, cryptography, and steganography to make an image immutable, or more correctly, to detect if the image was manipulated in some way. A hash of video frames is computed, and then the video is signed with cryptography. The signature is added to the video itself using video stenography. By embedding the signature in the video itself, the person who sees the video does not need to check against a central database, but can know who signed it.

Additional techniques employing blockchain can be seen in Using Blockchain for Improved Video Integrity Verification - Sarala Ghimire, Jae Young Choi, and Bumshik Lee, IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 22, NO. 1, JANUARY 2020. In another example, M. Tahir, M. N. Asghar, N. Kanwal, B. Lee and Y. Qiao, "Joint Crypto-Blockchain Scheme for Trust-Enabled CCTV Videos Sharing," 2021 IEEE International Conference on Blockchain (Blockchain), Melbourne, Australia, 2021, pp. 1-6, doi: 10.1109/Blockchain53845.2021.00054, relates to “joint encryption and blockchain-based solutions for immutable decentralized evidence management for CCTV footage.”

When it is desired to preserve trust for a long time, for example, tens of years, existing approaches such as the aforementioned approaches may break. The weak point may be encryption. With the advent of computers, algorithms, and quantum computers, code-breaking of the encryption is possible. Breaking the encryption would make modifying the videos or creating fake videos and signing them, as if they were created many years before, possible. This will lead to a problem of trust if an entity is unable to determine whether a video is indeed original or has been manipulated.

At least one embodiment described herein improves upon prior approaches such as the aforementioned approaches, by providing an approach that ensures immutability of the digital media asset in view of increasing computational abilities that enable cracking previously used cryptography processes.

At least one embodiment described herein is designed to protect against attacks which are based on the following process:

* Identify an authentication code that is breakable using existing computational hardware and/or existing approaches for cracking codes.

* Create a modified video.

* Sign the modified video with the authentication code using the original signing protocol. The reason the modified video can be signed using the same signature as the original video, is that the authentication was broken. The modified video now appears to be a secure original video, when in fact, the original video has been modified. There is no way for an entity to identify using the signature/authorization, that the original video has been modified.

An example scenario: A video is signed in 2023. The signature designates the cryptography process that was used, the strength of the key, and in addition the year 2060 as the year of expiration of the signature. The cryptography process that was used with the same size key to generate the signature for the video in 2023, is broken by a quantum computer in 2035. Now, in 2040 a signed video is shown, with the signature authenticating it as a 2023 video. Since the cryptography process used to generate the original signature in 2023 is broken by the year 2040, the current signature cannot be used reliable for authentication of the video as being original and non-manipulated. At least one embodiment described herein enables authenticating the video in 2040, in view of the progress in computational abilities which is increasingly able to crack cryptography processes.

At least one embodiment described herein addresses the aforementioned technical problem, and/or improves upon the aforementioned technical field, and/or improves upon the aforementioned prior approaches, and/or provides a practical application, by sealing a digital media asset using a sequences of metadata instances. Each metadata instance is created at a different time. Each metadata instance includes a digital signature computed for the metadata instance, a current date of creation of the current digital signature, and an expiration date of the current digital signature. The date of creation of a certain metadata instance is verified to be prior to the expiration date of a preceding digital signature of a preceding metadata instance in the sequence. The originality of the digital media asset is verified by confirming that the data of creation of each respective digital signature of each respective metadata instance of the sequence of metadata instances is prior to the expiration date of the digital signature in another metadata instance that precedes the respective metadata instance.

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to FIG. 1, which is a block diagram of components of a system 100 for sealing a digital media asset and/or verifying the originally of the digital media asset, in accordance with some embodiments of the present invention. Reference is also made to FIG. 2, which is a flowchart of a method of signing a digital media asset using a sequence of metadata instances that follow a set of rules, in accordance with some embodiments of the present invention. Reference is also made to FIG. 3, which is a flowchart of a method of verification of originally of a digital media asset using a sequence of metadata instances that follow a set of rules, in accordance with some embodiments of the present invention.

System 100 may implement the acts of the method described with reference to FIGs. 2-3, by processor(s) 102 of a computing device 104 executing code instructions stored in a memory 106 (also referred to as a program store).

Computing environment 104 may be implemented as, for example one or more and/or combination of: a group of connected devices, a client terminal, a server, a virtual server, a computing cloud, a virtual machine, a desktop computer, a thin client, a network node, and/or a mobile device (e.g., a Smartphone, a Tablet computer, a laptop computer, a wearable computer, glasses computer, and a watch computer).

Computing device 104 seals one or more digital media assets 150 (e.g., videos, audio files, images, documents) and/or performs verification of originally of the sealed digital media asset(s) 150.

Multiple architectures of system 100 based on computing device 104 may be implemented. For example:

* Computing device 104 may be implemented as a standalone device (e.g., workstation, kiosk, client terminal, smartphone) that include locally stored code instructions 106A that implement one or more of the acts described with reference to FIGs. 2-3, for locally sealing a digital media asset 150 and/or locally verifying the sealed digital media asset. The locally stored code instructions 106 A may be obtained from a server, for example, by downloading the code over the network, and/or loading the code from a portable storage device. Digital media asset(s) 150 may be obtained, for example, stored by a data storage device such as by a server(s) 118, by a user manually entering a path where digital media asset(s) 150 is stored, intercepting digital media asset(s) 150 being transferred by user(s) across a network, and/or a user activating an application that automatically analyzes digital media asset(s) 150 stored on computing device 104 and/or accessed by computing device 104 (e.g., over a network 110, and/or stored on a data storage device 122). The computing device may locally seal digital media asset(s) 150 using code 106A as described herein. The sealed digital media asset(s) 150 may be provided, for example, to other devices, for storage, for hosting by a web server, and the like. Computing device 104 may locally verify originally of the sealed digital media asset(s) 150, including sealed digital media assets that were sealed by other devices, which may be obtained from an external source (e.g., external computer and/or external storage device).

* Computing device 104 executing stored code instructions 106 A, may be implemented as one or more servers (e.g., network server, web server, a computing cloud, and a virtual server) that provides centralized services (e.g., one or more of the acts described with reference to FIGs. 2-3). Services may be provided, for example, to one or more client terminals 108 over network 110, and/or to one or more server(s) 118 over network 110. Server(s) 118 may include, for example, web servers that host websites and/or social network from which digital media asset(s) 150 may be accessed, and/or data storage servers that store data including digital media asset(s) 150, which are accessed and/or downloaded by client terminals. Services may be provided to client terminals 108 and/or server(s) 118, for example, as software as a service (SaaS), a software interface (e.g., application programming interface (API), software development kit (SDK)), an application for local download to the client terminal(s) 108 and/or server(s) 118, an add-on to a web browser running on client terminal(s) 108 and/or server(s) 118, and/or providing functions using a remote access session to the client terminals 108 and/or server(s) 118, such as through a web browser executed by client terminal 108 and/or server(s) 118 accessing a web sited hosted by computing device 104. For example, digital media asset(s) 150 are provided from each respective client terminal 108 and/or server(s) 118 to computing device 104, and computing device 104 returns a sealed version of the digital media asset(s) 150. In another example, digital media asset(s) 150 are hosted by server(s) 118 for being accessed by users via client terminals 108, for example, by streaming and/or for download.

Processor(s) 102 of computing device 104 may be hardware processors, which may be implemented, for example, as a central processing unit(s) (CPU), a graphics processing unit(s) (GPU), field programmable gate array(s) (FPGA), digital signal processor(s) (DSP), and application specific integrated circuit(s) (ASIC). Processor(s) 102 may include a single processor, or multiple processors (homogenous or heterogeneous) arranged for parallel processing, as clusters and/or as one or more multi core processing devices.

Memory 106 stores code instructions executable by hardware processor(s) 102, for example, a random access memory (RAM), read-only memory (ROM), and/or a storage device, for example, non-volatile memory, magnetic media, semiconductor memory devices, hard drive, removable storage, and optical media (e.g., DVD, CD-ROM). Memory 106 stores code 106A that implements one or more features and/or acts of the method described with reference to FIGs. 2-3 when executed by hardware processor(s) 102. Computing device 104 may include a data storage device 122 for storing data, such as one or more code based processes described herein, for example, signature creator 122A which computes signatures for the digital media assets 122A, embedder 122B that embeds metadata within the digital media asset, extracted data repository 122C set for storing data extracted from metadata for verification of the media asset, and/or verification rules 122D indicating how to analyze the extracted data for verification of the digital media assets, as described herein. Data storage device 114 may be implemented as, for example, a memory, a local hard-drive, virtual storage, a removable storage unit, an optical disk, a storage device, and/or as a remote server and/or computing cloud (e.g., accessed using a network connection).

Network 110 may be implemented as, for example, the internet, a local area network, a virtual network, a wireless network, a cellular network, a local bus, a point to point link (e.g., wired), and/or combinations of the aforementioned.

Computing device 104 may include a network interface 124 for connecting to network 110, for example, one or more of, a network interface card, a wireless interface to connect to a wireless network, a physical interface for connecting to a cable for network connectivity, a virtual interface implemented in software, network communication software providing higher layers of network connectivity, and/or other implementations.

Computing device 104 and/or client terminal(s) 108 include and/or are in communication with one or more physical user interfaces 126 that include a mechanism for a user to enter data (e.g., manually designate the location of digital media asset(s) 150 for analysis) and/or view the displayed results (e.g., presentation of results of verification of a sealed digital media asset), within a GUI. Exemplary user interfaces 126 include, for example, one or more of, a touchscreen, a display, gesture activation devices, a keyboard, a mouse, and voice activated software using speakers and microphone.

Referring now back to FIG. 2, at 202, a digital media asset is accessed.

The digital media asset may be selected for being sealed against manipulation, for example, by deepfake models and/or manual manipulation, for example, adding scenes to a video which did not exist in the original video, changing the voice of a person in an audio file, changing a face of a person in a video from one person to another person, modifying text in a document, and the like. The digital media asset may be selected for being made immutable. The digital media asset may be selected for preserving its original version.

Examples of digital media asset include videos, frames of a video, images, animations, audio files, and documents. The digital media asset may be content that is automatically created by a generative model, optionally in response to an input prompt. Content automatically generated by the generative model may be sealed as described herein. The generative model may be implemented as part of a digital human, such as a video of a real person or synthetically generated person, with whom a user may interact, such as by asking questions and/or having a conversation.

At 204, a digital signature of the digital media asset is computed.

The digital signature may be computed using different approaches.

In an exemplary approach, a digital signature is computed using public-key cryptography, typically based on algorithms like RSA, DSA (Digital Signature Algorithm), or ECDSA (Elliptic Curve Digital Signature Algorithm). The digital media asset to be signed is hashed, optionally using a cryptographic hash function, for example, SHA-256, SHA-512). A hash value is generated. The hash value is encrypted using a private key of an entity performing the signing. The key may be of varying length, indicating increasing strength of encryption. The encrypted hash is used as the digital signature. The entity’s private key enables generating the digital signature. The originality of the signed digital media asset may be authenticated by anyone using the entity’s private key that corresponds to the private key used to create the digital signature. The public key is used to decrypt the digital signature to obtain the hash value, which may be computed to a newly computed hash of the digital media asset. A match in the hash values indicates that the current version of the digital media asset is the same as the original digital media asset for which the digital signature was computed. However, cracking the process and determining the private key enables malicious parties to generate the digital signature as if they were the entity, compromising on the authenticity of the digital media asset.

Optionally, the process for generating the digital signature is based on quantum-safe cryptography approaches. Quantum-safe cryptography represents a new generation of the publickey cryptographic system. These new quantum cryptographic processes are based on hard mathematical problems that based on research, that even large quantum computers cannot break. As such, the quantum-safe cryptography approaches are expected to be more difficult to break than standard cryptography approaches using for signing. It is noted that signing using quantum-safe cryptographic approaches may be done using standard computational resources. Quantum computers are not required. Approaches that are based on the hardness of finding factors are susceptible to Shor’s factoring quantum algorithm and therefore are predicted to not be sufficiently safe from attack once the quantum hardware becomes scalable.

At 206, one or more verifications associated with the current digital signature may be performed. The verifications may be based on a set of rules. Optionally, when the current digital signature is created (in the current iteration) following a previously generated digital signature (in a preceding iteration), a verification that a current date of creation of the current digital signature (in the current iteration) is prior to an expiration date of the previously generated digital signature. Generating another digital signature for the digital media asset prior to expiration of the previously generated digital signature may help ensure a continuity of security, i.e., avoiding a time interval during which the digital media asset is unsecure against attack.

A verification may be made that a combination of the cryptographic process and/or key strength used to compute the current digital signature has not been broken. The verification may be made for example, by accessing and/or searching a dataset of cryptographic processes used for computing digital signatures known to have been broken, to verify that the currently used cryptographic process is excluded from the dataset. The dataset may include an indication of the strength of the broken cryptographic process and/or strength of the key that was broken. Alternatively or additionally, a cryptographic process for computing the current digital signature that does not appear in the dataset may be selected. For cryptographic processes that have been broken, the dataset may further store an indication of the entity that broke the corresponding cryptographic process, for example, government of a certain country, specific computational hardware, university computer science department, and the like. The dataset may store an indication of dates (e.g., years) during which a respective entity was trusted. The dataset may indicate the date at which the cryptographic process and optionally a key of a certain strength (e.g., as a combination) was broken. The dataset may be pre-existing, and/or dynamically created and/or updated by the entity performing the signing and/or in response to detecting a breaking of a certain cryptographic process. The dataset may be made publicly accessible. The dataset may be stored, for example, hosted by a central server, hosted by a blockchain, distributed in multiple copies at multiple locations, hosted by a computing cloud, and the like. For example, code may monitor data source. In response to identifying a report (e.g., news release, journal report, and the like) indicating that a combination of the certain cryptographic process and a certain key strength has been broken (and optionally which entity broken it), the code may automatically update the dataset.

At 208, metadata, including the current digital signature, may be created for the digital media asset.

The metadata may be created in response to successful verification(s), as described with reference to 206.

The metadata may further include one or more of:

The current date of creation of the current digital signature. • An expiration date of the current digital signature.

• Parameters of the cryptographic process used to compute the digital signature (e.g., which cryptographic process, length of key). Alternatively this information is omitted in case the cryptographic process that was used will be broken in the future, enable using the breaking approach to break the current digital signature.

• A unique identifier of the entity performing the signing. The entity may be verified using the unique identifier.

• One or more data elements of one or more preceding digital signatures and/or preceding metadata, from the immediately preceding metadata, from the sequence of all preceding metadata, or another implementation.

Additional details of the aforementioned data included in the metadata is now provided.

The current date may include at least the year. The day and/or month and/or time may be included.

The expiration date may be automatically selected to be earlier than a date predicted by a prediction model. The prediction model may predict the data at which it is likely that the cryptographic process optionally including the key length used for computing the current digital signature will be broken, for example, based on the expectation of development of more powerful computational hardware and/or software and/or code breaking processes. The prediction model may be implemented as, for example, a machine learning model such as a neural network, and/or deterministic model such as a support vector machine, or other implementations. The prediction model may be trained on a training dataset of records, where a record may include parameters of cryptographic processes and/or key lengths, computational hardware and/or software used to break the cryptographic process, and a ground truth indicating a date when the cryptographic process was broken using the corresponding computational hardware.

The unique identifier may include a private and/or public key that enables authenticating the entity that performed the signing. The unique identifier may be used for searching for the entity that performed the signing in a central dataset hosting identifiers of verified entities. The central dataset may be publicly available, implemented as, for example, a database hosted by a server, a distributed dataset such as hosted by a blockchain, and the like.

At 210, the metadata is stored.

Optionally, the metadata is stored by being embedded within the digital media asset, for example, in a video using stenography approaches, or other embedding approaches according to the type of digital media asset. Exemplary approaches for add metadata using stenography is described, for example, in Embedding Data in Video Stream Using Steganography, Author(s): Stanescu, Daniela; Stratulat, Mircea; Ciubotaru, Bogdan; Chiciudean, Dan; Cioarga, Razvan Dorel; Micea, Mihai Victor: Proceedings of the 32-nd IEEE International Symposium on Applied Computational Intelligence and Informatics, SACI 2007, incorporated herein by reference in its entirety.

Alternatively or additionally, the metadata may be stored within a dataset, such as a database. The dataset may be external to the digital media asset. The dataset may be publicly available. The dataset may be hosted, for example, by a central server, on a blockchain, a computing cloud, and the like.

Optionally, a combination of the cryptographic key and optionally key length (i.e., strength of the key) used to generate the digital signature for the digital media asset may be stored externally to the metadata, for example, within a dataset, such as a database. The dataset may be publicly accessed and/or hosted, for example, by a server, a blockchain, distributed at multiple locations, by a computing cloud, and the like.

At 212, the sealed digital media asset is provided. The sealed digital media includes the metadata with digital signature and optionally other data, as described herein.

The sealed digital media asset may be provided, for example, for long term stored in a storage device, for archiving, for being publicly accessible such as on a server and/or library, for recording an important historical event, and the like.

At 214, features described with reference to 202-212 are iterated.

In each iteration, another digital signature and another metadata instance is created, as described herein. The next digital signature may be computed using a stronger cryptographic process and/or stronger key than the strength of the cryptographic process and/or strength of the key used to compute preceding digital signatures.

A next iteration generating a next digital signature may be automatically triggered prior to the expiration date of a preceding digital signature. For example, the next iteration may be automatically triggered a predefined amount of time prior to the nearest expiration date, such as a year, two years, 5 years prior, or other values. Generating another digital signature for the digital media asset prior to expiration of the previously generated digital signature may help ensure a continuity of security, i.e., avoiding a time interval during which the digital media asset is unsecure against attack.

Alternatively or additionally, the next iteration may be automatically triggered in response to a prediction indicating likelihood that at least one preceding cryptographic process used for computing at least one preceding digital signature of the digital media item is likely to be broken. The prediction may be generated, for example, by the prediction model described herein, for example, with reference to 208 of FIG. 2.

Alternatively or additionally, the next iteration may be automatically triggered based on predefined time intervals, for example, every year, every 3 years, or other time intervals.

Alternatively or additionally, the next iteration may be automatically triggered based on events and/or a set of rules, for example, in response to identifying a significant improvement in computational technology, a significant improvement in code breaking algorithms, and the like.

Alternatively or additionally, the next iteration may be manually triggered, for example, by a human that believes that one or more existing cryptographic processes optionally using existing key lengths used for sealing the digital media asset is about to be broken.

Different iterations may be sealed by the same entity or by different entities. For example, a video may have been sealed by a first entity during the year 2023 and by a second entity that is different than the first entity during the year 2033, where each sealing creates a respective digital signature and corresponding metadata, as described herein.

If before the expiration date, the digital media asset is re- sealed by computing another digital signature, the digital media asset may be considered secure. For example, a video was initially sealed by computing a digital signature in 2023 with an expiration date of 2060, and the video was resealed in 2033, by computing another digital signature. The second seal was generated while the previous seal was in force (expiration of the previous seal is 2060). The second seal may be generated with a new cryptographic process and/or higher key strength. The expiring date of the new seal does not necessarily have to be later than the previous expiring date, but may be earlier, for example, 2055 for the second seal and 2060 for the first seal. The expiration date of the new seal may be earlier, for example, based on improved prediction by a prediction model according to more rapid developments in computing technology and/or code breaking approaches than previously predicted for the first seal. As such, the second seal, even though generated using stronger cryptography, may be predicted to be cracked earlier than previously expected, and is assigned the date of 2055 accordingly. The video now includes two seals (i.e., two authentications). The authentications have each a date in which they were created. If the sequence of dates starts from the original seal, and is continuous without a time interval during which there is not seal, the N+l date of creating the digital signature is earlier than the expiry of the preceding N’th expiration date, and the current date of signing of the current digital signature is earlier than the termination date of a subsequent digital signature(s), then the video is considered authenticated.

Referring now back to FIG. 3, at 302, a sealed digital media asset is accessed. The sealed digital media asset has been sealed using the process described with reference to FIG. 2.

The sealed digital media asset may be accessed by the same entity that sealed it, and/or by a different entity. For example, the digital media asset is an original video of a speech by a candidate for president. The digital media asset is sealed to preserve its originality. 20 years later, the video of the speech is accessed by a university student as part of a PhD thesis. The university student is able to verify originality using the verification process described herein.

At 304, the metadata associated with the sealed digital media asset is accessed.

The metadata may be extracted from the sealed digital media asset, such as when the metadata is embedded within the sealed media digital asset. Alternatively or additionally, when the metadata is stored externally to the digital media asset, such as by a dataset (e.g., database) such as by a server, blockchain, computing cloud, and the like, the dataset is accessed to obtain the metadata.

Multiple metadata instances associated with the sealed digital asset may be accessed. Each metadata instance was created using a respective iteration of the process described with reference to FIG. 2.

Each respective metadata instance includes a respective digital signature, a respective date of creation of the corresponding digital signature, a respective expiration date of the corresponding digital signature, and optionally other data, as described herein.

Optionally, each of the metadata instances includes a temporal identifier within a temporal sequence. The temporal identifier indicates the date of creation of the respective metadata instance relative to other metadata instances. The temporal sequence may indicate a timeline of the signatures. For example, when there are three metadata instances, the timeline of signatures extracted for the signed digital media asset may be denoted as NO<N1<N2.

At 306, one or more verifications may be performed for the sealed digital media asset, for ensuring that the digital media asset is original and/or has not been tampered with. The verifications may be based on a set of rules. Performing one or more verifications based on one or more of the metadata instances is referred to herein as a verification process.

The verification process may be performed for each one of the multiple metadata instances. The verification process may include one or more of the following verification approaches:

Optionally, the verification process includes verifying that the date of creation of each respective digital signature is prior to the expiration date of each corresponding preceding digital signature(s). In terms of mathematical notation, for each N+l digital signature (and/or metadata instance), the sealing was done before the Nth digital signature (and/or metadata instance) expires, for example, because of the expiration data associated with the Nth digital signature (and/or metadata instance) or because the Nth digital signature (and/or metadata instance) was no longer considered secure by the time N+l digital signature (and/or metadata instance) was created.

Alternatively or additionally, the verification process includes verifying that the date of creation of the respective metadata instance (and/or digital signature) is after a preceding metadata instance (and/or digital signature) and prior to a subsequent metadata instance (and/or digital signature) according to the temporal sequence, i.e., verifying continuity in the sequence of metadata instances (and/or digital signatures).

Alternatively or additionally, the verification process includes obtaining an indication of a combination of a process (e.g., cryptographic process) and/or key length used for generating the signature of the respective metadata instance, and verifying that the combination has not been broken. The indication of the combination may be obtained, for example, from the metadata instance, and/or by accessing the dataset described herein that stores the combinations for different digital media assets. The verification that the combination of the cryptographic process and/or key length (i.e., strength) used for generating the signature has not been broken may be determined when the combination is not in the dataset. Alternatively or additionally, the verification process may include verifying that the date when the combination including the cryptographic process was broken, according to the dataset, is after creation of a subsequent signature of a subsequent metadata instance using a stronger process.

Alternatively or additionally, the verification process includes obtaining respective public keys associated with respective metadata instances, and verifying each respective digital signature of the respective metadata instance using its respective public key. The verification may be done by computing a temporary digital signature by applying the respective public key to the digital media element, and comparing the temporary digital signature to the corresponding digital signature which was computing using the private key. A match indicates authenticity of the digital media element.

Alternatively or additionally, the verification process includes accessing (e.g., extracting) a respective unique identity of an entity (e.g., each entity) that generated the digital signature (e.g., each respective digital signature of each metadata instance), and validating the entity (or each entity) using the respective unique identity. The entity may be valid when the respective instance of the metadata (and/or digital signature) created by the entity occurred within a time interval during which the entity was determined to be trusted. The respective unique identity of the respective entity that sealed the respective metadata instance may be extracted from the respective metadata instance. The integrity of each entity that created each respective seal may be validated, for example, by accessing the dataset hosting indications of trusted entities, as described herein. The digital media asset may be considered as trusted as the entity who sealed (e.g., signed) it. When the sealing entity is trusted, the digital media asset that was signed by the trusted entity, for example, in 2023 and 2033, may be considered verified. Alternatively, untrusted entities may have sealed the digital media element at a different year than the signing date, for example, in 2026 saying it is 2023.

In a case in which the entity is not validated but other validations are successful, for example, the entity was trusted during a time interval but the signing by the entity was outside the time interval and other validations have been met, the digital media asset may be determined to be partially sealed, i.e., partially authentic. Alternatively, in a case in which the entity is validated (i.e., trusted) but other validations have failed, the digital media asset may be partially authentic, according to the trust of the sealing entity.

For example, for a digital media asset being validated in the year 2040, it was known that quantum machines have become available in 2035 with the exception that the US government had a working quantum computer in 2032. In this case when the digital media asset is being validated, the digital media asset may be partially authenticated, but not against attacks by the US government from 2032 to 2033. Depending on the content of the digital media asset this may be good enough (or not).

Optionally, the digital media asset may be determined to be validated (e.g., fully validated), for example, when all of the following set of rules/conditions are met:

• All the times of the respective metadata instances (i.e., the computed signatures) of the timeline are consecutive, and passed the current time.

• Every digital signature of a certain metadata instance was considered secure during the time before expiration of the next consecutive signature of the next metadata instance.

• All entities that created all digital signatures of all metadata instances are considered trusted during their time of creation of the digital signature.

For example, for the temporal sequence of two metadata instances (N=0, and N=l) for a certain digital media asset, for N=0 the sealing date was 2023, the expiration date is 2060, and the combination of the cryptographic key and the key strength is provided. For N=l, the sealing date was 2033, the expiration data is 2055, and the combination of the cryptographic key and the key strength is provided. Now, when the date during which validation is being performed for the certain digital media asset is 2040, the validation process as described herein indicates that there is an unbroken chain from creation of the first metadata instance to the current date. Therefore, if the entities creating the metadata instances were trusted at the time of sealing, the digital media asset is trusted, i.e., validated.

Alternatively, the digital media asset may be determined to be partially validated, for example, under the following set of rules/conditions:

• When some sealing entities are trusted but partially suspected.

• The temporal sequence of the metadata instances includes time intervals in which the cryptographic process (and optionally the key strength) may have been broken by specific players, but for the digital media asset being validated it is considered excepted risk.

At 308, an indication of the outcome of the validation process is provided, and/or an indication of originality of the digital media asset and/or a confirmation that the digital media asset is tamper free, may be provided. For example, a message is generated, presented on a display, provided to another computing device, and the like.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant cryptographic processes and keys will be developed and the scope of the terms cryptographic process and key are intended to include all such new technologies a priori.

As used herein the term “about” refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of" and "consisting essentially of".

The phrase "consisting essentially of" means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof. The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the invention may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

It is the intent of the applicant(s) that all publications, patents and patent applications referred to in this specification are to be incorporated in their entirety by reference into the specification, as if each individual publication, patent or patent application was specifically and individually noted when referenced that it is to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting. In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.

Claims

WHAT IS CLAIMED IS:

1. A computer- implemented method of signing a digital media asset for verification of originally, comprising: accessing a digital media asset; in at least two iterations, for a current iteration: computing a current digital signature of the digital media asset; verifying that a current date of creation of the current digital signature is prior to an expiration date of a preceding digital signature; in response to the verifying, creating a current metadata including the current digital signature, the current date of creation of the current digital signature, and an expiration date of the current digital signature; and embedding the current metadata within the digital media asset, wherein the current metadata is embedded in addition to preceding metadata generated in at least one preceding iteration.

2. The computer implemented method of claim 1, wherein the current iteration is automatically triggered prior to the expiration date of a preceding digital signature.

3. The computer implemented method of claim 1 , wherein the expiration date is automatically selected to be earlier than a date predicted by a prediction model indicating likelihood of breaking a cryptographic process used for computing the current digital signature.

4. The computer implemented method of claim 1, wherein the expiration date of the current digital signature precedes the expiration date of the preceding digital signature.

5. The computer implemented method of claim 1, wherein the current iteration is automatically triggered in response to a prediction that at least one preceding cryptographic process used for computing the at least one preceding digital signature of at least preceding metadata generated in at least one preceding iteration, wherein a current cryptographic process for computing the current digital signature for the current iteration is stronger than the at least one preceding cryptographic process.

6. The computer implemented method of claim 1, further comprising: accessing a dataset of cryptographic processes used for computing digital signatures known to have been broken, and strength of the process and/or strength of a key; and selecting a combination of a cryptographic process and/or a key strength for computing the current digital signature that does not appear in the dataset.

7. The computer implemented method of claim 6, further comprising monitoring a plurality of data sources for an indication of a certain combination of a certain cryptographic process and/or a certain key strength that has been broken, and automatically updating the dataset for indicating the combination of the cryptographic process and/or the key strength that has been broken.

8. The computer implemented method of claim 1, the metadata further including parameters indicating strength of a combination of a cryptographic process and/or a key strength used to compute the current digital signature.

9. The computer implemented method of claim 1, wherein the current metadata further includes a unique identifier of a current entity performing the signing, wherein the current entity is verifiable using the unique identifier.

10. The computer implemented method of claim 9, wherein the unique identifier includes a private or public key that enables authenticating the entity that performed the signing.

11. The computer implemented method of claim 9, wherein the unique identifier is used for searching for the current entity in a central dataset hosting identifiers of verified entities.

12. The computer implemented method of claim 1, wherein the digital media asset selected from: video, frame, image, audio file, and document.

13. The computer implemented method of claim 1, wherein the digital media asset is automatically created by a generative model.

14. The computer implemented method of claim 13, wherein the generative model is implemented as part of a digital human.

15. The computer implemented method of claim 1, wherein a process for signing each current digital signature is based on quantum-safe cryptography.

16. The computer implemented method of claim 1, wherein the current metadata includes at least one of: the preceding digital signature of the preceding metadata, the preceding metadata, a sequence of the preceding digital signatures of a plurality of preceding metadata, and a sequence of the preceding metadata.

17. A computer-implemented method of verifying originally of a digital media asset, comprising: extracting a plurality of metadata instances from a digital media asset; each metadata instance including a digital signature of a plurality of digital signatures of the plurality of metadata instances, a date of creation of the digital signature, and an expiration date of the digital signature; for each respective metadata instance, verifying that the date of creation of the respective digital signature is prior to the expiration date of the corresponding preceding digital signature; and in response to verifying dates of creation, verifying originality of the digital media asset.

18. The computer-implemented method of claim 17, further comprising: wherein each of the plurality of metadata instances includes a temporal identifier within a temporal sequence indicating date of creation relative to other metadata instances; for each respective metadata instance, verifying that the date of creation of the respective metadata instance is after a preceding metadata instance and prior to a subsequent metadata instance according to the temporal sequence.

19. The computer implemented method of claim 17, further comprising: for each respective metadata instance: obtaining an indication of a process used for generating the signature of the respective metadata instance; accessing a dataset storing a plurality of records, wherein a record is for a process used for computing digital signatures, indicating a date when the process was broken; and verifying that the process used for generating the signature is not in the dataset or the date when the process was broken is after creation of a subsequent signature of a subsequent metadata instance using a stronger process.

20. The computer implemented method of claim 17, wherein each respective metadata instance includes a unique identifier of an entity that sealed the respective metadata instance, and further comprising verifying integrity of each entity that sealed each respective metadata instance.

21. The computer implemented method of claim 17, further comprising: for each respective metadata instance: obtaining a respective public key; and verifying each digital signature of the respective metadata instance using the respective public key.

22. The computer implemented method of claim 17, further comprising: for each respective metadata instance: extracting a respective unique identity of an entity that generated the signature; and validating the entity using the respective unique identity.

23. The computer implemented method of claim 22, further comprising validating that the date of creation of the respective signature falls within a date interval during which the entity was determined to be valid.