Blockchain Fintech – Andres Kroonmaa, Ahto Buldas, Jeffrey Pearce, Guardtime SA
Abstract for “Blockchain-supported, fail-safe synchronization in a data authentication infrastructure”
“A distributed hash-tree-based authentication system for digital in-records has more than one core node. Each receives at most one value from aggregators. The nodes communicate with each other about the aggregator values that they have received and try to agree on which values should be included within duplicated intra-node evaluations to create a consistent top level value to use as the basis of digital signatures associated to the digital input records. The top-level value can then be entered directly or in combination with other top level values over a period into a block of blockchain.
Background for “Blockchain-supported, fail-safe synchronization in a data authentication infrastructure”
It has become more difficult to verify digital data authenticity in an electronic age, but it is also more important. Electronic documents (which can be defined broadly as any type of digital information) 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 certificate to?sign’ them. They are usually generated using some type of asymmetric cryptography. The speed of public key cryptography allows for almost instantaneous certificate generation. Asymmetric cryptography can be used to create digital signatures, but there is a weakness: Cryptographic signature keys could become compromised. The certificates that were created using that key can no longer be verified if the key is compromised. Certificates created using keyed cryptography can only be used for a limited time because the probability of a key being compromised increases.
Key-based systems also have other drawbacks. It becomes difficult to track sometimes large numbers of keys and whether or not they are valid.
“Most common systems treat every digital record as an independent entity, unrelated to any others” keys are generated for each record and security is dependent on this key set. Information associated with records will not reflect anything that has happened to another record or any other time. Without an individual user being aware, entire systems could be compromised.”
Other systems can increase verifiability by using information from multiple records at once to calculate a composite higher-level value that can help detect unauthorised changes to any records. A tree structure of hash value (for example, Merkle tree structure), can be used to create a single highest level verification value. This means that any change to one record will result in a different highest-level value after recomputation, which will indicate that there has been a change.
“When it comes verifying digital documents’ authenticity, no matter how much the user cares about proofs of receipt order, all existing methods have the serious flaw of requiring that the users trust the service provider. This means that even if a verification scheme is theoretically reliable, the user must trust the entity performing the verification. Although trust in such systems can sometimes be unfounded, it is still a cause for concern. For example, in 2007, it was discovered that the BSAFE cryptographic libraries of RSA Security (a major provider cryptographic technologies) used DUAL_EC_DRBG random numbers generator as a default. This included a?backdoor? This was due to the use of a set U.S. National Security Agency initiating numbers. Even with the most sophisticated keys, it is still difficult to trust the keymaker.
Publishing a digital record with verifying information is an alternative to relying on keys. This may avoid the need for such trust, but a pure publication-verification scheme is unsuitable for large collections of documents that each may need authentication. One or both of the two problems that are common to known authentication schemes is that there must be a?trust authority? Or the systems aren’t scalable enough.
Guardtime AS, Tallinn, Estonia provides a distributed hash tree-based data verification system that does away with keys, is highly scalable and can be used independently relying on only mathematical procedures that are available to everyone.
“FIGS. “FIGS. Sets of digital data (or?digital records?) or ?digital records?) are input by a group of low-level systems, which includes clients 2000. A hash function transforms the digital data and returns a hash value. The client-level hash value is used to create a node in a global haveh tree. It then hashes in successively higher levels of gateways 3000. These nodes then hash each other’s nodes in their respective internal hash tree structure to form inputs for aggregators 4000. In turn, the aggregators hash their input nodes within a tree structure to create highest-level aggregator values. These inputs are then submitted to input nodes in core system 5000 which hash at least the current set input node values together in order to form a root value that forms a value ti in calendar 6000. A unique digital signature is generated for each client-level input data. This encodes, among other data, the hash value of?sibling nudes. The global hash tree also contains the corresponding calendar value. This allows one to recompute the global haveh tree using the data set and signature. The highest level of certainty is that the data set that led to digital signature is identical to the one that is derived from the uppermost computation.
“The operation and configuration of the system as shown in FIGS. FIGS. 1-5 show the operation of the system. However, this is not a complete description. This means that if the server or network connection to core fails, no client would be able digitally sign records. If one of the aggregators fails, or the network connection to it to the core becomes too slow, then clients whose requests are fed to this aggregator will not be able get digital signatures within the current period. What is needed is therefore a way to overcome the concern about single-point-of-failure, while still providing well-determined data signatures that can be used for later data validation.”
“Various embodiments of a method and various system implementations are described to reduce or eliminate at least one aspect of the problem of single-point-of-failure in a digital record validation infrastructure that is arranged as a tree structure. It is useful to first understand the details of a distributed tree infrastructure, which can be modified to provide fail-safe mechanisms. Another embodiment uses a blockchain to store the fail-safe values.
“Distributed hash tree infrastructure”
“FIGS. 1 and 2 illustrate a distributed, keyless, hash tree-based digital record-authentication infrastructure such as is provided by Guardtime AS of Tallinn, Estonia. There are several layers to the general infrastructure: a client layer 2000, which includes a number client systems; a layer with gateways 3000; one or more aggregation system 4000; and a layer that includes a core 5000. The core, gateways, and aggregators will typically be servers with network connections and network communication software and hardware. The ‘user-level’ Client systems can also be servers. However, depending on how the implementation is done, some or all of them may be more individual workstations, laptops, or other mobile computing devices. FIG. FIG.
“As FIG. “As FIG. 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, the centrally administered system/server) 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.
“In the illustrated arrangement, a client is the system where digital records are prepared and entered into the verification/signature system. A digital record can be any binary data that one later wants to verify has not changed from the initial registration and signature using the infrastructure. The term “digital record” is used here. A digital representation of an image or audio file, or combined audio-visual data, such as from a camera, could all be considered digital records. A?digital record’ is generally defined as a “digital record”. A?digital record? can therefore be any data that can be represented as a collection of binary data regardless of source, method of creation, or storage method. A client is a system that represents any type of information, regardless of source, creation, or presentation. It can then be processed and registered according to the invention.
“A gateway at layer 3000 will usually be a computer system, such as a server, with which one or several clients communicates in order to receive requests for digital records registrations from its clients. A gateway is a server that an enterprise or third-party provider controls. This server may be known by and possibly controlled by a client’s organization, or accessible through the Internet. A gateway can be any server that is located in a geographic area 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 and another gateway might be an online server that is accessible to arbitrary users.
An aggregator in the 4000 aggregation layer will be similar to a computer system, such as a server that receives registration requests after they have been consolidated by their respective gateways. Depending on the design and scale of an implementation, any aggregator can also be controlled or owned by the same system as the gateways or clients. In some cases, it may also be possible consolidate the gateways and aggregators for a particular client.
“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 related to clients. Aggregators may also be more closely linked with the core administrator. However, this is not an easy distinction. Some of the functional components that are associated with an aggregater may also be located within the core, as shown in the following. The bottom line is that although clients, gateways, cores, and aggregators will be typically separate computers such as servers or web servers, the functional and logical distinctions may not always be as clear.
“Everyone of the computer systems that make up the infrastructure will include hardware (CPU(s), storage, memory, network interface devices, and so on). Software (including operating system software, computational modules to perform various hashing operations and maintain internal data structures, results, and so on) required to implement the registration or authentication processes described here. These hardware and software components, except for those that are specific to implementing various embodiments, are well-known to system designers. They are not therefore discussed further.
“FIG. FIG. 2 illustrates the infrastructure of FIG. 1 in more detail. FIG. FIG. 2. Different clients are represented as 2010-1. . . 2010-n gateways are represented by 3010-1 and 3010-2. . . , 3010 m; and two other aggregators are listed as 4010-1,4010-k. As described below, an aggregator will usually communicate with each of the core’s lowest level hash tree nodes. 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 popular class of hash functions that can be used in this infrastructure is the “secure hash algorithm”. (SHA) family.”
“Additional hashing or an expanded input vector that includes other parameters may be required by the client depending on the protocol for the infrastructure. The system designer may choose to include the following arguments in the additional hash function 2016. An identifier for the person or entity that is requesting registration, an identification of the specific client system being used and a time indication. Information relating to the geographical location of the client, other system or any other information requested to be included as part of the registration application. The signing infrastructure doesn’t generally care? The signing infrastructure does not care about what arguments are in a digital input record. It doesn’t matter if they are in the same order or following what formatting protocol. Any 1’s or 0’s in the data record can be hashed and signed just like any other. Only one requirement is that an authentic or original data file be verified by the user. It must be presented identically so that the arguments to the hashing function produce the same output. 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) along with any other parameters or data required to communicate with a gateway to initiate registration requests.
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. Many well-known hash function will work across the infrastructure. You can choose from normal design considerations. However, the function that converts digital records into forms suitable for submission as a request does not need to be a hash function. As long as its properties can be determined. If the user doesn’t care about the?raw? aspect of small digital records, it may be a good idea to not do so. If the user doesn’t care about the “raw” data being disclosed, it might be more efficient to send the digital records as they are.
The gateway 3010-2 illustrates the data structure of a binary tree. The gateway hash tree’s lowest nodes will correspond to 2018 transformed dataset submitted by a client. The values of each pair of nodes form inputs to a parent, which then calculates an output value as a combination of the input values from its?children?. nodes. Each combined output/hash value is then submitted “upward?” As one of the inputs to a “grandparent?” one of two inputs 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 aggregators will ultimately calculate the highest combined output value. The result of applying a hash function that includes the information derived from every client who submitted a request to the gateway under that aggregator. 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 often maintained and managed by the overall system administrator. The core uses the lowest level inputs of the aggregators to compute a hash tree data structure. The core’s hash computations and structure form an aggregate of aggregation value. At each calendar time interval of t0, 1, the core will ultimately compute one current core hash value at each tree node 5001. . . , tn. This is also known as the ‘calendar value? or?current calendar value? or ?current period value? “Ci for the time interval Ti.”
“Note: The time origin and the granularity can be chosen in both design options. One could choose to have each time interval equalized at 1.0 seconds. It might be better to choose a higher value if network delays are anticipated or suspected. A less frequent calculation of calendar values may also be used to meet administrative or other requirements of verification infrastructures that are implemented entirely within one enterprise or for other reasons.
In the reverse, one could reduce the time interval to generate calendar values more often than once per second if there is a need for finer temporal resolution. The system designers might choose the appropriate time granularity depending on factors such as expected processing load, transmission rate, and network bandwidth.
One advantage to having a consistent and precise calendar period such as 1.0 seconds is the exact correspondence between time and calendar value. Each calendar value will also represent a time value, which will be included in each signature. Core 5000 should therefore communicate with or include a precise time base such as a precision time clock or low-latency connection for an external clock signal or indication.
“Note: The root node at the top of the tree 5001 is the root node in the entire tree structure. This will change at the end the next period of accumulating request and generating signature vectors. (also known as “data signatures?”). containing recomputation parameters.”
“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 (the 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 input record 2012 includes all the?X marked values, then the re-computation will produce the same value in the current calendar value. However, only if the original input value is identical to the original. Any slight alteration to the digital output record, or any single bit change in the signature associated to record 2012, will result in a re-computed value calendar that is not identical to node 5001. Also, each computed value in core?the current value?contains information that was derived from all digital input records that were input into the system within the current calendar time period.
“FIG. “FIG. Infrastructure whose hash trees node values contain information that is necessary to recompute a hash tree path from the top to 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 to authenticate or detect any differences.
“In FIG. “In FIG. If order is important in the chosen haveh function, then sibling status at each level will be to the ‘right? Or?left? in the hash structure will apply. FIG. FIG. 3 shows not only the value, but also its order (0: from left to 1: from right). This vector (sibling value 0-9 and order bits) returns along with any other information (for instance, the clock time or physical time that the current calendar value is corresponding to) 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 One can also see that the computational load to validate N digital input records at any time is log2N.
“To increase independence between the different layers?” In particular, clients and later entities that wish to perform authentication via recomputation, it is beneficial for the entire calendar be passed to the clients and to the aggregators, as well as the lower layers. This is done every time a new calendar value, that is at the end of each time interval. This allows for delegation and the distribution of the computational load without compromising the integrity of system. It would be possible to authenticate digital records up to the level of their respective calendar values if the data signature vectors were passed along with the respective calendar values. However, anyone with the ability to calculate hash values in the correct order could authenticate digital records that are identical to the original given the signature vector.
“FIG. “FIG. The core contains all calendar values, either starting at some time or, more preferably, beginning at the beginning of the system time. The collection of past and present calendar values (or the “calendar”) is the most common use of the illustrated infrastructure. The collection of the past and present calendar values (or the “calendar”) will soon grow in size to transmit from the core to the aggregators each time a new value is calculated. However, this may be possible in certain cases where the difference in time is sufficient relative to available bandwidth. It is not practical or even necessary in most cases. It is preferable to send to aggregators only the most recent calendar value. Each aggregator keeps its own complete calendar. This has the advantage of allowing full calendars to be stored in multiple locations. The core could transmit a complete calendar whenever a new aggregator is installed to the infrastructure. This would be complemented by the new calendar values that are being computed as they are calculated. Calendars can be kept at any level of the infrastructure. This allows clients, gateways, and new aggregators to join the infrastructure without any administrative burden. It also makes it possible to recomputational and authenticate any digital record without needing to involve higher levels than the entity that is trying to authenticate it.
“In most implementations, the authentication infrastructure shown at FIG. 1. Digital input records will be from many sources. They may come from different types and be input to client systems that are separated physically. These digital input records may then be fed upwards into different gateway servers. A change in even one bit of a digital input record can result in a calendar value that is not comparable to what it would be without the bit change. This is due to the nature of proper hashing functions. Practically, this means that if even one digital input record is entered into the infrastructure within a subsequent interval, the calendar value is completely unknown beforehand.
“See again FIG. 3. The core may compute the current calendar value 5001 for the new interval. After that, the aggregator can return to aggregator 4041-0 its sibling (X) lowest core value from aggregator 4010-k. The gateway 3010-2 can then return downwards all the above plus the X marked hash value computed within the gateway’s hash tree structure to the client 2010. For each client, the data signature vector 8000 can be created. This includes any input record 2012 (or any other entity) that has all the?sibling?. Values for an input record.”
This arrangement allows for the distribution of the hash computation infrastructure across various layers (vertically and?horizontally). Each layer has a responsibility to transmit requests downwards and partial or complete signature vectors upwards. However, this arrangement allows for the distribution of these tasks and can be done simultaneously at many locations. Since a data signature is unique for the digital record it led to, the procedure to return a signature vector 2012 for client 2010-1 (note: a client may input more digital records for verification at any time interval) should be duplicated for all digital inputs records received during the time period over which the values were accumulated to calculate node value 5001.
FIG. 2 shows the configuration of the distributed infrastructure. 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 functions will 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 wishes to verify that the digital record in question is correct?a?candidate?digital record? Is an identical copy to digital record 2012. The entity must compute the exact same digital record 2012 by applying the same transformation function 2016 on the candidate digital records and recomputing upward with the corresponding data signature 8000. It is not necessary that you call the signature infrastructure 500 to verify a candidate record. However, it is possible for the same system be configured to recompute a record from a given calendar value to a service.
This level of verification may be sufficient for some implementations. One possible example is that if enough independent aggregators distribute the calendar, then if one malicious agent attempts to alter any calendar value, it could be detected by 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 time interval is short enough. This delay can be increased to increase security. Clients could request an option to generate and send a data signature vector and a key-based signed cert. The certificate may be issued by any higher level system, such as core, aggregator or current gateway. However, this is only a temporary and optional expedient that will increase security. Implementations of the keyless authentication infrastructure disclosed may also include the use of keys for other purposes than authentication of digital input records. For example, one might include a key-based solution to verify the identity of a user, independent of any data he might be trying sign or authenticate.
“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 an online posting, newspaper, or blockchain. 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 all need to have 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, which will not match the actual publication price. The composite signature value, or the publication value, is no longer required to associate any signed digital certificates (which may be used as before to increase security, but will not be necessary) with the signature vector for the corresponding digital input records; instead, one can use the data signature vector, and the calendar values (which is advantageously stored in each aggregator), to recompute hash value upwards 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 recorded being tested 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. FIG. 5, the Merkle tree structure) is required to recompute the published value 7000. The current calendar value must not be the last in the current publication interval Tp. If that happens, all sibling values within the core required to recompute the published value will not be available until data signatures corresponding the current calendar value have been returned. The?extended sibling? The?extended sibling? values (illustrated by those marked with??E?) These values (illustrated as those marked with?E?) may be passed on to aggregators and further down through the layers at the end the publication time interval, so clients can add extended sibling values to their data signatures. The core may then extend or augment the signature vectors to include?E? at the end of each calendar period. The extended signature vectors are then 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 digital input records will 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.
“Another option would be 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, for 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 record submitted to the data room.
“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 calendar values for the publication time interval concatenated, and then hashed together with a pseudorandom numbers, which becomes part of extended data signature vectors. A further embodiment is described below, in which a Blockchain serves both the function of the Calendar and the purpose of “publication?” “In an essentially indestructible medium.”
“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.
“Redundancy & Synchronization”
FIG. 2: If the core system (typically a server) 5000, or the network connection to it, fails, it is impossible to create data signatures for as long as the failure continues. There would be an unacceptable delay, or worse, administrative problems in getting data signatures for both the past and current periods’ requests. This assumes that the requests from the previous period are being serviced. If no connection is made between the core and one of the aggregators, there will be no other option and that aggregators’ childrens’ would not be served. Requests for data signatures cannot be fulfilled.”
“FIGS. “FIGS. 5000-0, 5000-1, and 5000-2 are all labeled N0, 1 N2, 2 respectively. This embodiment has two highest level aggregaters (4000-1 and 4000-2, also labeled A1, respectively), which feed their respective topmost hash values of x1, 2 to N1, 2, respectively. The primary or default? Core for A1 is N1 while core for A2 are N2. Because they are so associated, aggregator Ai will be referred to as the ‘associate’. or the?associated aggregateor? Node Ni. This association is not required, but may be because Ai or Ni have a network connection that is known to be stable and fast, either for load balancing, geographic preference, administrative reasons, or just for administrative purposes. They could be running different processes on the same computer. Each node Ni attempts to transmit the corresponding hash value (xi) to the other nodes. Alternative implementations are also possible. The nodes could exchange their node IDs first and then fill in the received xi values with the other nodes later. This would allow for a more practical approach to the calculation of the calendar round.
“An alternative is to have each aggregator transmit its highest hash value to all nodes (or as many) as possible. The success or failure of receipts will be displayed in subsequent exchanges. Another alternative embodiment is described and illustrated below.
“Each core network node will be able to identify which aggregator issued a received request. Core nodes will be able decode the identifiers for each aggregator and receive them. There are several ways to identify which server another server communicates with. One way is by looking at the IP address of the aggregator or the specific information the aggregator sends with each request. You can also include the aggregator’s identifier and its hash value, xi.
“Note that FIG. Although FIG. 6A depicts separate lines of communication between the core nodes and the aggregators, in practice, one network, such as the Internet, may be used. The core nodes N1, and N2 can communicate with each other over the same network (e.g., the Internet) or over a dedicated, faster network. It is assumed that aggregators, in the normal, non-failure situation, will be capable of communicating information to core nodes.
“Failure is a concept that refers to an inoperable component of the infrastructure. “Failure” does not only refer to an inoperable component of the infrastructure. For example, if a server goes down? or a network connection being severed. Many signature infrastructures have a time limit, such as a calendar period, when requests for digital signatures must be?cut off?. Then, subsequent requests will fall in the next period. Also, there must be a?cut-off? So that the hash tree (period) for the current round can be established, and an uppermost haveh value calculated. A failure by an aggregator to reach the core node within the time limit (before the cut off time for the current round), is also considered a failure. In the spirit of embodiments, the request has been rejected by at least one core network node.
“FIG. “FIG. 6A” illustrates the hardware and software components that are typically included in core nodes. The standard components like a processor, memory, storage and an operating system will be included in core nodes. However, they are not shown in this figure for simplicity. Similar hardware and software components are not shown in a similar server or computer system that implements each core node. FIG. FIG. 6A shows that each core node N0 and N1 will have a network interface 505. This may be a standard hardware component with corresponding driver Software, a computation module 535 for computing the internal hash trees that include the aggregators? uppermost hash values as inputs and a calendar component 6000. These components will typically consist of a data structure in storage, or non-volatile, with code that enables computation and processing of various values within the data structure. Each core node in this embodiment will include an exchange module 515 and a resolution module 525. These modules will contain bodies of computer-executable software, whose functions will be described below. Any or all of the components listed may be virtualized.
“Now let Si be a set of highest hash values that Ni receives in a given calendar period. The?local set’ is Si. For Ni. For Ni.
“x1=only x1;”
“x2=only x2;”
“x1,x2=both of x1 or x2; or”
neither HTML1 nor HTML2.”
“Different circumstances may have caused a core node to not receive one or both xi values of the aggregators, A1, A2. One possible reason is that the core node did not receive the xi values from the aggregators A1, A2.
“In a single core infrastructure, it is easy to decide which upper-most aggregater’s hash value to include in the calculation of the current calendar. Simply include the received xi. Multi-core infrastructures can receive different xi transmissions. Therefore, there should be a mechanism to resolve any ambiguities and determine a consistent current calendar value across all cores. Also, it should be possible to calculate a global final set of xi values from the different local sets. These may differ. FIGS. 6A and 6B are consistent in two phases: Distribution (or Agreement), labeled D or A in FIG. 6B.”
“The figures are shown as though the core nodes N1 and the exchange modules 510 have distinct connections as in FIG. 6B, or the connections between exchange modules 510 in FIG. 6A is the connection between the exchange modules 510 in FIG. This would be possible if the network was dedicated and faster, but core nodes will still communicate over the same network, 900 via the same interface 505, just as with any other network connection.
“In the distribution phase each core node Ni compiles, exchanges (via its respective exchange module 5010) with all core nodes (at minimum, all those it can connect and communicate to at the moment), its Si of aggregator Ai values xi it has received. Each node then tells the other what it thinks. The current input set of the aggregator hash value xi. If a minimum number of core nodes receives at least one set Si, then core nodes in the resolution module520 determine the majority view. This set becomes S* and is used to calculate the current calendar value. This embodiment includes the core node N0 to arbitrate any disagreements by providing another vote? About the current correct set Si.
“If a core nude is not part of the majority, it doesn’t compute a calendar value and does not return its associated?child? aggregator the set recomputation values it would require to form proper digital signatures. Instead, assume a core node consensus (the majority agrees on the input set), then?minority? The computed current calendar value is sent to the core node by one of the majority nodes.
“Each core Node may therefore compile and maintain an entire and consistent system-wide calendar. FIGS. 4 and 5 show embodiments that include publication. 4, 5, and 6 each core node N1, 2, N3, and publication may be computed independently (since they all use the same calendars). Or, the infrastructure could be designed in such a way that one node computes the publication value and distributes it globally if needed.
“In the general scenario here, after the Distribution phase the resolution modules determine the?majority’. This is the view. If at least two core nodes agree, that is the current set S* all nodes use to compute the current calendar value, send recomputation parameters and error messages to aggregators whose values are included in S*. Here are some examples:
“Example 1”
“The ?ideal? “The?ideal?” case is the most common. Each aggregator A1, A2 transmits successfully its highest hash value x1, and x2, respectively to the core nodes N0 N1 N2. Thus, S0=S1=S2=x1, x2. Each core node will share its Si to the two other core nodes. All nodes’ resolution module 520 will detect unanimity and x1, x2 will be distributed in the Agreement phase as S*=x1,x2. Once S* has been stored, each core node will be able to compute the current calendar value as usual in the tree module 533 and then distribute the recomputation parameters down to its associated aggregater. If the aggregator does not receive an answer from?its, If an aggregator doesn’t receive an answer from?its within a predetermined period of time, it might follow a failure protocol. This would be: query any other nodes. Failure to get an answer from any node indicates to the aggregator that the request cannot be serviced for this calendar period. It would then need to either resubmit, or simply return to its subordinate gateways, aggregators, and/or clients an “Error message”.
“Example 2”
“The ?worst? “The?worst?” case: The majority of core nodes fail to receive request xi from at least two of S0_ =?., S1_, and S2. After the Distribution phase, all core nodes will realise that it is impossible to return answers to aggregators. After the Agreement phase, all nodes will realize that it is not possible to return any answers to aggregators and will send failure messages down to them.
“Example 3”
“S0=x1, x2; S1=x1; S2=x1, x2. Both values x1 and x2 must reach at least two core nodes. The?consensus can be formed by a majority. S*=x1,x2. This information is then sent to all core nodes (including N1) during the Agreement phase. The current tn calendar value can be computed by all core nodes using the inputs x1 or x2. All clients can still receive digital signatures because there is a consistent recomputation path from each client to the calendar to tn upward.
“Example 4”
“S0=x1; S1=x1; S2=x1, x2. The majority of this set includes only one value x1, x2. S*=x1 in this example means that only x1 is allowed to be used in the calculation of the current calendar value, tn. The error message must be sent to A2 (e.g., by N2) because the x2 value of its associated aggregator does not appear in the final set. Clients below A1 will not receive digital signatures, as they only have a path to tn.
“Example 5”
“S0=x1, x2; S1=x1; S2=x2. Even though the majority does not have the same set, it is still possible to compute the final set. The final set in this example is x1,x2. This is because both x1 (and x2) are elements of two distinct majorities of the sets. Essentially, x1 is an x1 element of S0=x1, S2=x1 and S1=x1. x2 (and x1) is an x1 element of S0=x1 and S2=x1. x2 is an x2 element of S0 and S2=x2=x2=x2=x2=x2=x2=x2=x2x2=x2=x2=x2=x2=x2=x2=2=x2=x2x2=x2=x2x2=x2=x2=x2=x1x1x1x1x1x1x1x1x1x1x2x1x1x1x1x1x1x1x1x1x3x1x1x1x1x1x1x2x2x2x2x2x2x2x2x2x2x1x2x1x1x1x1x1x1x1x2x1x2x1x1x1x1x1x1x2x1x1x2x1x1x1x1x1x1x2x2x1x1x1x1x1x1x1x1x2x2x1x2x1x1x1x1x1x2x1x1x1x2x1x1x1x1x1x2x1x2x1 If N1 has all three sets it can compute the final set S*, and may be able to answer its clients.
“Example 6”
“S0=x1, x2; S1=x1, x2; S2=?. This consensus again states that S*=x1,x2; S1=x1,x2; S2=?. All core nodes can use this data to compute the same number. It is possible to still service clients below A2 even if the connection to N2 has been cut or N2 has suffered other problems. As long as there is an internal recomputation path through a node’s tree (which will be identical to what N2’s tree would be), then a valid data signature can be formed. After receiving all the missing? data, N2 or the connection back to N2 will be able to maintain and store a complete calendar 6000. Any other nodes such as N0, the arbitrator, or N2 will also receive values.
“Example 8”
“S0={? }; S1=x1, x2; S2=?. This is a variation of the “worst?” This is a variant of the?worst? scenario in which there is no majority consensus and all aggregators get error messages.
“Example 9”
“S0=x1, x2; S1=x1, x2; S2=?. N1 can decide that the final set of numbers is S*=x1,x2; S1=x1,x2; S2=?.
“Example 10”
“S0=x2; S1=x1, x2; S2=x1. N1 cannot decide which set is the final one. If S2=x2 then the final sets should be S*=x2. If S2=x1,x2, then S*should be S*=x1. In the present case, N1 doesn’t know S2 so it is impossible for N1 determine what S* is. In such a case, N1 should not answer its clients but should instead follow the recovery protocol for such cases.
“Remember that there will be other cases (switching between x1 andx2 or switching node indexes), or they can be solved using the general rule for majority consensus.
“FIG. “FIG.7 illustrates an infrastructure where a number of aggregators submit higher-level hash value to n core nosdes. Where k>2 or n?k. Although k=4 is shown and n=5, this is only one example. The relationship between k, and n does not have to be the same. Different aggregators (A1-A4) are linked with different nodes in the illustrated embodiment. So A1 is communicating its highest hash value, x1, to N1, N2, N3, and A2; A3 is also communicating with N2 andN3; A3 is also communicating with N2 and the N3; while A4 is communicating with N3 and N4. This is only one example. In the nominal, no-failure scenario, each aggregator Ai can communicate its highest value xi with all nodes N1 through N4, which in turn communicates with each other nodes N2 and N3; A3 is also communicating x3 to nodes N2 and N3; A4 is communicating x4 with nodes N3 and N4.
As before, each aggregator (A1-A4) may be uniquely associated to a particular one of the N1-N4 nodes, for example because it is a process that is running in that node. This is because it has a network connection that is known to be reliable and fast for network administration or any other reason. Each node Ni could also be considered to have its associated aggregator Ai in such an embodiment. A given aggregator Ai may also be able communicate only with Ni. In this case, nodes exchange their values xi among themselves so that Nj learns the value xi from Ni (j?i). This is sometimes referred to as “fixed?” association.”
“It is also possible for aggregators to not have a fixed association to any node. Each aggregator Ai tries to communicate its value to all or selected nodes at least once. This may be called?nonfixed? association. Inter-node exchanges of xi values in such cases may not be necessary or may be performed as a secondary, confirmative, or back-up step.
Each node may be assigned two roles, depending on whether it serves requests from associates (aggregators). If an associate request is not received by a node, that node can assume a support role and serve as backup storage for core nodes. These roles can change depending on whether requests are received by a given node.
Summary for “Blockchain-supported, fail-safe synchronization in a data authentication infrastructure”
It has become more difficult to verify digital data authenticity in an electronic age, but it is also more important. Electronic documents (which can be defined broadly as any type of digital information) 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 certificate to?sign’ them. They are usually generated using some type of asymmetric cryptography. The speed of public key cryptography allows for almost instantaneous certificate generation. Asymmetric cryptography can be used to create digital signatures, but there is a weakness: Cryptographic signature keys could become compromised. The certificates that were created using that key can no longer be verified if the key is compromised. Certificates created using keyed cryptography can only be used for a limited time because the probability of a key being compromised increases.
Key-based systems also have other drawbacks. It becomes difficult to track sometimes large numbers of keys and whether or not they are valid.
“Most common systems treat every digital record as an independent entity, unrelated to any others” keys are generated for each record and security is dependent on this key set. Information associated with records will not reflect anything that has happened to another record or any other time. Without an individual user being aware, entire systems could be compromised.”
Other systems can increase verifiability by using information from multiple records at once to calculate a composite higher-level value that can help detect unauthorised changes to any records. A tree structure of hash value (for example, Merkle tree structure), can be used to create a single highest level verification value. This means that any change to one record will result in a different highest-level value after recomputation, which will indicate that there has been a change.
“When it comes verifying digital documents’ authenticity, no matter how much the user cares about proofs of receipt order, all existing methods have the serious flaw of requiring that the users trust the service provider. This means that even if a verification scheme is theoretically reliable, the user must trust the entity performing the verification. Although trust in such systems can sometimes be unfounded, it is still a cause for concern. For example, in 2007, it was discovered that the BSAFE cryptographic libraries of RSA Security (a major provider cryptographic technologies) used DUAL_EC_DRBG random numbers generator as a default. This included a?backdoor? This was due to the use of a set U.S. National Security Agency initiating numbers. Even with the most sophisticated keys, it is still difficult to trust the keymaker.
Publishing a digital record with verifying information is an alternative to relying on keys. This may avoid the need for such trust, but a pure publication-verification scheme is unsuitable for large collections of documents that each may need authentication. One or both of the two problems that are common to known authentication schemes is that there must be a?trust authority? Or the systems aren’t scalable enough.
Guardtime AS, Tallinn, Estonia provides a distributed hash tree-based data verification system that does away with keys, is highly scalable and can be used independently relying on only mathematical procedures that are available to everyone.
“FIGS. “FIGS. Sets of digital data (or?digital records?) or ?digital records?) are input by a group of low-level systems, which includes clients 2000. A hash function transforms the digital data and returns a hash value. The client-level hash value is used to create a node in a global haveh tree. It then hashes in successively higher levels of gateways 3000. These nodes then hash each other’s nodes in their respective internal hash tree structure to form inputs for aggregators 4000. In turn, the aggregators hash their input nodes within a tree structure to create highest-level aggregator values. These inputs are then submitted to input nodes in core system 5000 which hash at least the current set input node values together in order to form a root value that forms a value ti in calendar 6000. A unique digital signature is generated for each client-level input data. This encodes, among other data, the hash value of?sibling nudes. The global hash tree also contains the corresponding calendar value. This allows one to recompute the global haveh tree using the data set and signature. The highest level of certainty is that the data set that led to digital signature is identical to the one that is derived from the uppermost computation.
“The operation and configuration of the system as shown in FIGS. FIGS. 1-5 show the operation of the system. However, this is not a complete description. This means that if the server or network connection to core fails, no client would be able digitally sign records. If one of the aggregators fails, or the network connection to it to the core becomes too slow, then clients whose requests are fed to this aggregator will not be able get digital signatures within the current period. What is needed is therefore a way to overcome the concern about single-point-of-failure, while still providing well-determined data signatures that can be used for later data validation.”
“Various embodiments of a method and various system implementations are described to reduce or eliminate at least one aspect of the problem of single-point-of-failure in a digital record validation infrastructure that is arranged as a tree structure. It is useful to first understand the details of a distributed tree infrastructure, which can be modified to provide fail-safe mechanisms. Another embodiment uses a blockchain to store the fail-safe values.
“Distributed hash tree infrastructure”
“FIGS. 1 and 2 illustrate a distributed, keyless, hash tree-based digital record-authentication infrastructure such as is provided by Guardtime AS of Tallinn, Estonia. There are several layers to the general infrastructure: a client layer 2000, which includes a number client systems; a layer with gateways 3000; one or more aggregation system 4000; and a layer that includes a core 5000. The core, gateways, and aggregators will typically be servers with network connections and network communication software and hardware. The ‘user-level’ Client systems can also be servers. However, depending on how the implementation is done, some or all of them may be more individual workstations, laptops, or other mobile computing devices. FIG. FIG.
“As FIG. “As FIG. 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, the centrally administered system/server) 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.
“In the illustrated arrangement, a client is the system where digital records are prepared and entered into the verification/signature system. A digital record can be any binary data that one later wants to verify has not changed from the initial registration and signature using the infrastructure. The term “digital record” is used here. A digital representation of an image or audio file, or combined audio-visual data, such as from a camera, could all be considered digital records. A?digital record’ is generally defined as a “digital record”. A?digital record? can therefore be any data that can be represented as a collection of binary data regardless of source, method of creation, or storage method. A client is a system that represents any type of information, regardless of source, creation, or presentation. It can then be processed and registered according to the invention.
“A gateway at layer 3000 will usually be a computer system, such as a server, with which one or several clients communicates in order to receive requests for digital records registrations from its clients. A gateway is a server that an enterprise or third-party provider controls. This server may be known by and possibly controlled by a client’s organization, or accessible through the Internet. A gateway can be any server that is located in a geographic area 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 and another gateway might be an online server that is accessible to arbitrary users.
An aggregator in the 4000 aggregation layer will be similar to a computer system, such as a server that receives registration requests after they have been consolidated by their respective gateways. Depending on the design and scale of an implementation, any aggregator can also be controlled or owned by the same system as the gateways or clients. In some cases, it may also be possible consolidate the gateways and aggregators for a particular client.
“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 related to clients. Aggregators may also be more closely linked with the core administrator. However, this is not an easy distinction. Some of the functional components that are associated with an aggregater may also be located within the core, as shown in the following. The bottom line is that although clients, gateways, cores, and aggregators will be typically separate computers such as servers or web servers, the functional and logical distinctions may not always be as clear.
“Everyone of the computer systems that make up the infrastructure will include hardware (CPU(s), storage, memory, network interface devices, and so on). Software (including operating system software, computational modules to perform various hashing operations and maintain internal data structures, results, and so on) required to implement the registration or authentication processes described here. These hardware and software components, except for those that are specific to implementing various embodiments, are well-known to system designers. They are not therefore discussed further.
“FIG. FIG. 2 illustrates the infrastructure of FIG. 1 in more detail. FIG. FIG. 2. Different clients are represented as 2010-1. . . 2010-n gateways are represented by 3010-1 and 3010-2. . . , 3010 m; and two other aggregators are listed as 4010-1,4010-k. As described below, an aggregator will usually communicate with each of the core’s lowest level hash tree nodes. 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 popular class of hash functions that can be used in this infrastructure is the “secure hash algorithm”. (SHA) family.”
“Additional hashing or an expanded input vector that includes other parameters may be required by the client depending on the protocol for the infrastructure. The system designer may choose to include the following arguments in the additional hash function 2016. An identifier for the person or entity that is requesting registration, an identification of the specific client system being used and a time indication. Information relating to the geographical location of the client, other system or any other information requested to be included as part of the registration application. The signing infrastructure doesn’t generally care? The signing infrastructure does not care about what arguments are in a digital input record. It doesn’t matter if they are in the same order or following what formatting protocol. Any 1’s or 0’s in the data record can be hashed and signed just like any other. Only one requirement is that an authentic or original data file be verified by the user. It must be presented identically so that the arguments to the hashing function produce the same output. 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) along with any other parameters or data required to communicate with a gateway to initiate registration requests.
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. Many well-known hash function will work across the infrastructure. You can choose from normal design considerations. However, the function that converts digital records into forms suitable for submission as a request does not need to be a hash function. As long as its properties can be determined. If the user doesn’t care about the?raw? aspect of small digital records, it may be a good idea to not do so. If the user doesn’t care about the “raw” data being disclosed, it might be more efficient to send the digital records as they are.
The gateway 3010-2 illustrates the data structure of a binary tree. The gateway hash tree’s lowest nodes will correspond to 2018 transformed dataset submitted by a client. The values of each pair of nodes form inputs to a parent, which then calculates an output value as a combination of the input values from its?children?. nodes. Each combined output/hash value is then submitted “upward?” As one of the inputs to a “grandparent?” one of two inputs 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 aggregators will ultimately calculate the highest combined output value. The result of applying a hash function that includes the information derived from every client who submitted a request to the gateway under that aggregator. 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 often maintained and managed by the overall system administrator. The core uses the lowest level inputs of the aggregators to compute a hash tree data structure. The core’s hash computations and structure form an aggregate of aggregation value. At each calendar time interval of t0, 1, the core will ultimately compute one current core hash value at each tree node 5001. . . , tn. This is also known as the ‘calendar value? or?current calendar value? or ?current period value? “Ci for the time interval Ti.”
“Note: The time origin and the granularity can be chosen in both design options. One could choose to have each time interval equalized at 1.0 seconds. It might be better to choose a higher value if network delays are anticipated or suspected. A less frequent calculation of calendar values may also be used to meet administrative or other requirements of verification infrastructures that are implemented entirely within one enterprise or for other reasons.
In the reverse, one could reduce the time interval to generate calendar values more often than once per second if there is a need for finer temporal resolution. The system designers might choose the appropriate time granularity depending on factors such as expected processing load, transmission rate, and network bandwidth.
One advantage to having a consistent and precise calendar period such as 1.0 seconds is the exact correspondence between time and calendar value. Each calendar value will also represent a time value, which will be included in each signature. Core 5000 should therefore communicate with or include a precise time base such as a precision time clock or low-latency connection for an external clock signal or indication.
“Note: The root node at the top of the tree 5001 is the root node in the entire tree structure. This will change at the end the next period of accumulating request and generating signature vectors. (also known as “data signatures?”). containing recomputation parameters.”
“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 (the 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 input record 2012 includes all the?X marked values, then the re-computation will produce the same value in the current calendar value. However, only if the original input value is identical to the original. Any slight alteration to the digital output record, or any single bit change in the signature associated to record 2012, will result in a re-computed value calendar that is not identical to node 5001. Also, each computed value in core?the current value?contains information that was derived from all digital input records that were input into the system within the current calendar time period.
“FIG. “FIG. Infrastructure whose hash trees node values contain information that is necessary to recompute a hash tree path from the top to 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 to authenticate or detect any differences.
“In FIG. “In FIG. If order is important in the chosen haveh function, then sibling status at each level will be to the ‘right? Or?left? in the hash structure will apply. FIG. FIG. 3 shows not only the value, but also its order (0: from left to 1: from right). This vector (sibling value 0-9 and order bits) returns along with any other information (for instance, the clock time or physical time that the current calendar value is corresponding to) 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 One can also see that the computational load to validate N digital input records at any time is log2N.
“To increase independence between the different layers?” In particular, clients and later entities that wish to perform authentication via recomputation, it is beneficial for the entire calendar be passed to the clients and to the aggregators, as well as the lower layers. This is done every time a new calendar value, that is at the end of each time interval. This allows for delegation and the distribution of the computational load without compromising the integrity of system. It would be possible to authenticate digital records up to the level of their respective calendar values if the data signature vectors were passed along with the respective calendar values. However, anyone with the ability to calculate hash values in the correct order could authenticate digital records that are identical to the original given the signature vector.
“FIG. “FIG. The core contains all calendar values, either starting at some time or, more preferably, beginning at the beginning of the system time. The collection of past and present calendar values (or the “calendar”) is the most common use of the illustrated infrastructure. The collection of the past and present calendar values (or the “calendar”) will soon grow in size to transmit from the core to the aggregators each time a new value is calculated. However, this may be possible in certain cases where the difference in time is sufficient relative to available bandwidth. It is not practical or even necessary in most cases. It is preferable to send to aggregators only the most recent calendar value. Each aggregator keeps its own complete calendar. This has the advantage of allowing full calendars to be stored in multiple locations. The core could transmit a complete calendar whenever a new aggregator is installed to the infrastructure. This would be complemented by the new calendar values that are being computed as they are calculated. Calendars can be kept at any level of the infrastructure. This allows clients, gateways, and new aggregators to join the infrastructure without any administrative burden. It also makes it possible to recomputational and authenticate any digital record without needing to involve higher levels than the entity that is trying to authenticate it.
“In most implementations, the authentication infrastructure shown at FIG. 1. Digital input records will be from many sources. They may come from different types and be input to client systems that are separated physically. These digital input records may then be fed upwards into different gateway servers. A change in even one bit of a digital input record can result in a calendar value that is not comparable to what it would be without the bit change. This is due to the nature of proper hashing functions. Practically, this means that if even one digital input record is entered into the infrastructure within a subsequent interval, the calendar value is completely unknown beforehand.
“See again FIG. 3. The core may compute the current calendar value 5001 for the new interval. After that, the aggregator can return to aggregator 4041-0 its sibling (X) lowest core value from aggregator 4010-k. The gateway 3010-2 can then return downwards all the above plus the X marked hash value computed within the gateway’s hash tree structure to the client 2010. For each client, the data signature vector 8000 can be created. This includes any input record 2012 (or any other entity) that has all the?sibling?. Values for an input record.”
This arrangement allows for the distribution of the hash computation infrastructure across various layers (vertically and?horizontally). Each layer has a responsibility to transmit requests downwards and partial or complete signature vectors upwards. However, this arrangement allows for the distribution of these tasks and can be done simultaneously at many locations. Since a data signature is unique for the digital record it led to, the procedure to return a signature vector 2012 for client 2010-1 (note: a client may input more digital records for verification at any time interval) should be duplicated for all digital inputs records received during the time period over which the values were accumulated to calculate node value 5001.
FIG. 2 shows the configuration of the distributed infrastructure. 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 functions will 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 wishes to verify that the digital record in question is correct?a?candidate?digital record? Is an identical copy to digital record 2012. The entity must compute the exact same digital record 2012 by applying the same transformation function 2016 on the candidate digital records and recomputing upward with the corresponding data signature 8000. It is not necessary that you call the signature infrastructure 500 to verify a candidate record. However, it is possible for the same system be configured to recompute a record from a given calendar value to a service.
This level of verification may be sufficient for some implementations. One possible example is that if enough independent aggregators distribute the calendar, then if one malicious agent attempts to alter any calendar value, it could be detected by 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 time interval is short enough. This delay can be increased to increase security. Clients could request an option to generate and send a data signature vector and a key-based signed cert. The certificate may be issued by any higher level system, such as core, aggregator or current gateway. However, this is only a temporary and optional expedient that will increase security. Implementations of the keyless authentication infrastructure disclosed may also include the use of keys for other purposes than authentication of digital input records. For example, one might include a key-based solution to verify the identity of a user, independent of any data he might be trying sign or authenticate.
“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 an online posting, newspaper, or blockchain. 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 all need to have 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, which will not match the actual publication price. The composite signature value, or the publication value, is no longer required to associate any signed digital certificates (which may be used as before to increase security, but will not be necessary) with the signature vector for the corresponding digital input records; instead, one can use the data signature vector, and the calendar values (which is advantageously stored in each aggregator), to recompute hash value upwards 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 recorded being tested 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. FIG. 5, the Merkle tree structure) is required to recompute the published value 7000. The current calendar value must not be the last in the current publication interval Tp. If that happens, all sibling values within the core required to recompute the published value will not be available until data signatures corresponding the current calendar value have been returned. The?extended sibling? The?extended sibling? values (illustrated by those marked with??E?) These values (illustrated as those marked with?E?) may be passed on to aggregators and further down through the layers at the end the publication time interval, so clients can add extended sibling values to their data signatures. The core may then extend or augment the signature vectors to include?E? at the end of each calendar period. The extended signature vectors are then 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 digital input records will 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.
“Another option would be 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, for 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 record submitted to the data room.
“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 calendar values for the publication time interval concatenated, and then hashed together with a pseudorandom numbers, which becomes part of extended data signature vectors. A further embodiment is described below, in which a Blockchain serves both the function of the Calendar and the purpose of “publication?” “In an essentially indestructible medium.”
“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.
“Redundancy & Synchronization”
FIG. 2: If the core system (typically a server) 5000, or the network connection to it, fails, it is impossible to create data signatures for as long as the failure continues. There would be an unacceptable delay, or worse, administrative problems in getting data signatures for both the past and current periods’ requests. This assumes that the requests from the previous period are being serviced. If no connection is made between the core and one of the aggregators, there will be no other option and that aggregators’ childrens’ would not be served. Requests for data signatures cannot be fulfilled.”
“FIGS. “FIGS. 5000-0, 5000-1, and 5000-2 are all labeled N0, 1 N2, 2 respectively. This embodiment has two highest level aggregaters (4000-1 and 4000-2, also labeled A1, respectively), which feed their respective topmost hash values of x1, 2 to N1, 2, respectively. The primary or default? Core for A1 is N1 while core for A2 are N2. Because they are so associated, aggregator Ai will be referred to as the ‘associate’. or the?associated aggregateor? Node Ni. This association is not required, but may be because Ai or Ni have a network connection that is known to be stable and fast, either for load balancing, geographic preference, administrative reasons, or just for administrative purposes. They could be running different processes on the same computer. Each node Ni attempts to transmit the corresponding hash value (xi) to the other nodes. Alternative implementations are also possible. The nodes could exchange their node IDs first and then fill in the received xi values with the other nodes later. This would allow for a more practical approach to the calculation of the calendar round.
“An alternative is to have each aggregator transmit its highest hash value to all nodes (or as many) as possible. The success or failure of receipts will be displayed in subsequent exchanges. Another alternative embodiment is described and illustrated below.
“Each core network node will be able to identify which aggregator issued a received request. Core nodes will be able decode the identifiers for each aggregator and receive them. There are several ways to identify which server another server communicates with. One way is by looking at the IP address of the aggregator or the specific information the aggregator sends with each request. You can also include the aggregator’s identifier and its hash value, xi.
“Note that FIG. Although FIG. 6A depicts separate lines of communication between the core nodes and the aggregators, in practice, one network, such as the Internet, may be used. The core nodes N1, and N2 can communicate with each other over the same network (e.g., the Internet) or over a dedicated, faster network. It is assumed that aggregators, in the normal, non-failure situation, will be capable of communicating information to core nodes.
“Failure is a concept that refers to an inoperable component of the infrastructure. “Failure” does not only refer to an inoperable component of the infrastructure. For example, if a server goes down? or a network connection being severed. Many signature infrastructures have a time limit, such as a calendar period, when requests for digital signatures must be?cut off?. Then, subsequent requests will fall in the next period. Also, there must be a?cut-off? So that the hash tree (period) for the current round can be established, and an uppermost haveh value calculated. A failure by an aggregator to reach the core node within the time limit (before the cut off time for the current round), is also considered a failure. In the spirit of embodiments, the request has been rejected by at least one core network node.
“FIG. “FIG. 6A” illustrates the hardware and software components that are typically included in core nodes. The standard components like a processor, memory, storage and an operating system will be included in core nodes. However, they are not shown in this figure for simplicity. Similar hardware and software components are not shown in a similar server or computer system that implements each core node. FIG. FIG. 6A shows that each core node N0 and N1 will have a network interface 505. This may be a standard hardware component with corresponding driver Software, a computation module 535 for computing the internal hash trees that include the aggregators? uppermost hash values as inputs and a calendar component 6000. These components will typically consist of a data structure in storage, or non-volatile, with code that enables computation and processing of various values within the data structure. Each core node in this embodiment will include an exchange module 515 and a resolution module 525. These modules will contain bodies of computer-executable software, whose functions will be described below. Any or all of the components listed may be virtualized.
“Now let Si be a set of highest hash values that Ni receives in a given calendar period. The?local set’ is Si. For Ni. For Ni.
“x1=only x1;”
“x2=only x2;”
“x1,x2=both of x1 or x2; or”
neither HTML1 nor HTML2.”
“Different circumstances may have caused a core node to not receive one or both xi values of the aggregators, A1, A2. One possible reason is that the core node did not receive the xi values from the aggregators A1, A2.
“In a single core infrastructure, it is easy to decide which upper-most aggregater’s hash value to include in the calculation of the current calendar. Simply include the received xi. Multi-core infrastructures can receive different xi transmissions. Therefore, there should be a mechanism to resolve any ambiguities and determine a consistent current calendar value across all cores. Also, it should be possible to calculate a global final set of xi values from the different local sets. These may differ. FIGS. 6A and 6B are consistent in two phases: Distribution (or Agreement), labeled D or A in FIG. 6B.”
“The figures are shown as though the core nodes N1 and the exchange modules 510 have distinct connections as in FIG. 6B, or the connections between exchange modules 510 in FIG. 6A is the connection between the exchange modules 510 in FIG. This would be possible if the network was dedicated and faster, but core nodes will still communicate over the same network, 900 via the same interface 505, just as with any other network connection.
“In the distribution phase each core node Ni compiles, exchanges (via its respective exchange module 5010) with all core nodes (at minimum, all those it can connect and communicate to at the moment), its Si of aggregator Ai values xi it has received. Each node then tells the other what it thinks. The current input set of the aggregator hash value xi. If a minimum number of core nodes receives at least one set Si, then core nodes in the resolution module520 determine the majority view. This set becomes S* and is used to calculate the current calendar value. This embodiment includes the core node N0 to arbitrate any disagreements by providing another vote? About the current correct set Si.
“If a core nude is not part of the majority, it doesn’t compute a calendar value and does not return its associated?child? aggregator the set recomputation values it would require to form proper digital signatures. Instead, assume a core node consensus (the majority agrees on the input set), then?minority? The computed current calendar value is sent to the core node by one of the majority nodes.
“Each core Node may therefore compile and maintain an entire and consistent system-wide calendar. FIGS. 4 and 5 show embodiments that include publication. 4, 5, and 6 each core node N1, 2, N3, and publication may be computed independently (since they all use the same calendars). Or, the infrastructure could be designed in such a way that one node computes the publication value and distributes it globally if needed.
“In the general scenario here, after the Distribution phase the resolution modules determine the?majority’. This is the view. If at least two core nodes agree, that is the current set S* all nodes use to compute the current calendar value, send recomputation parameters and error messages to aggregators whose values are included in S*. Here are some examples:
“Example 1”
“The ?ideal? “The?ideal?” case is the most common. Each aggregator A1, A2 transmits successfully its highest hash value x1, and x2, respectively to the core nodes N0 N1 N2. Thus, S0=S1=S2=x1, x2. Each core node will share its Si to the two other core nodes. All nodes’ resolution module 520 will detect unanimity and x1, x2 will be distributed in the Agreement phase as S*=x1,x2. Once S* has been stored, each core node will be able to compute the current calendar value as usual in the tree module 533 and then distribute the recomputation parameters down to its associated aggregater. If the aggregator does not receive an answer from?its, If an aggregator doesn’t receive an answer from?its within a predetermined period of time, it might follow a failure protocol. This would be: query any other nodes. Failure to get an answer from any node indicates to the aggregator that the request cannot be serviced for this calendar period. It would then need to either resubmit, or simply return to its subordinate gateways, aggregators, and/or clients an “Error message”.
“Example 2”
“The ?worst? “The?worst?” case: The majority of core nodes fail to receive request xi from at least two of S0_ =?., S1_, and S2. After the Distribution phase, all core nodes will realise that it is impossible to return answers to aggregators. After the Agreement phase, all nodes will realize that it is not possible to return any answers to aggregators and will send failure messages down to them.
“Example 3”
“S0=x1, x2; S1=x1; S2=x1, x2. Both values x1 and x2 must reach at least two core nodes. The?consensus can be formed by a majority. S*=x1,x2. This information is then sent to all core nodes (including N1) during the Agreement phase. The current tn calendar value can be computed by all core nodes using the inputs x1 or x2. All clients can still receive digital signatures because there is a consistent recomputation path from each client to the calendar to tn upward.
“Example 4”
“S0=x1; S1=x1; S2=x1, x2. The majority of this set includes only one value x1, x2. S*=x1 in this example means that only x1 is allowed to be used in the calculation of the current calendar value, tn. The error message must be sent to A2 (e.g., by N2) because the x2 value of its associated aggregator does not appear in the final set. Clients below A1 will not receive digital signatures, as they only have a path to tn.
“Example 5”
“S0=x1, x2; S1=x1; S2=x2. Even though the majority does not have the same set, it is still possible to compute the final set. The final set in this example is x1,x2. This is because both x1 (and x2) are elements of two distinct majorities of the sets. Essentially, x1 is an x1 element of S0=x1, S2=x1 and S1=x1. x2 (and x1) is an x1 element of S0=x1 and S2=x1. x2 is an x2 element of S0 and S2=x2=x2=x2=x2=x2=x2=x2=x2x2=x2=x2=x2=x2=x2=x2=2=x2=x2x2=x2=x2x2=x2=x2=x2=x1x1x1x1x1x1x1x1x1x1x2x1x1x1x1x1x1x1x1x1x3x1x1x1x1x1x1x2x2x2x2x2x2x2x2x2x2x1x2x1x1x1x1x1x1x1x2x1x2x1x1x1x1x1x1x2x1x1x2x1x1x1x1x1x1x2x2x1x1x1x1x1x1x1x1x2x2x1x2x1x1x1x1x1x2x1x1x1x2x1x1x1x1x1x2x1x2x1 If N1 has all three sets it can compute the final set S*, and may be able to answer its clients.
“Example 6”
“S0=x1, x2; S1=x1, x2; S2=?. This consensus again states that S*=x1,x2; S1=x1,x2; S2=?. All core nodes can use this data to compute the same number. It is possible to still service clients below A2 even if the connection to N2 has been cut or N2 has suffered other problems. As long as there is an internal recomputation path through a node’s tree (which will be identical to what N2’s tree would be), then a valid data signature can be formed. After receiving all the missing? data, N2 or the connection back to N2 will be able to maintain and store a complete calendar 6000. Any other nodes such as N0, the arbitrator, or N2 will also receive values.
“Example 8”
“S0={? }; S1=x1, x2; S2=?. This is a variation of the “worst?” This is a variant of the?worst? scenario in which there is no majority consensus and all aggregators get error messages.
“Example 9”
“S0=x1, x2; S1=x1, x2; S2=?. N1 can decide that the final set of numbers is S*=x1,x2; S1=x1,x2; S2=?.
“Example 10”
“S0=x2; S1=x1, x2; S2=x1. N1 cannot decide which set is the final one. If S2=x2 then the final sets should be S*=x2. If S2=x1,x2, then S*should be S*=x1. In the present case, N1 doesn’t know S2 so it is impossible for N1 determine what S* is. In such a case, N1 should not answer its clients but should instead follow the recovery protocol for such cases.
“Remember that there will be other cases (switching between x1 andx2 or switching node indexes), or they can be solved using the general rule for majority consensus.
“FIG. “FIG.7 illustrates an infrastructure where a number of aggregators submit higher-level hash value to n core nosdes. Where k>2 or n?k. Although k=4 is shown and n=5, this is only one example. The relationship between k, and n does not have to be the same. Different aggregators (A1-A4) are linked with different nodes in the illustrated embodiment. So A1 is communicating its highest hash value, x1, to N1, N2, N3, and A2; A3 is also communicating with N2 andN3; A3 is also communicating with N2 and the N3; while A4 is communicating with N3 and N4. This is only one example. In the nominal, no-failure scenario, each aggregator Ai can communicate its highest value xi with all nodes N1 through N4, which in turn communicates with each other nodes N2 and N3; A3 is also communicating x3 to nodes N2 and N3; A4 is communicating x4 with nodes N3 and N4.
As before, each aggregator (A1-A4) may be uniquely associated to a particular one of the N1-N4 nodes, for example because it is a process that is running in that node. This is because it has a network connection that is known to be reliable and fast for network administration or any other reason. Each node Ni could also be considered to have its associated aggregator Ai in such an embodiment. A given aggregator Ai may also be able communicate only with Ni. In this case, nodes exchange their values xi among themselves so that Nj learns the value xi from Ni (j?i). This is sometimes referred to as “fixed?” association.”
“It is also possible for aggregators to not have a fixed association to any node. Each aggregator Ai tries to communicate its value to all or selected nodes at least once. This may be called?nonfixed? association. Inter-node exchanges of xi values in such cases may not be necessary or may be performed as a secondary, confirmative, or back-up step.
Each node may be assigned two roles, depending on whether it serves requests from associates (aggregators). If an associate request is not received by a node, that node can assume a support role and serve as backup storage for core nodes. These roles can change depending on whether requests are received by a given node.
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:
- European Patent Office (EPO) provides esp@cenet to access a network of Europe’s patent databases with access to machine translation of European patents.
- Japan Patent Office (JPO) – with access to machine translations of Japanese patents.
- World Intellectual Property Organization (WIPO) offers PATENTSCOPE with a full-text search of published international patent applications and machine translations for some documents, as well as a list of international patent databases.
- Korean Intellectual Property Rights Information Service (KIPRIS)
- State Intellectual Property Office (SIPO) with machine translation of Chinese patents.
- Other International Intellectual Property Offices with online patent databases include Australia, Canada, Denmark, Finland, France, Germany, Great Britain, India, Israel, Netherlands, Norway, Sweden, Switzerland, and Taiwan.
- 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