Patent ID: 12200142

Reference is made to the accompanying drawings throughout the following detailed description. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative implementations described in the detailed description, drawings, and claims are not meant to be limiting. Other implementations may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented here. It will be readily understood that the aspects of the present disclosure, as generally described herein and illustrated in the figures, can be arranged, substituted, combined, and designed in a wide variety of different configurations, all of which are explicitly contemplated and made part of this disclosure.

DETAILED DESCRIPTION

In order to protect sensitive information cryptography, PKIs, and digital signatures are used to securely transmit and validate data integrity of the sensitive information. However, long-term retention of digitally signed data is difficult as cryptographic keys have limited periods where the underlying cryptography are valid, PKI certificates expire or are revoked, digital signature algorithms change, hash algorithms change, keys are revoked, and underlying schemas may change or become compromised over time. There are many reasons cryptographic algorithms and digital signature schemas may change, for example: discovering vulnerabilities, developing superior characteristics, or adapting to new security standards and policies. Accordingly, many current electronic signatures solutions are based on technology that cannot sustain itself over a cryptographic transition as the original data is re-signed using different keys, such that continuity and data integrity relies wholly on system or application logs. Thus, changes to the cryptography applied or digital signature schema used must be properly implemented to continue to protect the long-term signed data but retain signed data integrity. In other words, there is a need for a mechanism to provide data continuity for long-term retention periods that do not lend themselves to cryptographic solutions and/or rely on non-cryptographic cybersecurity methods (e.g., access controls, logs, etc.)

Various embodiments described herein relate to systems and methods for a time-based digital signature system. Generally, the time-based digital signature system provides a crypto-based solution using reliable standards-based methods to provide data continuity for long-term retention periods. Using a time-based digital signature message, signed data may be refreshed, signed, and/or re-signed to retain overall continuity of the original signed data. This time-based digital signature system provides data integrity and origin authenticity for signed data through long-term retention. As will be appreciated, the time-based digital signature message data can be verified at any point in the long-term retention and provides a record of where the data was compromised or changed, thereby enabling the detection of the problem point.

The time-based digital signature system is structured to generate, monitor, and refresh signed data to retain the overall continuity of the original signed data. The time-based digital signature may include the signature and corresponding PKI credentials for a wide variety of certificates (e.g., X509). The time-based digital signature system may utilize a variety of extensions to the cryptographic techniques defined in the ANSI X9.73, ANSI X9.79, ITU-T Recommendation X.894, ANSI X9.95, ISO 21188, or other Cryptographic Message Syntax (“CMS”) Standard. In some embodiments, the time-based digital signature system receives signed data and other information and submits a hash of the data to a Trusted Time Authority or Time Stamp Authority (“TSA”) to get a first Time Stamp Token (“TST”). The time-based digital signature system utilizes the first TST and the signed data to generate a time-based digital signature message. When an event necessitates an update to the time-based digital signature message, the time-based digital signature system facilitates the generation of a second TST and generates a second time-based digital signature message. In some embodiments, a second data signature (subsequent from the first data signature in the underlying content) is added to the first TST using a second TST. In some embodiments, a combined hash of the first TST and the second signature information is used to retain the overall continuity of the first (e.g., original) and second signature. In some embodiments, a second signature is needed on the previously signed time-based digital signature message. The second signature is added onto the first TST, and a combined hash of the first TST and the second signature information is used to generate the second time-based digital signature message to retain the overall continuity of the underlying content.

In some embodiments, the time-based digital signature system may utilize SignedData, detached SignedData, and SigncryptedData message schema, each of which provides unique functionality. Generally, the digital signature process is also referred to as “signing a message digest.” The message digest includes hash values that represent the specific, digitally signed time-based digital signature messages in the time-based digital signature system. A message digest is assigned to particular data content such that a change to any of the content within a time-based digital signature message will be reflected in the message digest. In some arrangements, the message digest includes a direct signature that does not first hash the information to be protected before signing the content. In some arrangements, a signature key that includes a set of private data elements specific to an entity and usable only by this entity in the signature process may be used for the digital signature process. Beneficially, under the CMS message type SignedData, there may be more than one message signer, each using a different public-private key pair and signature algorithm.

Referring generally to the use of the SignedData schema, a SignedData message is generated at each step in the time-based digital signature message encapsulation. Each successive step in the processing chain wraps another SignedData message around the previous message, and additional attributes can be added to the SignedData messages at each step. Using the detached SignedData schema, a hash of the time-based digital signature message is signed at each step in the processing chain and is transmitted out-of-band. As will be appreciated, the actual processing message content is not present, which maintains confidentiality throughout the process. With SignedData or detached SignedData, each financial institution can perform recursive descent at each step in the time-based digital signature message encapsulation to validate the integrity of each layer of the time-based digital signature message at each step.

As will be appreciated, the time-based digital signature system may be used to verify digital signatures in connection with secure communications, funds transfers, e-commerce transactions, or other digitally signed messages (e.g., cloud-based, blockchain-based, distributed ledgers, or smart contract systems) and to ensure that the signed data is updated and secured for long-term retention. The systems and methods address the requirement to protect data for long term retention even when it is stored in a publicly accessible environment, such as the cloud or within a blockchain, distributed ledger, and/or smart contracts, in a flexible way that is file and data-element neutral. In some embodiments, a signed smart contract relies on a certificate that expires requiring that the same key is certified (e.g., renewal) in a new certificate and “wraps” over the initial signature. To provide integrity, authentication, and non-repudiation, the time-based digital signature messages are bound by a TST and, in some embodiments, digitally signed by the time-based digital signature system.

The time-based digital signature system provides technical solutions to computer-centric and internet-centric problems associated with conventional message systems. By having the signed data encapsulated in a TST, a compromised aspect of the underlying cryptography or digital signature will be “protected” by being encapsulated in an up-to-date TST and/or digital signature. Accordingly, forensic analysis on a time-based digital signature message along the time-based digital signature message chain would ascertain when the time-based digital signature message was altered. Through digital signature verification and path validation, the time-based digital signature system provides a simple, yet effective, mechanism for protecting, monitoring, and updating a time-based digital signature message.

Further, the methods and systems described herein alleviate the strain on processing power and memory components currently required to manage, store, and authenticate signed data during long-term storage. The time-based digital signature system allows for the integration for encryption and signature schemes efficiently without sacrificing each scheme's security. In some embodiments, the time-based digital signature system utilizes a signed attributes feature to provide for an easy and lightweight mechanism to bind additional information to message. Accordingly, time-based digital signature system can be easily adapted to support new financial institution applications and security requirements. Additionally, making use of a TST from a TSA enables a relying party to determine when a message was digitally signed and that it is “fresh” (e.g., that the sample is not from an unauthorized party along the processing chain). Beneficially, the time-based digital signature system may implement a unique utilization of extensions to SignedData processing. The unique utilization of extensions to SignedData processing do not prohibit the use of currently deployed, long-term retention-vulnerable signature schemes. The time-based digital signature system provides a more efficient and effective authentication mechanism, alleviating processing power and network congestions, as the time-based digital signature system does not require moving the current signature systems to what are believed to be safe algorithms. Beneficially, the time-based digital signature system operates within the deployed signature schemes while allowing the data to be proactively resistant and providing origin authenticity and data integrity to a message during long-term retention.

These problems arise out of the use of computers and the internet because each problem involves processing power, bandwidth requirements, storage requirements, and information security, each of which is inherent to the use of computers and the internet. The problems also arise out of the use of computers and the internet, because online communications, transactions, and payment services and the ability to properly store signed data and/or an online communication cannot exist without the use of computers and the Internet.

Referring toFIG.1, a functional block diagram of a time-based digital signature system100is illustrated, according to an example embodiment. The time-based digital signature system100is used to generate a time-based digital signature message by facilitating and storing a TST that includes the signed data110. The time-based digital signature system100is structured to update the time-based digital signature message upon the occurrence of an event requiring the time-based digital signature message to be updated through the generation method140. By wrapping the time-based digital signature message in one or more TSTs and in a digital signature, the data integrity and origin authenticity of the underlying signed data110can be evaluated at each step along the time-based digital signature message. As shown inFIG.1, the time-based digital signature system100includes a signing party102(e.g., signer), signed data110, a time-based digital signature computing system104, and a TSA106. The TSA106is managed by a TSA or time authority.

The process of using the time-based digital signature system100begins when the signing party initiates a digital signature process130on content112(e.g., message, data, etc.) to generate signed data. The signed data110includes the content112cryptographically bound under a digital signature114(e.g., a first digital signature). The digital signature114may be generated using a wide variety of digital signature algorithms and/or key pairs. A variety of cryptographic techniques are used to encrypt data and to create digital signatures114. With symmetric key cryptographic systems, a pair of users who desire to exchange data securely use a shared “symmetric” key. With this type of approach, the signing party102of the signed data110uses the same key to encrypt the message that a recipient of the message uses to decrypt the message. Symmetric key systems require that each sender and recipient establish the shared key in a secure manner. Public key systems (e.g., asymmetric key cryptography) may also be used to exchange messages securely. With public-key cryptographic systems, two types of keys are used-public keys and private keys. A signing party102of the signed data110may encrypt the message using the public key of a recipient. The recipient may use a corresponding private key to decrypt the message.

The X.509 extension mechanism in version 3 allows the X.509 to be extended by anyone with a need without requiring any change whatsoever to the X.509 standard. These “protocol holes” are a free form, open ended location that a user of the protocol can fill in with anything they need or that suits them. Each extension is a package containing an identifier of its content (e.g., the extension payload) and the extension content. The content may be of any type of data and of any kind or format. Additionally, X.509 has two Distinguished Names (“DN”) in every certificate, one DN for the certificate subject and another DN for the certificate issuer, implemented as a set of attributes. The X.509 DNs can be cryptographically bound by a digital signature of the certificate issuer. In some embodiments, the certificates116may be provided as signed attributes that can serve the same function in an identity management context as “signed claims” or “signed assertions” provided using assertions.

In some arrangements, the certificate116is a “sequence” type containing a component that is the content-to-be-signed, the digital signature on the content-to-be-signed component, and information indicating the signing party's public key, the digital signature algorithm used, and additional parameters used to form the signed data110. In other arrangements, the digital signature of the signed data110is in the form used to sign X.509 attributes. The attributes can be used, for example, to identify a particular transaction type or entity, such as a credit card service provider. In some arrangements, each signed data110could be entity-specific, with each signed data110including as an attribute an identifier of the associated entity. In some arrangements, the key pair is associated with a certificate116in a PKI.

The singing party102transmits132the signed data110to the time-based digital signature computing system104. In some embodiments, the signing party102may have an account or be enrolled in services provided by the time-based digital signature computing system104. The time-based digital signature computing system104receives the signed data110and begins the time-based digital signature generation method140of the first time-based digital signature message150. The generation method140begins with the time-based digital signature computing system104generating a hash122of the signed data110information. In some embodiments, the hash122includes the entire signed data110. In other embodiments, the hash122includes the underlying content112bound under the digital signature114without the certificate(s)116. Notably, the digital signature process130and the generation method140may not utilize a merkle tree and may be algorithm agnostic. The time-based digital signature computing system104transmits the hash122to the TSA106with a request to the TSA106to generate a TST.

The TSA106may be in communication with a plurality of time source entities, such as the International Time Authority, the National Measurement Institute, and a Master Clock. The TSA106may use the time source entities to generate multiple TSTs, each corresponding to a time source entity, or the TSA106may determine a time consensus for which to generate a single TST. The TSA106generates a first TST (TST1)124and returns it to the time-based digital signature computing system104to associate the first TST124with the signed data110. The first TST124allows a verifying entity to compare the hash of the information data entry to the information data entry to verify that they correspond to the same information and, because the time stamping authority is trusted, that the information data entry was generated at the time indicated on the time stamp.

The time-based digital signature computing system104receives the first TST124from the TSA106. The time-based digital signature computing system104stores the first time-based digital signature message150, which includes only the first TST124at this time, in a repository120. In some embodiments, the first time-based digital signature message150is digitally signed by the time-based digital signature computing system104. In those embodiments, the digital signature process may not utilize a Merkle tree and may be algorithm agnostic. The repository may reside on a local device, a server or mainframe based service, a third party server, or similar storage locations. The time-based digital signature computing system104may be configured to catalogue and identify the various aspects (e.g., digital signature schemas, cryptography, CRLs, etc.) of each signed data110in the repository120. In some embodiments, the time-based digital signature computing system104is configured to monitor the various aspects (e.g., digital signature schemas, cryptography, CRLs, etc.) of all signed data messages within the repository120. In other embodiments, a third-party is configured to monitor the various aspects (e.g., digital signature schemas, cryptography, CRLs, etc.) that are implemented within at least on the signed data messages within the repository120.

Upon the occurrence of an event (e.g., compromise or changes to the cryptography applied or digital signature schema), the time-based digital signature computing system104facilitates an update of the first time-based digital signature message150. Beneficially, the time-based digital signature computing system104can identify a change to an aspect and identify which signed data messages in the repository120are affected by the change. The time-based digital signature computing system104retrieves the first time-based digital signature message150that includes the signed data110and initiates the generation method140to generate a second time-based digital signature message200.

The generation method140begins again with the time-based digital signature computing system104generating a hash222of the first TST124. The time-based digital signature computing system104transmits the hash222to the TSA106with a request to the TSA106to generate a second TST (TST2)224. The TSA106generates a second TST224and returns it to the time-based digital signature computing system104. The second TST224allows a verifying entity to compare the hash of the information data entry to the information data entry to verify that they correspond to the same information and, because the time stamping authority is trusted, that the information data entry was generated at the time indicated on the time stamp.

The time-based digital signature computing system104receives the second TST224from the TSA106. The time-based digital signature computing system104stores the second time-based digital signature message210, which the first TST124and the second TST224at this time, in a repository120. In some embodiments, the second time-based digital signature message210is digitally signed by the time-based digital signature computing system104. The second time-based digital signature message210is shown inFIG.2. The event occurrence and generation method140may occur multiple times to create an N-th TST with (N−1) TSTs nested within to form an N-th time-based digital signature message200, as shown inFIG.2.

In some embodiments, the time-based digital signature computing system104generates a second TST using a time-based resign message300shown inFIG.3. A difference between the time-based resign message300and the second time-based digital signature message200is that the time-based resign message300generates a second signature. Upon the occurrence of an event, the time-based digital signature computing system104facilitates an update of the first time-based digital signature message150. The time-based digital signature computing system104retrieves the first time-based digital signature message150, including the signed data110, and initiates the generation method140to generate a time-based resign message300.

The generation method140for the time-based resign message300begins with the time-based digital signature computing system104generating a second digital signature314(Signature2) on the content112of the original signed data110. In some embodiments, the second digital signature314is generated by the time-based digital signature computing system104digitally signing the original content112using a key pair of the time-based digital signature computing system104. In other embodiments, the time-based digital signature computing system104facilitates the signing party102providing the second digital signature314. The second digital signature314includes certificate316associated with the second digital signature314.

The time-based digital signature computing system104generates a combined hash322of the first TST124and the second digital signature314to retain the overall continuity of the original and second signatures114,314. The time-based digital signature computing system104transmits the hash322to the TSA106with a request to the TSA106to generate a second TST (TST2)324. The TSA106generates a second TST324and returns it to the time-based digital signature computing system104. The second TST324allows a verifying entity to compare the hash of the information data entry to the information data entry to verify that they correspond to the same information and, because the time stamping authority is trusted, that the information data entry was generated at the time indicated on the time stamp.

The time-based digital signature computing system104receives the second TST324from the TSA106. The time-based digital signature computing system104stores the second time-based digital signature message310, which includes the first TST124and the second TST324at this time, in a repository120. In some embodiments, the second time-based digital signature message310is digitally signed by the time-based digital signature computing system104. In those embodiments, the digital signature process may not utilize a merkle tree and may be algorithm agnostic. The second time-based digital signature message310is shown inFIG.3. The event occurrence and generation method140may occur multiple times to create an N-th TST with (N−1) TSTs nested within to form an N-th time-based resign message300, as shown inFIG.3. As will be appreciated, the generation method140ofFIG.2and the generation method140of the time-based resign message300ofFIG.3may be used interchangeably and/or in tandem to generate an N-th time-based digital signature with TSTs nested within.

In other embodiments, the time-based digital signature computing system104generates a second TST324using a time-based resign signed message400, as shown inFIG.4. A difference between the time-based resign signed message400and the second time-based digital signature message200is that the time-based resign signed message400generates a second signature414(Signature2). Upon the occurrence of an event the time-based digital signature computing system104facilitates an update of the first time-based digital signature message150. The time-based digital signature computing system104retrieves the first time-based digital signature message150that includes the signed data110and initiates the generation method140to generate a time-based resign signed message400.

The generation method140for the time-based resign signed message400begins with the time-based digital signature computing system104generating the second digital signature414(Signature2) on the first TST124. In some embodiments, the generation method140includes re-signing the signed data110. In some embodiments, the second digital signature414is generated by the time-based digital signature computing system104digitally signing the original content112using a key pair of the time-based digital signature computing system104. In other embodiments, the time-based digital signature computing system104facilitates the signing party102providing the second digital signature414. The second digital signature414includes a certificate416associated with the second digital signature414.

The time-based digital signature computing system104generates a combined hash422of the first TST124and the second digital signature414to retain the overall continuity of the original and second signatures114,414. The time-based digital signature computing system104transmits the hash422to the TSA106with a request to the TSA106to generate a second TST (TST2)424. The TSA106generates a second TST424and returns it to the time-based digital signature computing system104. The second TST424allows a verifying entity to compare the hash of the information data entry to the information data entry to verify that they correspond to the same information and, because the time stamping authority is trusted, that the information data entry was generated at the time indicated on the time stamp.

The time-based digital signature computing system104receives the second TST424from the TSA106. The time-based digital signature computing system104stores the second time-based digital signature message410, which includes the first TST124and the second TST424at this time, in a repository120. In some embodiments, the second time-based digital signature message410is digitally signed by the time-based digital signature computing system104. In those embodiments, the digital signature process may not utilize a merkle tree and may be algorithm agnostic. The second time-based digital signature message410is shown inFIG.3. The event occurrence and generation method140may occur multiple times to create an N-th TST with (N−1) TSTs nested within to form an N-th time-based resign signed message400, as shown inFIG.3. As will be appreciated, the generation method140ofFIG.2, the generation method140of the time-based resign signed message400ofFIG.3, and the generation method140of the time-based resign signed message400ofFIG.4may be used interchangeably and/or in tandem to generate an N-th time-based digital signature with TSTs nested within.

In other embodiments, the based digital signature computing system104is used to generate a distributed ledger-based system. Turning toFIG.5A, a distributed ledger time-based digital signature system500is shown, according to an example embodiment. The distributed ledger time-based digital signature system500may implement one of the methods described above with respect toFIGS.1-4to generate a time-based digital signature message. Generally, each block in the distributed ledger time-based digital signature system500may include a TST such that each subsequent block includes another encapsulated TST.

The distributed ledger time-based digital signature system500begins with the generation of a first block (B0)502that includes a first TST514and a hash512of the signed data. A second block (B1)504is generated upon an occurrence of an event and includes the second TST522and a hash522of the first block. A third block (B2)506is generated upon an occurrence of an event and includes the third TST534and a hash532of the second block. The generation of the first TST514, second TST522, and/or third TST534may be done using a method similar to generation method outlined above with respect toFIGS.1-4.

Turning toFIG.5B, a distributed ledger time-based digital signature system550with multiple signers is shown, according to an example embodiment. The distributed ledger time-based digital signature system550may implement a method described above, with respect toFIGS.1-4, to generate a time-based digital signature message. Generally, each block in the distributed ledger time-based digital signature system550may include a TST such that each subsequent block includes another encapsulated TST. Beneficially, each organization need not sign a subsequent block if an update is not needed.

The distributed ledger time-based digital signature system550begins with the generation of a first block (B0)552that includes a first entity first TST560, second entity first TST562, third entity first TST564, a hash566of the collection of the first TSTs560,562,564, and a hash568of the signed data. A second block (B1)554is generated upon an occurrence of an event and includes the first entity second TST570, third entity second TST574, a hash576of the collection of the first entity second TST570and the third entity second TST574, and a hash578of the first block. A third block (B2)556is generated upon an occurrence of an event and includes the first entity third TST580, second entity second TST582, a hash586of the collection of the first entity third TST580and the second entity second TST582, and a hash588of the second block. In some embodiments, the SignerInfo is used to identify the public key needed to verify the signature.

The SignerInfo may contain a pair of hash and pointer values that link and identify an associated blockchain. In some embodiments, the SignerInfo may contain an extended hash-pointer, which includes a hash, a pointer, and the type of data being pointed to, for example, an OID that identifies a distributed ledger block. The SignerInfo may first create a SignedData message that first serves as the first block in the associated blockchain and includes in that first associated blockchain block a preceding block attribute that points back to the parent blockchain's block (e.g., block N). The message digest of the content in that first block in the associated blockchain is the value used as “hash2” in SignerInfo.

FIG.6is a schematic diagram of a time-based digital signature system600, according to an example embodiment. The time-based digital signature system600includes a time-based digital signature computing system604, a signing party computing system602, and a TSA computing system606. Each of the time-based digital signature computing system604, the signing party computing system602, and the TSA computing system606are in operative communication with the others via a network610. According to various embodiments, the time-based digital signature system600may be utilized to implement the generation method140ofFIG.1to generate the second time-based digital signature message210ofFIG.2, the time-based resign signed message400ofFIG.3, and the time-based resign signed message400ofFIG.4. The signing party computing system602may be managed by the signing party102ofFIG.1, the time-based digital signature computing system604may be managed by the time-based digital signature computing system104ofFIG.1, and the TSA computing system606may be managed by the TSA106ofFIG.1. Additionally, the time-based digital signature system100ofFIG.1may be a part of the time-based digital signature system600.

The signing party computing system602includes a network interface circuit612, a key generation circuit614, and a digital signature circuit616. The network interface circuit612is structured to facilitate operative communication between the signing party computing system602and other systems and devices over the network610. The signing party computing system602may include smartphones, tablet computing systems, laptop computing systems, desktop computing systems, PDAs, smart watches, smart glasses, tablets, tagged objects, RFIDs, etc.

The key generation circuit614is structured to generate a public/private key pair for the digital signature of a quantum-resistant message. In some arrangements the public/private key pair is associated with a digital certificate in a PKI, such as the X.509 certificate. In those arrangements, a key pair is generated (the private/public key pair must be generated together as they are mathematically related), the private key signs the public key, and the pair is summited to the CA or the front end registration authority that will then generate that public key certificate. Alternatively, the private/public key pair could be issued with a commercial CA, such as one associated with a financial institution. In some arrangements, the signing party computing system602retrieves a public key certificate from the commercial CA and uses the certificate to ascertain the public/private key pair. In other embodiments, the key generation circuit614generates an ephemeral public/private key pair that is not associated with a digital certificate in a PKI. The key generation circuit614may compile any certificates included in the signed data.

The digital signature circuit616is structured to generate the signed data by retrieving the key from the key generation circuit614and digitally signing (and, therefore, cryptographically binding) the content, and facilitating the generation of the signed data. The digital signature circuit616may manage the key generation circuit614and control the generation of key pairs according to the desired signed data (e.g., whether the key is associated with a PKI, CA, etc.). Once a key pair is generated, the digital signature circuit616determines what additional attributes (or OIDs) are to be bound to the message under the digital signature. The attributes can include, for example, a transaction identifier, a signing party identifier, a system generated time stamp, a public key, or a uniform resource identifier query string.

The digital signature circuit616can accommodate and facilitate a wide variety of quantum-resistant digital signature methods to sign the original message. In some arrangements, the digital signature is achieved using SignedData CMS to generate a SignedData message. With SignedData, there is no need to send the actual certificate along in the message; instead, an attribute or other identifier can indicate which certificate the recipient needs to verify the signature.

The TSA computing system606includes a network interface circuit640and a time stamp circuit642. The TSA computing system606is managed by any trusted time authority that can provide a trusted time token for a piece of information or data entry. The trusted time authority can be one that complies with the X9.95 standard, or those defined in similar standards by ISO/IEC, IETF, and/or ETSI, and satisfies the legal and regulatory requirements. In some embodiments, the TSA computing system606may be contained in, and controlled by, the time-based digital signature computing system102. The TSA computing system606may include, for example, one or more servers each with one or more processors configured to execute instructions stored in a memory, send and receive data stored in the memory, and perform other operations to implement the compliance services described herein associated with the processing modules, databases, and processes shown.

The time-based digital signature computing system604includes a network interface circuit620, key and digital signature circuit622, TST circuit624, time-based message circuit626, aspect management circuit628, and a distributed repository618. The time-based digital signature computing system604is configured to receive signed data, generate time-based digital signature messages, monitor event changes, and update time-based digital signature messages. The network interface circuit620is structured to facilitate operative communication between the time-based digital signature computing system604and other systems and devices over the network610.

The key and digital signature circuit622is structured to verify the digital signature in a received signed data. In embodiments, where the time-based digital signature computing system604signs the time-based digital signature message, the key and digital signature circuit622facilitates digitally signing the time-based digital signature message. The key and digital signature circuit622may be structured to verify and/or sign a time-based digital signature message using the SignedData, detached SignedData, and SigncryptedData message schema, each of which provides unique functionality.

The TST circuit624is structured to communicate with the TSA computing system606to negotiate a trusted (e.g., recognized by regulators, auditors, members of the financial sector, etc. as a trustworthy time stamp) time stamp token for a piece of information. The TST circuit624is in communication with the time-based message circuit626to negotiate a trusted time stamp when an even occurs. Trusted time stamping provides authentication, integrity, and non-repudiation to the various data entries. In some arrangements, an information data entry is digitally signed by the generating entity (e.g., the time-based digital signature computing system604) before it is sent to the TSA computing system606. In some embodiments, the TST circuit624generates a hash of the information data entry using a hashing algorithm.

The TST circuit624submits the hash of the information data entry with a request to the TSA computing system606to generate a time stamp token. After submission of the request, the TST circuit624receives a trusted time stamp token from the TSA computing system606. The TST may include the hash of the information data entry and the time the hash of the information data entry was received by the TSA computing system606. The TST circuit624links the information data entry and the trusted time stamp token. The trusted TST allows a verifying entity to compare the hash of the information data entry to the information data entry to verify that they correspond to the same information and, because the TSA is trusted, that the information data entry was generated at the time indicated on the time stamp.

The time-based message circuit626is configured to receive, generate, and update the time-based digital signature messages. The time-based message circuit626is configured to generate a time-based digital signature message in a manner similar to the methods described inFIGS.1-4. In some embodiments, the time-based message circuit626is configured to implement SignedData with the time-based digital signature message. In those embodiments, certificates and/or other information related to the time-based digital signature message may be included in a value of a SignerInfo attribute for inclusion. The SignerInfo may include the public key identifier of the public key or certificate associated with the public/private key pair of the signed data and/or time-based digital signature message and the resulting signature value.

In some embodiments, the time-based message circuit626the time-based digital signature message is completed using the Abstract Syntax Notation One (“ASN.1”) type “SignedData.” In those arrangements, a cryptographic hash is used to create the time-based digital signature message on the content-to-be-signed and any associated attributes carried in type SignedData. The hash is calculated using the hash algorithm and parameters specified by the time-based digital signature computing system604, the content-to-be-signed, and any attributes that are to be cryptographically bound to the content. In some arrangements the TST is not part of the digital signature message. In other arrangements, the TST is included in “attributes” of the SignedData message. For example, both a SAML assertion and the TST could be included in the SignedData UnsignedAttributes field, as well as being cryptographically bound to the content. Alternatively, any SignedData content-to-be-signed (e.g., time-based digital signature message) can be “detached.” The detached content is such that the signature in the SignedData message is performed over the content-to-be-signed, but that signed content is not included in the SignedData message, thereby being detached. However, the content-to-be-signed must be available when the SignedData signature is verified, since the signature verification process requires computing the hash over the content-to-be-signed.

Additionally, certificates to support the key management techniques can be included in a time-based digital signature message using the typed SignedData. The certificates component of type SignedData is a value of type “Certificates,” which may contain a collection of one or more certificates. The certificates used in X9.73 are signed binary objects, whose digital signatures have been calculated over values encoded using the Distinguished Encoding Rules (“DER”) of ASN.1 using schema defined for these types in other standards. In order to verify the signatures on these objects, their original encodings must be maintained, but these values must also be represented in XML markup in a useful textual format. Consequently, the values in the certificates component of type Certificates have been Base64-armored to minimize their size when represented using XML markup while preserving their original encodings. The input to the Base64 processing is defined in this Standard as a Basic Encoding Rules (“BER”) encoded value of type SET OF CertificateChoices. Any combination of certificates, including X.509 certificates, attribute certificates and certificates supporting XML Advanced Electronic Signatures (“XAdES”) may be included in the Certificates type, and they may appear in any order.

The aspect management circuit628is structured to catalogue and identify the various aspects (e.g., digital signature schemas, cryptography, CRLs, etc.) of each signed data and/or time-based digital signature message in the distributed repository618. In some embodiments, the aspect management circuit628is configured to monitor the various aspects (e.g., digital signature schemas, cryptography, CRLs, etc.) of all signed data messages within the distributed repository618and transmit an event change and the event change information to the time-based message circuit626.

The distributed repository618is structured to store time-based digital signature messages that are needed to managed and protect in long-term retention. In some arrangements, the distributed repository618stores an event entry generated by the time-based digital signature computing system604. In some arrangements, the distributed repository618is a private blockchain.

The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.

It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”

As used herein, the term “circuit” may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (“IC”), discrete circuits, system on a chip (“SOCs”) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on.

The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor that, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (“ASICs”), field programmable gate arrays (“FPGAs”), digital signal processors (“DSPs”), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.

An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND,3D NAND, NOR,3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data that cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.

It should also be noted that the term “input devices,” as described herein, may include any type of input device including, but not limited to, video and audio recording devices, a keyboard, a keypad, a mouse, joystick, or other input devices performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices performing a similar function.

Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.

It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps, and decision steps.

The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions, and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.