Patent Publication Number: US-11394538-B2

Title: System and method for verifying the no-later-than date-of-existence, data integrity, identity of the recorder, and timestamp of the recording for digital content

Description:
BACKGROUND OF THE INVENTION 
     Field of the Invention 
     The disclosed subject matter relates to integrity verification, source verification, and time-of-existence verification of digital content. 
     BRIEF SUMMARY OF THE INVENTION 
     The present invention provides integrity verification, source verification, and time-of-existence verification of digital content. More particularly, the present invention presents system and method for verifying the no-later-than date-of-existence, data integrity, identity of the recorder, and timestamp of the recording for digital content is provided. The digital content may represent videos, computer code, images, certificates, audio, or any other digital file format. The provided system and method employ blockchain technology to ensure immutability and accessibility of digital content state, digital content recorder identity, and digital content record timestamp. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  presents an iconic view of the system and method. 
         FIG. 2  presents an exemplary flow of creating a NeoTrust ID. 
         FIG. 3  presents an exemplary flow of creating a NeoTrust file. 
         FIG. 4  presents an exemplary flow of creating a NeoTrust file. 
         FIG. 5  presents an exemplary flow of creating a NeoTrust Verification. 
         FIG. 6  presents an exemplary flow of creating a NeoTrust Verification. 
         FIG. 7  presents an exemplary flow of NeoTrust ID use. 
     
    
    
     DETAILED DESCRIPTION 
     The present invention presents a system and method for verifying the no-later-than date-of-existence, data integrity, identity  916  of the recorder, and timestamp of the recording for digital content is provided. The digital content may represent videos  944 A, computer code  944 B, images  944 C, certificates  944 D, audio  944 E, or any other digital file format. The provided system and method employ blockchain technology to ensure immutability and accessibility of digital content state, digital content recorder identity  916 , and digital content record timestamp. 
     To facilitate the verification of the identity  916  of the user creating and recording a NeoTrust archive file  944 , it is necessary for each user that will be creating and recording NeoTrust archive files to obtain a NeoTrust ID  912 . 
     The NeoTrust ID  912  is a secp256k1 cryptographic public/private key pair that serves to provide the functionality  932  for creating digital signatures (ie. digitally signing digital content digests with the private key). A “digest”, in this sense, is a fixed length code that is outputted by a hash algorithm. A hash algorithm is a mathematical calculation that produces a unique digest dependent on the contents of a digital file. The hash algorithm works in such a way that any difference to the file contents, no matter how small, will produce a different digest. 
     In the instant method and system, digests are used to record and verify the state of a digital file. The NeoTrust ID  912  is also mathematically linked (which may include dynamically electronically linking—such as via a Uniform Resource Locator [URL])  936  to the user&#39;s blockchain identity or address  932 . This due to the blockchain address  932  being mathematically generated from the public key that is part of the NeoTrust ID  912 . 
     The user must obtain 500 a NeoTrust ID  912  by inputting  504  into the NeoTrust program a scan of the user&#39;s government issued identity document (ie. driver&#39;s license, passport, state ID card) as well as a picture of the user&#39;s own face (selfie) taken at that time. The NeoTrust program then sends  508  this information to a trusted third party identity verification system in order to verify  512  that the submitted identity document is legitimate and that the user is in fact the person described in the identity document. This third party verification system will use software to determine the legitimacy of the submitted identity document and will determine whether the selfie was taken at that current time as well as if the selfie matches the image in the identity document. 
     If  512  a response from the trusted third party identity verification system indicating that the user&#39;s identity  916  was successfully verified is received by the NeoTrust program, it will request that the user create and input  516  a password for key encryption. The NeoTrust program then generates  520  a NeoTrust ID  912  and corresponding NeoTrust Key  904 . 
     The NeoTrust Key  904  is a keystore file that is a password encrypted version of the NeoTrust ID  912 . It is provided to the user as a more secure means to access  908  their NeoTrust ID  912 , as opposed to saving the unencrypted NeoTrust ID  912  private key. In this way, if a nefarious party got ahold of the NeoTrust Key  904 , they would still require the password to access  908  the associated NeoTrust ID  912  and would therefore not be able to forge a recorded NeoTrust archive file  944 . 
     The NeoTrust program then generates  524  a digital certificate called a BlockCert  924  which contains information regarding the user&#39;s identity  916  (ie. user full name) and issues  528  it to the user&#39;s NeoTrust ID  912  linked  936  blockchain address  932  in the form of a blockchain transaction. The BlockCert  924  serves as a link  920  to the user&#39;s real world identity  916  and a link  928  to the user&#39;s NeoTrust ID  912 . The blockchain transaction is sent from the NeoTrust program&#39;s blockchain address to the user&#39;s NeoTrust ID  912  linked  936  blockchain address  932  so that verification of the issuer (ie. the NeoTrust Program) and the recipient (ie. the NeoTrust user) is possible. This transaction also stores as meta-data the SHA256 digest of the entire BlockCert  924 , as generated by the NeoTrust program. Issuing the BlockCert  924  in this manner provides an immutable record linking the BlockCert  924  (ie. the user&#39;s real world identity  916 ) to the user&#39;s NeoTrust ID  912  linked  936  blockchain address  932 . 
     The user should download and securely store  532  the NeoTrust Key  904  and BlockCert  924  on a local device and keep the NeoTrust Key  904  private. At this point, the process of creating a NeoTrust ID is complete  536 . 
     Once the user has obtained their NeoTrust ID  912  and NeoTrust Key  904 , they must load  600  their NeoTrust ID  912  linked  936  blockchain address  932  with funds in order to create and record NeoTrust archive files  944 . This is because public blockchains, such as Ethereum and Bitcoin, require funds to send transactions, and the data that must be recorded for verification purposes is held in such a transaction. To load their blockchain address  932  with funds, the user must contact a cryptocurrency exchange and purchase the appropriate cryptocurrency  604 , depending on which blockchain the embodiment in question uses. The cryptocurrency must then be deposited  608  into the user&#39;s NeoTrust linked  936  blockchain address  932  in order for it to be accessible for recording NeoTrust archive related data on the blockchain. 
     Once the proper funds have been deposited into the user&#39;s NeoTrust ID  912  linked  936  blockchain address  932 , the user has the ability to create  700  a NeoTrust archive file  944  and record all verification related information on the blockchain using their NeoTrust ID  912  with the NeoTrust program. In the first step of this process, the user inputs  704  their NeoTrust Key  904  and BlockCert  924 . The NeoTrust Key  904  is required to access the user&#39;s NeoTrust ID  912  and the BlockCert  924  is required to provide proof of their identity  916  to any parties that would verify the created Neotrust. 
     The user then inputs  708  their password which allows the NeoTrust program to decrypt  716  the NeoTrust Key  904  and generate the private key (ie. the private portion of the NeoTrust ID  912 ). Accessing the NeoTrust ID  912  enables the functionality to create and record a NeoTrust archive file  944 . The target directory (ie. the file or set of files that the user would like to generate a NeoTrust archive file  944  from) is then inputted  712  into the NeoTrust program. Any type of file format can be in the target directory including video files  944 A, computer code files  944 B, image files  944 C, digital certificates  944 D, audio files  944 E, and more. 
     The NeoTrust program then verifies  720  the user inputted BlockCert  924  on the blockchain to ensure that the NeoTrust program issued the BlockCert  924  and that it is in the exact same state as when it was issued. This is accomplished by the NeoTrust program generating a SHA256 digest of the user inputted BlockCert  924  and comparing this digest against the digest recorded in the blockchain transaction of the BlockCert  924  issuance. If  720  the NeoTrust Program was able to successfully verify the BlockCert  924 , the NeoTrust program generates  724  a directory named “META-INF” within the user inputted target directory. 
     The “META-INF” directory will hold all the meta-information files that allow for verification of the NeoTrust archive file  944 . The NeoTrust program generates  728  a copy of the user inputted BlockCert  924  and saves it within the “META-INF” directory. This ensures that the certificate, and thus the identity  916  of the user that created the NeoTrust archive file  944 , is verifiable. The NeoTrust program then generates  732  the public key portion of the user&#39;s NeoTrust ID  912  from the private key portion and saves  736  it to a newly created manifest file within the “META-INF” directory. 
     To record the state of the digital content being converted into a NeoTrust archive file  944 , the NeoTrust program generates  740  a SHA256 digest for each file contained within the user inputted target directory and saves  744  each digest along with the corresponding file name as entries in the manifest file. The NeoTrust program then generates  748  a SHA256 digest of the entire manifest file. The manifest file digest serves as a digest that is representative of all of the file contents within the user inputted target directory. If anything changes in the content of any of the files, the manifest file digest will be different. 
     The NeoTrust program then creates and sends  752  a blockchain transaction containing the manifest file digest from the user&#39;s NeoTrust ID  912  linked  936  blockchain address  932 . The manifest file digest is held in the meta-data portion of the blockchain transaction. The NeoTrust program includes  756  the previously sent blockchain transaction hash, SHA256 digests for each manifest file entry, and the digest of the entire manifest file in the signature file. The signature file serves as a receptacle for all metadata collected for the NeoTrust archive file  944  creation and recording process up to this point. It links together the target file structure, target file names, target file digests, blockchain transaction so that the state of each of those elements can be saved into one file. 
     The NeoTrust program then generates  760  a SHA256 digest of the entire signature file, thus solidifying in code the state of the previously mentioned elements. The NeoTrust program then uses the private key portion of the user&#39;s NeoTrust ID  912  to sign  764  the digest of the entire signature file, producing a digital signature. This digital signature is saved  768  to a newly created signature block file in the META-INF directory. The signature block file provides verifiable proof that all of the previously mentioned elements have not been altered after the creation of a NeoTrust Archive file  944 . The NeoTrust program then compresses  772  the target directory, which now includes a META-INF directory, into a NeoTrust archive file  944  and returns  776  this file to the user. At this point, the process of creating and recording a NeoTrust archive file  944  is complete  780 . 
     Once the NeoTrust archive file  944  creation and recording process is complete, the files no-later-than date-of-existence, data integrity, identity  916  of the recorder, and timestamp of the recording can be verified  800 . Verification of a NeoTrust archive file  944  does not require the verifying user to have a NeoTrust ID  912  nor does it require any transfer of funds. 
     To verify  800  a NeoTrust archive file  944 , a user first inputs  804  the NeoTrust archive file  944  they would like to verify into the NeoTrust program. The NeoTrust program decompresses  808  the NeoTrust archive file  944  in a file directory. The NeoTrust program then generates  812  SHA256 digests for all files within the decompressed directory. This is the first step to ensuring that no changes have been made to the NeoTrust archive file  944  being verified after it was signed by the creator of that NeoTrust archive file  944 . 
     The NeoTrust program then generates  816  a manifest file that is held in a buffer in memory. This manifest file buffer includes entries for each SHA256 digest generated from the files in the archive directory along with the corresponding file names. It also includes the public key, found in the original manifest file of the NeoTrust archive, of the user that created the NeoTrust archive file  944  being verified. 
     The NeoTrust program then generates  820  a SHA256 digest for the entire manifest file buffer and generates  824  SHA256 digests for each file entry in the manifest file buffer. A signature file is then generated  828  that is held in a buffer in memory. This signature file buffer includes entries for each SHA256 digest generated from the manifest file buffer entries along with the corresponding file names. It also includes the hash of the blockchain transaction associated with the NeoTrust archive file  944  being verified. This blockchain transaction hash is copied from the original signature file included in the NeoTrust archive file  944 . 
     The NeoTrust program then generates  832  the NeoTrust archive file  944  creator&#39;s blockchain address  932  from the public key provided in the original manifest file of the NeoTrust archive. The blockchain transaction is then accessed  836  via transaction hash. The blockchain address  932  generated  832  is then compared to the blockchain address that sent the blockchain transaction. 
     If  832  both blockchain addresses match, it lends proof that the person who sent the NeoTrust archive is in fact who they claim to be and the verification process  800  moves on to verify  840  that the SHA256 digest generated from the manifest file buffer matches the SHA256 digest held in the blockchain transaction meta-data. If  840  the digests match, it lends proof that the content and structure of the files contained in the NeoTrust archive have not been altered since creation and the verification process  800  moves on to the next step. 
     However, with the verification measure put forth thus far, there is a risk that a malicious actor has altered the blockchain transaction hash contained in the signature file of the NeoTrust archive. Altering the blockchain transaction hash in such a way allows it to reference a falsified blockchain transaction that could return a falsified timestamp, that is, a falsified no-later-than date-of-existence for the NeoTrust archive file  944 . This risk is handled in a later step  872  of the NeoTrust archive file  944  verification process  800 . 
     Once the NeoTrust program determines that manifest file digest buffer matches the manifest file digest held in the blockchain transaction, the verification process  800  moves on to extract  848  and store the timestamp of the block in the blockchain that contains the transaction. The timestamp must be taken from the block rather than the transaction itself because blockchain transactions do not have timestamps. Due to this, there will be a time difference, the length of which is dependent on the traffic of the blockchain network at that time, between the time of actual creation of the NeoTrust archive file  944  and the timestamp that is used for the NeoTrust archive file  944  no-later-than date-of-existence. As the timestamp of the block that contains the NeoTrust archive blockchain transaction will always be later than the actual time of creation, the timestamp still serves as a valid no-later-than date-of-existence for the NeoTrust archive file  944 . 
     The NeoTrust program then generates  852  a SHA256 digest of the BlockCert  924  contained in the NeoTrust archive. The digest of the BlockCert  924  is held in a buffer in memory. The NeoTrust program then accesses  856  the blockchain transaction that holds the original SHA256 digest of the BlockCert  924  to compare the generated digest with the digest held in the transaction. The blockchain transaction being checked was created and sent when the BlockCert  924  was originally issued  528  to the user that created the NeoTrust archive file  944  being verified. If  860  both BlockCert  924  digests match, it lends proof that the user who sent the NeoTrust archive is in fact who they claim to be and the verification process  800  moves on. A verified  860  BlockCert  924  combined with a verified  840  creator blockchain address  932  provide complete proof that the sender of the NeoTrust archive file  944  is in fact who they claim to be. 
     Once it is determined that the generated BlockCert  924  digest matches the BlockCert  924  digest held in the blockchain transaction, the verification process  800  moves on to generate  864  a SHA256 digest of the signature file buffer that was generated earlier in the process. The signature block file contained in the NeoTrust archive is then decrypted  868  using the public key of the user that created the NeoTrust archive file  944 . The public key is found in the manifest file in the NeoTrust archive. 
     The NeoTrust program then verifies  872  that the digest resulting from decrypting  868  the signature block file matches the digest of the signature file buffer generated earlier in the verification process. If  872  both digests match, it lends proof that the content and structure of the files in the NeoTrust archive has not been altered since creation of the NeoTrust archive file  944  and that the blockchain transaction hash contained in the manifest file has not been altered. 
     At this point, the verification process of the NeoTrust archive file  944  is considered to have succeeded  876 . The no-later-than date-of-existence and the identity  916  information of the signer is then displayed  880  to the user, along with a message stating that verification has succeeded. The NeoTrust archive verification process then ends  888 .