Blockchain Fintech – Ahto Truu, Andres Kroonmaa, Michael GAULT, Jeffrey Pearce, Guardtime SA

Abstract for “Blockchain-supported, node ID-augmented digital record signature method”

“At least one of the nodes in a distributed haveh tree verification infrastructure is enhanced with an identifier for an entity in a registered path. Data signatures that include parameters for recomputation and identifiers of entities in a registration path will also contain data that identify at least one entity within the hash tree path. This data signature is associated with digital input records. A transaction in a blockchain is made when the hash tree verification infrastructure’s uppermost value is entered.

Background for “Blockchain-supported, node ID-augmented digital record signature method”

It has become more difficult to verify authenticity of documents in electronic form. Electronic documents are ubiquitous in modern commerce, law, government and banking. Electronic documents can be created, submitted and processed electronically. Notary seals, physical signatures and special papers, as well as other tools, are becoming less and less reliable.

“Perhaps the best way to confirm the authenticity of electronic documents at the moment is to use some type of digital signature to?sign. They are usually signed using some type of asymmetric cryptography. There are many different types of signing schemes that can be used to sign individual documents and groups of documents. The most popular data-signing method relies on some type of PKI (Public Key Infrastructure). The downside to PKI-based digital signing schemes is that keys can be compromised. Signatures made with that key cannot be trusted after it is known that it has been compromised. Signatures using keyed cryptography can be useful only for short-term purposes, as the probability of a key being compromised increases.

Another common method of verification is publication. This includes, but not necessarily, proof of a receipt order using a sequence value bound the digital record. Publishing is used to create a verifiable binding. The service provider usually publishes a digital file along with a sequence value in a well-witnessed way, such as in a newspaper. The published content can be considered certified by the service providers if it is bound to certain publication rules. The issue of key compromise is not an issue because no cryptographic keys were used in the publication process. The publication method is slow and not suitable for large document collections. Although publication is possible daily or weekly, instant certificate creation is not feasible, even though it is required by the modern electronic marketplace.

“Despite the fact that digital documents can be authenticated, no matter if the user is concerned about receipt order proof, the majority of existing methods have the grave flaw of requiring users to trust a service provider or a clock at some time. One or both of the two most common problems with known authentication schemes is that there must be a?trust authority? Or the systems are not scalable.

Guardtime AS, Tallinn, Estonia provides a distributed, keyless hash tree-based data signing infrastructure. It is currently referred to as the Keyless Signature Infrastructure. The KSI infrastructure is a robust, scalable verification system that doesn’t require a trusted authority, and does not rely on keys. Although such a distributed, hash tree-based infrastructure (Guardtime’s or otherwise) can verify the authenticity of a given document to a very high degree of certainty (especially Guardtime’s), in many cases it may be desirable to be able to verify not only the contents of a given document, but also to identify one or more of the entities involved in the original document-registration process.”

To understand ID augmentation of a verification network, you need to first understand the “bare” components. infrastructure to allow document authentication. To illustrate, we will first describe a keyless distributed hash tree-based infrastructure provided by Guardtime AS. Then, we’ll discuss two modifications to this infrastructure that enable verifiable identification for any or all entities involved in the registration of a document.

“FIGS. The Guardtime KSI infrastructure has several layers. FIGS. 1 and 2 show a client layer 2000 that contains a number client systems, a layer with gateways 3000, a layer that includes one or more aggregation system 4000, and an uppermost layer 5000 which includes a?core?. FIG. FIG.

“As FIG. 1 also illustrates, the core layer 5000 will in general be common to all users of the system and typically operated by a highest-level administrator/provider, whereas lower, subordinate layers 2000, 3000, 4000 will in many implementations have a unique configuration depending on the needs and preferences of users. What is the difference between core/common and unique/distributed? The distinction between?core/common? and?unique/distributed?” It is easy and quick, but in some cases, the core (that is, centrally managed system) will include structures and functions also used in lower levels. This infrastructure has the advantage of allowing for virtually unlimited scaling and reconfiguration of non-core layers to suit particular implementation requirements. It is enough that all the layers perform the required functions. There are common protocols to enter a digital record in the verification system, and generate registration requests.

“As FIG. “As FIG. 8 is functionally and FIG. A gateway is a server that an enterprise or third-party provider controls. This server may be known and possibly controlled by the organization of the client or be accessed via the Internet. A gateway can be defined as any server that is located in a particular location and capable of receiving requests from clients to register digital records. The gateway systems need not be the same type. One gateway could be a server in a company with many clients. Another gateway might be an online server that is accessible to arbitrary users. Gateways can also be commercial systems. Access to verify is only granted if a fee is paid.

“An aggregator within the aggregation layers 4000 will also be a computer system like a server that receives registration requests, again typically over a dedicated line or network, that have been consolidated (or?aggregated?). Gateways. Depending on the size and design requirements of an implementation, any aggregator can also be controlled or owned by the same system owners as the gateways or clients. In some cases, it may also be possible consolidate the gateways and aggregators for a particular client group.

“Example: Large corporations and government agencies might prefer to use the infrastructure’s benefits using their own systems. Another option is that all gateways and aggregaters could be configured using “cloud computing?” This would mean that the gateways and aggregators could all be configured using?cloud computing?. This infrastructure has the advantage that digital input records can be verified with almost total security even when users or others don’t know if they trust the systems in the gateway, aggregation layers 3, 4,000. In fact, trusting the administrator of core 5000 is not necessary in order to have virtually complete reliability in verification.

“The different terms ‘aggregator? Layer(s) 4000,?gateway? Layer(s) 3000 is not meant to imply that systems (such servers) within them are functionally different?a gateway?aggregates It could be considered a ‘local? service that serves the needs of clients. or ?lower level? an aggregator of its own. However, in many cases, gateways could be under the control entities that are more closely associated to clients. Aggregators will also be more closely linked with the overall system administrator who maintains the core. It is not an easy distinction to make.

“FIG. FIG. 2 illustrates the infrastructure of FIG. 1 in more detail. FIG. FIG. 2 shows various data structures that are used during authentication. FIG. FIG. . . 2010-n gateways are represented by 3010-1 and 3010-2. . . , 3010 -m; and two (by example only) aggregators, 4010-1,4010-k. An aggregater will usually communicate with each of the lowest-level hash tree nodes in the core. FIG. 2 shows only two aggregators. 2. For simplicity’s sake.

“In one implementation, every client system that wants to use the verification infrastructure has a software package loaded or internal routines for easy or even automatic communication and submission?upwards?” Digital information. Some software packages may contain an application program interface (API 2014) that converts digital records to a suitable form for processing. The API 2014 allows you to submit a digital record 2012 that has been created, selected or input in any other way. It then sends the API 2014 to a 2016 software module. This module uses the digital data from the 2012 record as at least one argument for a transformation function, such as a hash function.

“Cryptographic haveh functions are well-known in many areas in computer science. They are not discussed here. One example of a common class that can be used in this infrastructure is the?secure hash algorithm? family (SHA-1, SHA-2, etc.).”

“Additional hashing in the client might be desired to include additional data depending on the design protocol for the infrastructure. The system designer may choose to include additional arguments in the extra hash function 2016. These arguments could include an identifier for the person or entity that is requesting registration, an identification of the specific client system being used and a time indication. Other information might include information about the geographical location of the client, other systems, or any other information required to be included with the registration request. It is preferred to include a software module 2020 to transmit the output from the transformation 2016 to higher levels of the infrastructure as an request (REQ), together with any other parameters or data required to communicate with a gateway to initiate the registration request.

It is assumed that the 2016 transformation function is a hash function. This is because it is the most commonly used and efficient design choice and because many hash functions can be used within commodity computers in cryptology, security, and other areas. Another advantage of hash functions are their ability to reduce large amounts of digital information to an easier-to-process size, with a statistically small chance that two inputs will produce the same output. This means that many well-known hash function will be compatible with this infrastructure and can be selected using standard design considerations. However, the function that converts digital records into forms suitable for submission as a request does not need to be a haveh function. As long as its properties can be identified. It may be easier to send small amounts of digital records as-is, particularly for smaller ones. In this instance, the transformation function can be seen as an identity function that may add any additional information required by the core system administration in order to create a registration request.

The gateway 3010-2 illustrates the data structure of a binary tree. Each node at the lowest level will correspond to 2018’s transformed dataset. This request must also include any parameters or data that were used in the implementation. The values of each pair of nodes form inputs to a parent, which then calculates an output value. For example, a hash of two input values from its?children? nodes. Each combined output/hash value for each input is submitted to a?grandparent. Each output/hash value from the two inputs is then submitted to a?grandparent?.

“Aggregators like the system 4010-1 also include computation modules that calculate combined output values for each node in a hash-tree data structure. The gateways use the two?children’ to compute the value for each node of the aggregator data structure. nodes are used as inputs. The result of applying a hash function to the information in each client’s digital input records will be used by each aggregator to compute the highest combined output value. It is possible to control the aggregator layer 4000 from the same system administrator who is responsible for the core layer 5 000. The aggregation layers, gateway and client can be configured to use whatever architecture is preferred by different users as long as they adhere to the protocols and use the correct haveh functions.

“The core 5000 is managed and controlled by an overall system administrator in one embodiment. A core data structure that computes a hash tree using the lowest level inputs of each aggregator is created by the core. The core’s hash computations and structure form an aggregate of aggregation value. At each calendar time interval of t0, 1 and t1, the core will compute one current core hash value at tree node 5001. . . , tn. This is also known as the ‘calendar value? Or?current calendar value? The time interval. You can choose between granularity and time origin.

“Note: The root node at the top of the tree is 5001 and it represents the tree structure’s root node. This will change at the end the next period of accumulating request and generating signature vectors. containing recomputation parameters.”

“System designers will know that the various administrative and computational modules within clients, gateways and core contain computer-executable instruction. They can be stored, loaded, executed, and provided over a network to memory or other storage units. This includes downloading the code onto physical media like CD-ROM, other disks, optical or magnetic storage media or flash, or other RAM-based memories devices.

“In FIG. 2. Certain hash tree nodes of the gateway 3010-2 and the aggregator 4010-1 are marked with an “X?”. If one follows the tree paths upward starting at the 2018 value in client 2010-1, it’s possible to calculate every value up in the tree structures until the current core value 5001 given all the values in X-marked tree nosdes (siblings of nodes in direct recomputation path) as well as a knowledge about the hash functions that were applied to each parent node. If a digital record 2012 is signed with all the?X-marked?, then it will be deemed valid. If the digital record 2012 has a signature that includes all the?X marked values, then the hash function will be re-computation. However, only if the input value for the original digital records is identical in every way to the original. Any slight alteration to the digital output record, even one bit, in any value of the signature associated to record 2012, will result in a re-computed date value that is not identical with the one in node 5001. Also, each computed core value (the current calendar value) contains information derived from all digital input records that were input to the system during the current time period.

“FIG. “FIG. infrastructure whose hash trees node values contain information necessary for recomputed the hash-tree path all the way up to the top of system to the value at node 5001. Recomputation does not have to be performed in any gateway, aggregater, or core. In fact, recomputation can take place within the same client 2010-1 who originally submitted the verification request to the digital record 2012. The vector containing the sibling information is all that is required. Each level has its own tree value, and each hash function is used to calculate each parent node. This means that any third party could perform recomputations and compare them with node value 5001, and thus either authenticate any representation of the digital record 2012 or detect any differences.

“In FIG. “In FIG. If nodes are constructed in order of time, and order is important for the chosen hash function then sibling status at each level will be to the ‘right? Or?left? relevant to the hash structure. FIG. FIG. 3 shows not only the value, but also the order (0, 1, from left) in the vector (sibling Values 0-9 and order Bits). This vector is returned together with any other information as the data signature 8000. One advantage to using a binary tree structure is that at each level there will only be one sibling value for upward recomputation. A non-binary tree structure is possible but one would have to be willing to accept increased storage and computational complexity. Compare FIG. Comparing FIG. 3 and FIG. It is possible to increase the independence of the different layers?in particular clients and later entities who wish to perform authentication via recomputation?it would be advantageous to pass the entire calendar to the aggregators, and even to the lower levels, whenever a new calendar value, that is, at each end of each calendar time period, is computed. This allows for delegation and the distribution of the computational load without compromising the integrity of system. FIG. FIG. The number 6000 includes all calendar values starting at the beginning of system times. This would allow gateways and new aggregators to join the infrastructure without any administrative burden. It would also enable recomputation of digital records and authentication without the need to involve higher levels than the client-level entity that wishes to authenticate them.

“When core computes current calendar value 5001 at a new interval, it may return aggregator 4041-0 its sibling (X) lowest core value from aggregator 4010-k. The aggregator 410-1 can then return downwards X-marked haveh values to gateway 3010-2 which can in turn return downwards to client 2010-1 all the above plus the X -marked hash value computed within the gateway’s hash tree. The hash computation infrastructure may be distributed across multiple layers (vertically and?horizontally). Each layer can have its own responsibility, and the responsibility to communicate requests upwards and partial or complete signature vectors downwards can be shared. This can be done simultaneously at many locations. A data signature is unique to each digital record that it led to, so the procedure to return a signature vector 2012 for client 2010-1 (note: a client can input more than one digital file for verification at any given time interval) should be duplicated for all digital inputs records received during the time period over which node values 5001 were calculated.

“The distributed infrastructure as shown in FIG. 2. does not have to be static at all times. Each component below the core can be constructed asynchronously without affecting the others. All that is required to authenticate recomputation from a digital file up to the appropriate calendar value are the transformation function and any other values that were part of the original request, as well as the vector of sibling hash tree values and the knowledge of which hash function is to be used at each computation. The simplest scenario would be to use the same hash function at each level. The alternative would be to use the exact same hash function for all computations at a given level (within clients or within gateways), but this is more complex. With variation between levels. Others, however, may require more complex choices. This will be possible for those who are skilled in the art and science of hash function computations and data structures. The infrastructure will validate an input record as long as it knows the hash function for each computation.

“In most cases it is unlikely that the number clients in a given computation period will be exactly equal or greater than a power 2. Any method that is known can be used to adjust to the number of clients, while maintaining a binary tree structure. For all the missing?, it is possible to use known dummy values. sibling node values. Alternativly, the hash tree branches can be adjusted accordingly in the same way as giving?byes. “In single-elimination sporting tournaments.”

“In one embodiment, gateways 3000 might be closer to clients than aggregators. It would be possible, for example, to locate aggregators in various parts of the globe not only to spread the workload but also to increase throughput. It is not shown in FIGS. FIGS. 1-3 show that clients are associated to a particular gateway, and gateways with a specific aggregator. However, this is not necessary. Instead, clients could submit requests over a network and the first gateway to respond could then be associated for that authentication transaction. Requests from gateways can be submitted to open networks and processed by the aggregator that establishes the connection first. It is possible to distribute the workload more efficiently and reduce latency by finding aggregators or gateways in a logical and physical way. However, this may not be possible in all implementations. This could be done by entities like the government, defense contractors, and companies who want to keep strict security and tight control over the whole infrastructure. They could also control and specify the relationships between layers or subsets of infrastructure.

“Assume, now, by way of an example, that some entity later wishes verify that a particular digital record is in question?a?candidate?digital record? Is an identical copy to digital record 2012. The entity should use the same transformation function 2016 for the candidate digital records and then recompute upward using the corresponding data sign 8000. This will produce the exact same calendar value as the original digital record’s registration. This level of verification may be sufficient in some cases. One example: If the calendar is distributed to sufficient independent aggregators, then it is possible that one malicious actor could tamper or alter some calendar value. This could be detected by implementing a procedure to compare other copies of the calendar.

“Another example is that users might choose to rely on core administrator security in certain implementations. Government entities may implement systems in which the users can rely only on government administrators. Recomputations up to the calendar value could be sufficient authentication in these situations. This can be considered a?first-level’ authentication in the context of this infrastructure. verification. A government agency might require companies, laboratories, and other entities to submit a copy of their calendars. This is one example of how such a system could be implemented. Every time a company updates its calendar, it must submit a copy to the government. The government could then audit the company’s records, verify the authenticity of any digital record and recommit to the correct calendar value that the government will have kept. This would require the company to maintain a ‘calendar audit trail’. With the auditing entity (such government).

“Even in other cases, as long the system administrator at the highest level trusts its ability secure store calendars, it can be satisfied that a candidate’s digital record is genuine if the recomputation leads the stored calendar value to be updated. It would be the system administrator in these cases that seeks proof of authenticity of candidate digital files, rather than clients or third-party entities. The system administrator could therefore trust the security of the calendar values and recomputation to the same degree it trusts its ability to maintain the calendar copies.

“All other than the last digital record that requested registration within a given calendar time period, will need to wait until all other requests are processed before a calendar value can be made available to enable authenticating recomputation. This delay can be tolerated if the calendar time intervals are kept short. It is possible to add an option to allow clients to submit authentication registration requests to increase security. This would include the generation and return of the data signature vector as well as a key-based signed cert. These certificates could be issued by any higher level system, such the current gateway, aggregater, or core.

“FIG. “FIG. This is permanent verification without keys or trust from any entity. FIG. FIG. The composite calendar value may then be published in any medium 7000, such as a newspaper or online posting. The term “unchangeable” is used here. It means that even the most malicious actor, even if he is the core administrator, would find it impossible to alter any publicly available value. You don’t need to make the value?published? It is not necessary for the?published? to be in any media accessible to the public. However, this is one option that eliminates the need for a trusted authority. A large or closed organization might choose to keep a journal or database of the composite calendar values in a secure logical or physical location.

“Because the different data structures and procedures in the distributed infrastructure, the published Composite Calendar Value may encode information obtained form every input digital record during the entire publication period. If the current calendar value is hashed together, which it is with the previous one, then the next one is hashed with that before it. Each published composite calendar value will contain information from all digital records submitted for registration since the beginning of the calendar year. This ensures the integrity of the whole system. Any change to a digital record that was registered before the publication date will result in a different publication value. The new publication value would not match the original publication value. The composite signature value, or the publication value, is published. Once that is done, any signed digital certificate can be used to temporarily associate the composite value with the digital input record. However, one can use the data signature vector as well as the calendar values, which are stored in each of these aggregators to recompute hash value upward from any digital input records all the way up to the published value. If the digital input record used for such recomputation matches the published value, one can be sure within the level of certainty of the hash function that the digital input record being recomputed is identical to that which originally received the signature vector.

“FIG. “FIG.5” illustrates an optional extension to the signature vector that includes the values computed during the calculation of the publication value. As before, the?X?marked is used. Nodes are the sibling hash value for the digital record that corresponds to the REQ from client 2010. The X-marked value is sufficient to recompute calendar value marked ‘C?. However, the hash values in nodes marked ‘E? are required. FIG. 5 (in FIG. The core should preferably augment or extend the signature vectors at the end of the calendar year to include the?E. The extended signature vectors should be extended to include the?E? values and the corresponding order bits. Any party can verify authenticity of digital records with an extended signature. As long as the extended signature vector, the knowledge of the hash or other functions used and the publication value are all present, recomputation will result in a match. If not, it is possible to determine if something has been changed. Also, any order change at the time of receipt of any two digital input records can affect both the computed and published composite signature values.

“In FIG. In each publication time interval Tp, eight calendar values are displayed. This means that the number of publication time intervals Tp in each illustration is conveniently a power 2. This might not be the case in other implementations depending on which intervals are chosen. If a calendar value is generated every second but publication occurs only once a week (604,800 seconds), then there won’t be a power to 2 number of calendar values that are used as leaf nodes in the Merkle tree structure. This can be done in the same way as when you give?byes to other trees. In single-elimination sporting tournaments, adjust the tree branches by using a?dummy? inputs, etc.”

“While it is not always desirable or necessary for the published value encode information from the entire calendar starting at the beginning of the calendar time, there are other options that can be implemented provided the appropriate bookkeeping routines have been included. Instead of including all calendar values in Merkle tree, all the latest calendar values could be included in publication computations. This would also include a random sampling from calendar values from prior intervals. This would allow you to make sure that there are only 2 calendar values included.

In some cases, authorities may require evidence of records that go back less than three years in certain contexts. It might be beneficial to only include calendar values that were generated within the required time period so that relevant digital records can only be encoded in their most recent publication value.

“An alternative is to have only one computation of the publication value. This would include all calendar values starting at the beginning of system-time. This could be helpful, for instance, in projects that have clear time limits or digital records limits. In litigation and transactions, for example, parties frequently submit digital records to a “data room”. For easy exchange. The calendar values could be generated as in other cases, but perhaps with a longer time period since digital records are not submitted as often as they are in large-scale, accessible infrastructure implementations. However, only one computation of a publication price is required when all parties agree that the data room should be closed. This publication value could then be considered a?seal?. The body of digital records submitted could be used to verify and recomputation of any digital records ever submitted into the data space.”

“It’s not necessary that the publication value be calculated using the Merkle haveh tree data structure illustrated at FIG. 4. Another alternative is to have all the calendar values for the publication time interval concatenated, and then hashed together with a pseudorandom numbers, which becomes part of extended data signature vectors.

“It’s not necessary for all layers to use the same hash functions. Different client systems may use different transformation functions. The authentication process will function properly as long as all functions in the recomputation path can be identified by anyone later who wants to authenticate a digital file through recomputation. One way to allow future users to authenticate digital records through recomputation is to add a hash function identifier to the registration request.

The general verification infrastructure allows for the provable authentication and creation of documents. However, the data signature described does not identify which entities (such a gateway(s), which aggregater(s), etc.) took part in the document’s registration in the system. It is possible to verify a document with recomputation, provided that the hash functions are known at all nodes of the tree as well as the immediate children of each node. If the inputs to the hash function are not commutative, it is possible to determine the order of the documents (for example left, right), regardless of any specific information about the original computing entities.

“FIG. “FIG. In which all or at most some lower-level entities (in this example gateways 3010-1), are included. . . , 3010-m), each contain either a memory/storage or another component ID1, . . Dm and Dm respectively encode an entity identifier. The identifiers can be in a standard format or generated by each entity according its own conventions. As long as they are in the correct form, each identifier can be hashed together (for example, with the highest value) from the sub-hash tree within the entity. The value that is passed “upward” In other words, the value passed?upward? in the hash tree will be the sum of each entity and the entity directly above it in the tree hierarchy. This augmentation of the hash-tree computation with the ID?nodes results in? ID1, . . . Dm means that each document below the level of an entity’s hash tree will have a data signature that encodes the entity’s identifier. To verify each document, recomputation will require knowledge of ID1. . . , Dm. Dm. ”

“As FIG. “As FIG. . . Dm is preferred to be communicated to each entity higher up. This may include a storage element 4100 to keep track the identifiers for entities that?report. It is the?child? entity. entities. While not essential for document-verifying recomputations, it is often desirable for administrative or security reasons.

The identifier of each entity can be fixed for administrative ease. However, this is not required. An entity’s identifiers could be generated according to a schedule or by a generating function. They can also include a time marker or a time marker. As long as the identifier used for the computation of a particular data signature is known and associated to the entity at the time it was being used, this is possible. For identity validation purposes, the set of identifiers (which may be dependent on other designer-chosen parameters or time-varying) is then preferred to be kept in the parent entity.

It is not required that the component that generates or provides an identifier for an entity be a pure software component, such as a memory, storage location or output of a calculation module. The identifier of a gateway, for example, could be stored in a hardware security code 3012 (FIG. 8), such as a “token?” 8), such as a?token? This key would not be considered a ‘key? In the PKI sense, this key would not be a?key. The infrastructure would remain keyless in cryptographic terms. Instead, the hardware key would only function to input an identification. However, it is possible for the identifier to be a PKI sign; however, the infrastructure itself would not be dependent on any system or private/public keys. It is possible to include a HSM (hardware safety module) in the identifier that uses PKI-based signatures. This could require a password or other biometric authentication in order to be re-enabled following a reboot. This?externally? can be used regardless of the implementation. No matter what implementation is chosen, such an?externally? activate? activate?

“The identifier ID1. . . Dm could also refer to input that an operator enters via a keyboard, or another type of console 3011 (FIG. 8), which acts as an identifier password and participates in the highest hash operation of an entity. This identifier could encode information that identifies the hardware entity, such as the server that implements the gateway or aggregator, and other information. The identifier could also identify the person who activated the entity to participate in the hash tree infrastructure. Another entity may also provide an identifier for an entity, such as an entity’s parent (e.g. an aggregator to gateway or the overall system administrator for all members of the infrastructure). The configuration shown in FIG. 6 is also known as “self-ID augmentation”. The entity is the one that performs the hash computation.

“FIG. 7 illustrates an “assigned-ID enhancement?” An example of the hash-tree infrastructure. This embodiment assigns the parent the identifier of each child entity to which it is to be provided with one. FIG. 7 The identifiers ID1 and ID2 are used in FIG. . . Dm for gateways 3310-1, . . Their common aggregator 4010-1 assigns them the 3010-m. The aggregator (the parent) performs the hashing of each identifier with its respective uppermost value (the child entity in this illustration). The dashed arrows indicate that the parent entity can communicate the identifier of each entity to the entity. However, this would not be required to allow authenticating recomputation for digital records (candidate documents). Thus, in this embodiment, all entities up to the level that assigns identifiers may function as before, possibly not even aware that they are identified within the data signatures of digital records in whose computation/recomputation paths they lie. As a result of standard network protocols, at least the child entity’s network identity will be known by parent entities. Other techniques, such as servers or other known methods, may also be used to identify child entities over the network connection.

“Hash node augmentation can be illustrated in gateways or lowermost aggregators in FIGS. It can be implemented at any level and even at more than one. When an identifier is included in a data signing, it will encode one portion of the registration path in a hash tree for each digital record that the data signature is associated to. A data signature will contain more entity identifiers if more are added.

“The embodiments in FIGS. The Merkle is a combination of the calendar values for a given period. This creates a composite value which can be published in an unalterable medium. FIGS. FIGS. 9 and 10 show an embodiment where the?medium is? A data structure that is easily visible and can be tampered with without detection. A?blockchain’ is one example of such a data structure. 9000. Although the term “blockchain” is not widely accepted, Although the term?blockchain? and related terms do not have universally accepted definitions yet, a?blockchain’ is a data structure that contains a series of blocks bi. is a data structure that consists of a number of blocks bi, which are usually time-stamped. . . , bj, bj+1, bj+2, bj+3, . . . Each block contains data that corresponds to one or more transactions. The data is hashed together and linked data such as the hash output of the block immediately before it. This chain can be used to create the public ledger. It is usually an append-only database created by distributed consensus among multiple participants. The entry of data into a block in the chain is irrefutable. Any tampering would be reflected on the chained hash calculations, and thus can easily be detected.

The concept of a “blockchain” is a current topic of disagreement. The question of whether any entity can submit blocks to the blockchain and verify them is a matter of dispute. This may depend on meeting some proof-of work requirements (e.g. Bitcoin’s mining?). ) or whether entities that can submit to and verify the blocks in the datastructure must be authorized by a central authority. Also, it is not clear whether “blockchain” means “open?” By definition, ‘blockchain? implies?open? Or not. “Embodiments of this invention don’t presuppose, or require either definition.”

“In FIG. “In FIG. 9, the composite calendar value of each calendar period is entered using any appropriate mechanism. This could include proof-of-work or multi-entity consensus. In the case of open blockchains, trust will not be required for any entity, even if they present a newspaper copy or keep a database.

“Some blockchains require a non-trivial settlement period. An example is that a Bitcoin blockchain update may take up to ten minutes before it can be accepted. It may be more convenient to combine several calendar values into one transaction. As shown in FIG. 9, the composite calendar value that forms the root of Merkle tree in core 5000 is one way to accomplish this. 9 is a consolidation of multiple calendar values. The transaction submitted at each end of each period Tp may then be considered the composite value. According to the blockchain settlement time, the period Tp can be adjusted.”

“If the blockchain can be added quickly enough, it will be possible to submit each calendar data as a separate transaction on the blockchain. FIG. 10. These cases may be a good example of why a Merkle Tree to consolidate calendar value into a composite value is not necessary. In essence, the blockchain could fulfill the function of the calendar.

“Regardless of the value (each calendar or composite calendar) submitted as blockchain transactions signatures may be extended to include parameters identifying the transaction, that is block, in which the input’s calendar value was part. Given a purportedly true copy of the original input record, its corresponding signature, and this blockchain-identifying information, one would then be able to verify the signature up to the level of the calendar value, and onward to the blockchain, thereby totally verifying (or confirming alteration of) the input record.”

It is not necessary that node identifiers be static. However, in order to make it more difficult for malicious actors to pretend to be an aggregator or gateway, the node ID could be a combination of a static and digital identifiers. The identifier could, for example, be made a function time so that it changes according to a schedule or every calendar period. Another example is the identifier might be combined or consist of a nonce it receives from a core or another higher-level entity in a computation path after authorization (for instance, using a challenge response or other mechanism) for participation in signature-generating computations within a period such as the current calendar, publication period Tp, and so on.

Summary for “Blockchain-supported, node ID-augmented digital record signature method”

It has become more difficult to verify authenticity of documents in electronic form. Electronic documents are ubiquitous in modern commerce, law, government and banking. Electronic documents can be created, submitted and processed electronically. Notary seals, physical signatures and special papers, as well as other tools, are becoming less and less reliable.

“Perhaps the best way to confirm the authenticity of electronic documents at the moment is to use some type of digital signature to?sign. They are usually signed using some type of asymmetric cryptography. There are many different types of signing schemes that can be used to sign individual documents and groups of documents. The most popular data-signing method relies on some type of PKI (Public Key Infrastructure). The downside to PKI-based digital signing schemes is that keys can be compromised. Signatures made with that key cannot be trusted after it is known that it has been compromised. Signatures using keyed cryptography can be useful only for short-term purposes, as the probability of a key being compromised increases.

Another common method of verification is publication. This includes, but not necessarily, proof of a receipt order using a sequence value bound the digital record. Publishing is used to create a verifiable binding. The service provider usually publishes a digital file along with a sequence value in a well-witnessed way, such as in a newspaper. The published content can be considered certified by the service providers if it is bound to certain publication rules. The issue of key compromise is not an issue because no cryptographic keys were used in the publication process. The publication method is slow and not suitable for large document collections. Although publication is possible daily or weekly, instant certificate creation is not feasible, even though it is required by the modern electronic marketplace.

“Despite the fact that digital documents can be authenticated, no matter if the user is concerned about receipt order proof, the majority of existing methods have the grave flaw of requiring users to trust a service provider or a clock at some time. One or both of the two most common problems with known authentication schemes is that there must be a?trust authority? Or the systems are not scalable.

Guardtime AS, Tallinn, Estonia provides a distributed, keyless hash tree-based data signing infrastructure. It is currently referred to as the Keyless Signature Infrastructure. The KSI infrastructure is a robust, scalable verification system that doesn’t require a trusted authority, and does not rely on keys. Although such a distributed, hash tree-based infrastructure (Guardtime’s or otherwise) can verify the authenticity of a given document to a very high degree of certainty (especially Guardtime’s), in many cases it may be desirable to be able to verify not only the contents of a given document, but also to identify one or more of the entities involved in the original document-registration process.”

To understand ID augmentation of a verification network, you need to first understand the “bare” components. infrastructure to allow document authentication. To illustrate, we will first describe a keyless distributed hash tree-based infrastructure provided by Guardtime AS. Then, we’ll discuss two modifications to this infrastructure that enable verifiable identification for any or all entities involved in the registration of a document.

“FIGS. The Guardtime KSI infrastructure has several layers. FIGS. 1 and 2 show a client layer 2000 that contains a number client systems, a layer with gateways 3000, a layer that includes one or more aggregation system 4000, and an uppermost layer 5000 which includes a?core?. FIG. FIG.

“As FIG. 1 also illustrates, the core layer 5000 will in general be common to all users of the system and typically operated by a highest-level administrator/provider, whereas lower, subordinate layers 2000, 3000, 4000 will in many implementations have a unique configuration depending on the needs and preferences of users. What is the difference between core/common and unique/distributed? The distinction between?core/common? and?unique/distributed?” It is easy and quick, but in some cases, the core (that is, centrally managed system) will include structures and functions also used in lower levels. This infrastructure has the advantage of allowing for virtually unlimited scaling and reconfiguration of non-core layers to suit particular implementation requirements. It is enough that all the layers perform the required functions. There are common protocols to enter a digital record in the verification system, and generate registration requests.

“As FIG. “As FIG. 8 is functionally and FIG. A gateway is a server that an enterprise or third-party provider controls. This server may be known and possibly controlled by the organization of the client or be accessed via the Internet. A gateway can be defined as any server that is located in a particular location and capable of receiving requests from clients to register digital records. The gateway systems need not be the same type. One gateway could be a server in a company with many clients. Another gateway might be an online server that is accessible to arbitrary users. Gateways can also be commercial systems. Access to verify is only granted if a fee is paid.

“An aggregator within the aggregation layers 4000 will also be a computer system like a server that receives registration requests, again typically over a dedicated line or network, that have been consolidated (or?aggregated?). Gateways. Depending on the size and design requirements of an implementation, any aggregator can also be controlled or owned by the same system owners as the gateways or clients. In some cases, it may also be possible consolidate the gateways and aggregators for a particular client group.

“Example: Large corporations and government agencies might prefer to use the infrastructure’s benefits using their own systems. Another option is that all gateways and aggregaters could be configured using “cloud computing?” This would mean that the gateways and aggregators could all be configured using?cloud computing?. This infrastructure has the advantage that digital input records can be verified with almost total security even when users or others don’t know if they trust the systems in the gateway, aggregation layers 3, 4,000. In fact, trusting the administrator of core 5000 is not necessary in order to have virtually complete reliability in verification.

“The different terms ‘aggregator? Layer(s) 4000,?gateway? Layer(s) 3000 is not meant to imply that systems (such servers) within them are functionally different?a gateway?aggregates It could be considered a ‘local? service that serves the needs of clients. or ?lower level? an aggregator of its own. However, in many cases, gateways could be under the control entities that are more closely associated to clients. Aggregators will also be more closely linked with the overall system administrator who maintains the core. It is not an easy distinction to make.

“FIG. FIG. 2 illustrates the infrastructure of FIG. 1 in more detail. FIG. FIG. 2 shows various data structures that are used during authentication. FIG. FIG. . . 2010-n gateways are represented by 3010-1 and 3010-2. . . , 3010 -m; and two (by example only) aggregators, 4010-1,4010-k. An aggregater will usually communicate with each of the lowest-level hash tree nodes in the core. FIG. 2 shows only two aggregators. 2. For simplicity’s sake.

“In one implementation, every client system that wants to use the verification infrastructure has a software package loaded or internal routines for easy or even automatic communication and submission?upwards?” Digital information. Some software packages may contain an application program interface (API 2014) that converts digital records to a suitable form for processing. The API 2014 allows you to submit a digital record 2012 that has been created, selected or input in any other way. It then sends the API 2014 to a 2016 software module. This module uses the digital data from the 2012 record as at least one argument for a transformation function, such as a hash function.

“Cryptographic haveh functions are well-known in many areas in computer science. They are not discussed here. One example of a common class that can be used in this infrastructure is the?secure hash algorithm? family (SHA-1, SHA-2, etc.).”

“Additional hashing in the client might be desired to include additional data depending on the design protocol for the infrastructure. The system designer may choose to include additional arguments in the extra hash function 2016. These arguments could include an identifier for the person or entity that is requesting registration, an identification of the specific client system being used and a time indication. Other information might include information about the geographical location of the client, other systems, or any other information required to be included with the registration request. It is preferred to include a software module 2020 to transmit the output from the transformation 2016 to higher levels of the infrastructure as an request (REQ), together with any other parameters or data required to communicate with a gateway to initiate the registration request.

It is assumed that the 2016 transformation function is a hash function. This is because it is the most commonly used and efficient design choice and because many hash functions can be used within commodity computers in cryptology, security, and other areas. Another advantage of hash functions are their ability to reduce large amounts of digital information to an easier-to-process size, with a statistically small chance that two inputs will produce the same output. This means that many well-known hash function will be compatible with this infrastructure and can be selected using standard design considerations. However, the function that converts digital records into forms suitable for submission as a request does not need to be a haveh function. As long as its properties can be identified. It may be easier to send small amounts of digital records as-is, particularly for smaller ones. In this instance, the transformation function can be seen as an identity function that may add any additional information required by the core system administration in order to create a registration request.

The gateway 3010-2 illustrates the data structure of a binary tree. Each node at the lowest level will correspond to 2018’s transformed dataset. This request must also include any parameters or data that were used in the implementation. The values of each pair of nodes form inputs to a parent, which then calculates an output value. For example, a hash of two input values from its?children? nodes. Each combined output/hash value for each input is submitted to a?grandparent. Each output/hash value from the two inputs is then submitted to a?grandparent?.

“Aggregators like the system 4010-1 also include computation modules that calculate combined output values for each node in a hash-tree data structure. The gateways use the two?children’ to compute the value for each node of the aggregator data structure. nodes are used as inputs. The result of applying a hash function to the information in each client’s digital input records will be used by each aggregator to compute the highest combined output value. It is possible to control the aggregator layer 4000 from the same system administrator who is responsible for the core layer 5 000. The aggregation layers, gateway and client can be configured to use whatever architecture is preferred by different users as long as they adhere to the protocols and use the correct haveh functions.

“The core 5000 is managed and controlled by an overall system administrator in one embodiment. A core data structure that computes a hash tree using the lowest level inputs of each aggregator is created by the core. The core’s hash computations and structure form an aggregate of aggregation value. At each calendar time interval of t0, 1 and t1, the core will compute one current core hash value at tree node 5001. . . , tn. This is also known as the ‘calendar value? Or?current calendar value? The time interval. You can choose between granularity and time origin.

“Note: The root node at the top of the tree is 5001 and it represents the tree structure’s root node. This will change at the end the next period of accumulating request and generating signature vectors. containing recomputation parameters.”

“System designers will know that the various administrative and computational modules within clients, gateways and core contain computer-executable instruction. They can be stored, loaded, executed, and provided over a network to memory or other storage units. This includes downloading the code onto physical media like CD-ROM, other disks, optical or magnetic storage media or flash, or other RAM-based memories devices.

“In FIG. 2. Certain hash tree nodes of the gateway 3010-2 and the aggregator 4010-1 are marked with an “X?”. If one follows the tree paths upward starting at the 2018 value in client 2010-1, it’s possible to calculate every value up in the tree structures until the current core value 5001 given all the values in X-marked tree nosdes (siblings of nodes in direct recomputation path) as well as a knowledge about the hash functions that were applied to each parent node. If a digital record 2012 is signed with all the?X-marked?, then it will be deemed valid. If the digital record 2012 has a signature that includes all the?X marked values, then the hash function will be re-computation. However, only if the input value for the original digital records is identical in every way to the original. Any slight alteration to the digital output record, even one bit, in any value of the signature associated to record 2012, will result in a re-computed date value that is not identical with the one in node 5001. Also, each computed core value (the current calendar value) contains information derived from all digital input records that were input to the system during the current time period.

“FIG. “FIG. infrastructure whose hash trees node values contain information necessary for recomputed the hash-tree path all the way up to the top of system to the value at node 5001. Recomputation does not have to be performed in any gateway, aggregater, or core. In fact, recomputation can take place within the same client 2010-1 who originally submitted the verification request to the digital record 2012. The vector containing the sibling information is all that is required. Each level has its own tree value, and each hash function is used to calculate each parent node. This means that any third party could perform recomputations and compare them with node value 5001, and thus either authenticate any representation of the digital record 2012 or detect any differences.

“In FIG. “In FIG. If nodes are constructed in order of time, and order is important for the chosen hash function then sibling status at each level will be to the ‘right? Or?left? relevant to the hash structure. FIG. FIG. 3 shows not only the value, but also the order (0, 1, from left) in the vector (sibling Values 0-9 and order Bits). This vector is returned together with any other information as the data signature 8000. One advantage to using a binary tree structure is that at each level there will only be one sibling value for upward recomputation. A non-binary tree structure is possible but one would have to be willing to accept increased storage and computational complexity. Compare FIG. Comparing FIG. 3 and FIG. It is possible to increase the independence of the different layers?in particular clients and later entities who wish to perform authentication via recomputation?it would be advantageous to pass the entire calendar to the aggregators, and even to the lower levels, whenever a new calendar value, that is, at each end of each calendar time period, is computed. This allows for delegation and the distribution of the computational load without compromising the integrity of system. FIG. FIG. The number 6000 includes all calendar values starting at the beginning of system times. This would allow gateways and new aggregators to join the infrastructure without any administrative burden. It would also enable recomputation of digital records and authentication without the need to involve higher levels than the client-level entity that wishes to authenticate them.

“When core computes current calendar value 5001 at a new interval, it may return aggregator 4041-0 its sibling (X) lowest core value from aggregator 4010-k. The aggregator 410-1 can then return downwards X-marked haveh values to gateway 3010-2 which can in turn return downwards to client 2010-1 all the above plus the X -marked hash value computed within the gateway’s hash tree. The hash computation infrastructure may be distributed across multiple layers (vertically and?horizontally). Each layer can have its own responsibility, and the responsibility to communicate requests upwards and partial or complete signature vectors downwards can be shared. This can be done simultaneously at many locations. A data signature is unique to each digital record that it led to, so the procedure to return a signature vector 2012 for client 2010-1 (note: a client can input more than one digital file for verification at any given time interval) should be duplicated for all digital inputs records received during the time period over which node values 5001 were calculated.

“The distributed infrastructure as shown in FIG. 2. does not have to be static at all times. Each component below the core can be constructed asynchronously without affecting the others. All that is required to authenticate recomputation from a digital file up to the appropriate calendar value are the transformation function and any other values that were part of the original request, as well as the vector of sibling hash tree values and the knowledge of which hash function is to be used at each computation. The simplest scenario would be to use the same hash function at each level. The alternative would be to use the exact same hash function for all computations at a given level (within clients or within gateways), but this is more complex. With variation between levels. Others, however, may require more complex choices. This will be possible for those who are skilled in the art and science of hash function computations and data structures. The infrastructure will validate an input record as long as it knows the hash function for each computation.

“In most cases it is unlikely that the number clients in a given computation period will be exactly equal or greater than a power 2. Any method that is known can be used to adjust to the number of clients, while maintaining a binary tree structure. For all the missing?, it is possible to use known dummy values. sibling node values. Alternativly, the hash tree branches can be adjusted accordingly in the same way as giving?byes. “In single-elimination sporting tournaments.”

“In one embodiment, gateways 3000 might be closer to clients than aggregators. It would be possible, for example, to locate aggregators in various parts of the globe not only to spread the workload but also to increase throughput. It is not shown in FIGS. FIGS. 1-3 show that clients are associated to a particular gateway, and gateways with a specific aggregator. However, this is not necessary. Instead, clients could submit requests over a network and the first gateway to respond could then be associated for that authentication transaction. Requests from gateways can be submitted to open networks and processed by the aggregator that establishes the connection first. It is possible to distribute the workload more efficiently and reduce latency by finding aggregators or gateways in a logical and physical way. However, this may not be possible in all implementations. This could be done by entities like the government, defense contractors, and companies who want to keep strict security and tight control over the whole infrastructure. They could also control and specify the relationships between layers or subsets of infrastructure.

“Assume, now, by way of an example, that some entity later wishes verify that a particular digital record is in question?a?candidate?digital record? Is an identical copy to digital record 2012. The entity should use the same transformation function 2016 for the candidate digital records and then recompute upward using the corresponding data sign 8000. This will produce the exact same calendar value as the original digital record’s registration. This level of verification may be sufficient in some cases. One example: If the calendar is distributed to sufficient independent aggregators, then it is possible that one malicious actor could tamper or alter some calendar value. This could be detected by implementing a procedure to compare other copies of the calendar.

“Another example is that users might choose to rely on core administrator security in certain implementations. Government entities may implement systems in which the users can rely only on government administrators. Recomputations up to the calendar value could be sufficient authentication in these situations. This can be considered a?first-level’ authentication in the context of this infrastructure. verification. A government agency might require companies, laboratories, and other entities to submit a copy of their calendars. This is one example of how such a system could be implemented. Every time a company updates its calendar, it must submit a copy to the government. The government could then audit the company’s records, verify the authenticity of any digital record and recommit to the correct calendar value that the government will have kept. This would require the company to maintain a ‘calendar audit trail’. With the auditing entity (such government).

“Even in other cases, as long the system administrator at the highest level trusts its ability secure store calendars, it can be satisfied that a candidate’s digital record is genuine if the recomputation leads the stored calendar value to be updated. It would be the system administrator in these cases that seeks proof of authenticity of candidate digital files, rather than clients or third-party entities. The system administrator could therefore trust the security of the calendar values and recomputation to the same degree it trusts its ability to maintain the calendar copies.

“All other than the last digital record that requested registration within a given calendar time period, will need to wait until all other requests are processed before a calendar value can be made available to enable authenticating recomputation. This delay can be tolerated if the calendar time intervals are kept short. It is possible to add an option to allow clients to submit authentication registration requests to increase security. This would include the generation and return of the data signature vector as well as a key-based signed cert. These certificates could be issued by any higher level system, such the current gateway, aggregater, or core.

“FIG. “FIG. This is permanent verification without keys or trust from any entity. FIG. FIG. The composite calendar value may then be published in any medium 7000, such as a newspaper or online posting. The term “unchangeable” is used here. It means that even the most malicious actor, even if he is the core administrator, would find it impossible to alter any publicly available value. You don’t need to make the value?published? It is not necessary for the?published? to be in any media accessible to the public. However, this is one option that eliminates the need for a trusted authority. A large or closed organization might choose to keep a journal or database of the composite calendar values in a secure logical or physical location.

“Because the different data structures and procedures in the distributed infrastructure, the published Composite Calendar Value may encode information obtained form every input digital record during the entire publication period. If the current calendar value is hashed together, which it is with the previous one, then the next one is hashed with that before it. Each published composite calendar value will contain information from all digital records submitted for registration since the beginning of the calendar year. This ensures the integrity of the whole system. Any change to a digital record that was registered before the publication date will result in a different publication value. The new publication value would not match the original publication value. The composite signature value, or the publication value, is published. Once that is done, any signed digital certificate can be used to temporarily associate the composite value with the digital input record. However, one can use the data signature vector as well as the calendar values, which are stored in each of these aggregators to recompute hash value upward from any digital input records all the way up to the published value. If the digital input record used for such recomputation matches the published value, one can be sure within the level of certainty of the hash function that the digital input record being recomputed is identical to that which originally received the signature vector.

“FIG. “FIG.5” illustrates an optional extension to the signature vector that includes the values computed during the calculation of the publication value. As before, the?X?marked is used. Nodes are the sibling hash value for the digital record that corresponds to the REQ from client 2010. The X-marked value is sufficient to recompute calendar value marked ‘C?. However, the hash values in nodes marked ‘E? are required. FIG. 5 (in FIG. The core should preferably augment or extend the signature vectors at the end of the calendar year to include the?E. The extended signature vectors should be extended to include the?E? values and the corresponding order bits. Any party can verify authenticity of digital records with an extended signature. As long as the extended signature vector, the knowledge of the hash or other functions used and the publication value are all present, recomputation will result in a match. If not, it is possible to determine if something has been changed. Also, any order change at the time of receipt of any two digital input records can affect both the computed and published composite signature values.

“In FIG. In each publication time interval Tp, eight calendar values are displayed. This means that the number of publication time intervals Tp in each illustration is conveniently a power 2. This might not be the case in other implementations depending on which intervals are chosen. If a calendar value is generated every second but publication occurs only once a week (604,800 seconds), then there won’t be a power to 2 number of calendar values that are used as leaf nodes in the Merkle tree structure. This can be done in the same way as when you give?byes to other trees. In single-elimination sporting tournaments, adjust the tree branches by using a?dummy? inputs, etc.”

“While it is not always desirable or necessary for the published value encode information from the entire calendar starting at the beginning of the calendar time, there are other options that can be implemented provided the appropriate bookkeeping routines have been included. Instead of including all calendar values in Merkle tree, all the latest calendar values could be included in publication computations. This would also include a random sampling from calendar values from prior intervals. This would allow you to make sure that there are only 2 calendar values included.

In some cases, authorities may require evidence of records that go back less than three years in certain contexts. It might be beneficial to only include calendar values that were generated within the required time period so that relevant digital records can only be encoded in their most recent publication value.

“An alternative is to have only one computation of the publication value. This would include all calendar values starting at the beginning of system-time. This could be helpful, for instance, in projects that have clear time limits or digital records limits. In litigation and transactions, for example, parties frequently submit digital records to a “data room”. For easy exchange. The calendar values could be generated as in other cases, but perhaps with a longer time period since digital records are not submitted as often as they are in large-scale, accessible infrastructure implementations. However, only one computation of a publication price is required when all parties agree that the data room should be closed. This publication value could then be considered a?seal?. The body of digital records submitted could be used to verify and recomputation of any digital records ever submitted into the data space.”

“It’s not necessary that the publication value be calculated using the Merkle haveh tree data structure illustrated at FIG. 4. Another alternative is to have all the calendar values for the publication time interval concatenated, and then hashed together with a pseudorandom numbers, which becomes part of extended data signature vectors.

“It’s not necessary for all layers to use the same hash functions. Different client systems may use different transformation functions. The authentication process will function properly as long as all functions in the recomputation path can be identified by anyone later who wants to authenticate a digital file through recomputation. One way to allow future users to authenticate digital records through recomputation is to add a hash function identifier to the registration request.

The general verification infrastructure allows for the provable authentication and creation of documents. However, the data signature described does not identify which entities (such a gateway(s), which aggregater(s), etc.) took part in the document’s registration in the system. It is possible to verify a document with recomputation, provided that the hash functions are known at all nodes of the tree as well as the immediate children of each node. If the inputs to the hash function are not commutative, it is possible to determine the order of the documents (for example left, right), regardless of any specific information about the original computing entities.

“FIG. “FIG. In which all or at most some lower-level entities (in this example gateways 3010-1), are included. . . , 3010-m), each contain either a memory/storage or another component ID1, . . Dm and Dm respectively encode an entity identifier. The identifiers can be in a standard format or generated by each entity according its own conventions. As long as they are in the correct form, each identifier can be hashed together (for example, with the highest value) from the sub-hash tree within the entity. The value that is passed “upward” In other words, the value passed?upward? in the hash tree will be the sum of each entity and the entity directly above it in the tree hierarchy. This augmentation of the hash-tree computation with the ID?nodes results in? ID1, . . . Dm means that each document below the level of an entity’s hash tree will have a data signature that encodes the entity’s identifier. To verify each document, recomputation will require knowledge of ID1. . . , Dm. Dm. ”

“As FIG. “As FIG. . . Dm is preferred to be communicated to each entity higher up. This may include a storage element 4100 to keep track the identifiers for entities that?report. It is the?child? entity. entities. While not essential for document-verifying recomputations, it is often desirable for administrative or security reasons.

The identifier of each entity can be fixed for administrative ease. However, this is not required. An entity’s identifiers could be generated according to a schedule or by a generating function. They can also include a time marker or a time marker. As long as the identifier used for the computation of a particular data signature is known and associated to the entity at the time it was being used, this is possible. For identity validation purposes, the set of identifiers (which may be dependent on other designer-chosen parameters or time-varying) is then preferred to be kept in the parent entity.

It is not required that the component that generates or provides an identifier for an entity be a pure software component, such as a memory, storage location or output of a calculation module. The identifier of a gateway, for example, could be stored in a hardware security code 3012 (FIG. 8), such as a “token?” 8), such as a?token? This key would not be considered a ‘key? In the PKI sense, this key would not be a?key. The infrastructure would remain keyless in cryptographic terms. Instead, the hardware key would only function to input an identification. However, it is possible for the identifier to be a PKI sign; however, the infrastructure itself would not be dependent on any system or private/public keys. It is possible to include a HSM (hardware safety module) in the identifier that uses PKI-based signatures. This could require a password or other biometric authentication in order to be re-enabled following a reboot. This?externally? can be used regardless of the implementation. No matter what implementation is chosen, such an?externally? activate? activate?

“The identifier ID1. . . Dm could also refer to input that an operator enters via a keyboard, or another type of console 3011 (FIG. 8), which acts as an identifier password and participates in the highest hash operation of an entity. This identifier could encode information that identifies the hardware entity, such as the server that implements the gateway or aggregator, and other information. The identifier could also identify the person who activated the entity to participate in the hash tree infrastructure. Another entity may also provide an identifier for an entity, such as an entity’s parent (e.g. an aggregator to gateway or the overall system administrator for all members of the infrastructure). The configuration shown in FIG. 6 is also known as “self-ID augmentation”. The entity is the one that performs the hash computation.

“FIG. 7 illustrates an “assigned-ID enhancement?” An example of the hash-tree infrastructure. This embodiment assigns the parent the identifier of each child entity to which it is to be provided with one. FIG. 7 The identifiers ID1 and ID2 are used in FIG. . . Dm for gateways 3310-1, . . Their common aggregator 4010-1 assigns them the 3010-m. The aggregator (the parent) performs the hashing of each identifier with its respective uppermost value (the child entity in this illustration). The dashed arrows indicate that the parent entity can communicate the identifier of each entity to the entity. However, this would not be required to allow authenticating recomputation for digital records (candidate documents). Thus, in this embodiment, all entities up to the level that assigns identifiers may function as before, possibly not even aware that they are identified within the data signatures of digital records in whose computation/recomputation paths they lie. As a result of standard network protocols, at least the child entity’s network identity will be known by parent entities. Other techniques, such as servers or other known methods, may also be used to identify child entities over the network connection.

“Hash node augmentation can be illustrated in gateways or lowermost aggregators in FIGS. It can be implemented at any level and even at more than one. When an identifier is included in a data signing, it will encode one portion of the registration path in a hash tree for each digital record that the data signature is associated to. A data signature will contain more entity identifiers if more are added.

“The embodiments in FIGS. The Merkle is a combination of the calendar values for a given period. This creates a composite value which can be published in an unalterable medium. FIGS. FIGS. 9 and 10 show an embodiment where the?medium is? A data structure that is easily visible and can be tampered with without detection. A?blockchain’ is one example of such a data structure. 9000. Although the term “blockchain” is not widely accepted, Although the term?blockchain? and related terms do not have universally accepted definitions yet, a?blockchain’ is a data structure that contains a series of blocks bi. is a data structure that consists of a number of blocks bi, which are usually time-stamped. . . , bj, bj+1, bj+2, bj+3, . . . Each block contains data that corresponds to one or more transactions. The data is hashed together and linked data such as the hash output of the block immediately before it. This chain can be used to create the public ledger. It is usually an append-only database created by distributed consensus among multiple participants. The entry of data into a block in the chain is irrefutable. Any tampering would be reflected on the chained hash calculations, and thus can easily be detected.

The concept of a “blockchain” is a current topic of disagreement. The question of whether any entity can submit blocks to the blockchain and verify them is a matter of dispute. This may depend on meeting some proof-of work requirements (e.g. Bitcoin’s mining?). ) or whether entities that can submit to and verify the blocks in the datastructure must be authorized by a central authority. Also, it is not clear whether “blockchain” means “open?” By definition, ‘blockchain? implies?open? Or not. “Embodiments of this invention don’t presuppose, or require either definition.”

“In FIG. “In FIG. 9, the composite calendar value of each calendar period is entered using any appropriate mechanism. This could include proof-of-work or multi-entity consensus. In the case of open blockchains, trust will not be required for any entity, even if they present a newspaper copy or keep a database.

“Some blockchains require a non-trivial settlement period. An example is that a Bitcoin blockchain update may take up to ten minutes before it can be accepted. It may be more convenient to combine several calendar values into one transaction. As shown in FIG. 9, the composite calendar value that forms the root of Merkle tree in core 5000 is one way to accomplish this. 9 is a consolidation of multiple calendar values. The transaction submitted at each end of each period Tp may then be considered the composite value. According to the blockchain settlement time, the period Tp can be adjusted.”

“If the blockchain can be added quickly enough, it will be possible to submit each calendar data as a separate transaction on the blockchain. FIG. 10. These cases may be a good example of why a Merkle Tree to consolidate calendar value into a composite value is not necessary. In essence, the blockchain could fulfill the function of the calendar.

“Regardless of the value (each calendar or composite calendar) submitted as blockchain transactions signatures may be extended to include parameters identifying the transaction, that is block, in which the input’s calendar value was part. Given a purportedly true copy of the original input record, its corresponding signature, and this blockchain-identifying information, one would then be able to verify the signature up to the level of the calendar value, and onward to the blockchain, thereby totally verifying (or confirming alteration of) the input record.”

It is not necessary that node identifiers be static. However, in order to make it more difficult for malicious actors to pretend to be an aggregator or gateway, the node ID could be a combination of a static and digital identifiers. The identifier could, for example, be made a function time so that it changes according to a schedule or every calendar period. Another example is the identifier might be combined or consist of a nonce it receives from a core or another higher-level entity in a computation path after authorization (for instance, using a challenge response or other mechanism) for participation in signature-generating computations within a period such as the current calendar, publication period Tp, and so on.

Click here to view the patent on Google Patents.

How to Search for Patents

A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.

Are you interested in similar patents? These are the steps to follow:

1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.

Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.

Use the questions below to help you identify keywords or concepts.

  • What is the purpose of the invention Is it a utilitarian device or an ornamental design?
  • Is invention a way to create something or perform a function? Is it a product?
  • What is the composition and function of the invention? What is the physical composition of the invention?
  • What’s the purpose of the invention
  • What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.

2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.

3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.

4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.

5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.

6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.

7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:

  • Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
  • Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
  • Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.

To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.

Download patent guide file – Click here