Blockchain Fintech – Jeffrey Pearce, Guardtime SA
Abstract for “Blockchain-supported device location verification with digital signatures”
“Location data from one of several geolocation engines, such as GPS, which determines the location from relative signal strength or transit times, etc. within and/or connected a device such as a cell phone, vehicle, movable electronic gadget, computer, etc. is included in a Digital Record that was submitted to receive a digital signature so that later it can be proved that the device is present at that particular location. A digital record can contain data that encodes a message and other parameters, such as time. The digital signature encodes the recomputation parameters for a hash-tree signature infrastructure to a highest value. This function is submitted as a transaction on a blockchain.
Background for “Blockchain-supported device location verification with digital signatures”
“It is sometimes necessary for an entity verify the location of a specific device. It could be owned by the entity, an employee, customer, or other person. In some cases, even the user/owner of the device might want to prove his/her location at a particular time.
The device may provide a simple text or graphical indication of its location to the entity. Many smart phones include a built-in GPS engine. This sub-system interfaces with an internal, or network-accessible, mapping routine. The transmitted indication could be spoofed by, for instance, substituting another geolocation.
“In some cases, system administrators?either human or automated?can locate a device using existing technology. Administrators of mobile telephones, in particular, can find a phone (and its SIM card) by sensing its strength at different cell towers. One disadvantage of such known multilateration/hyperbolic capabilities is that they do not provide a method to verify such geolocation information to an acceptable degree of reliability.”
“A system that provides non-repudiable evidence about the location of an entity that can be verified to high levels of reliability is needed.”
“Embodiments enable geolocation of devices with strong verifiability. FIG. FIG. 1 shows one example of a system 100 that can be used to verify the geolocation of any device within the system. FIG. FIG. 1 shows a user of a cell phone 611 and a vehicle communication system 612 as they transmit to reception systems, such as satellites 630 and cell phone towers 612. The invention’s potential uses will increase as wireless devices become more common. It is not required that the device being tracked by the geolocation software according to the embodiments of the invention be mobile. The system can be used to prove that a device has moved beyond or within a boundary. The invention could also be integrated into a remote-controlled device or device that is not subject to human interaction. The term “device” is used for convenience. It can be used to refer to any device that receives data from a geolocation engine, and whose location is to verified using a data signature.”
“FIG. 2. illustrates an embodiment for a mobile device 700 that can determine its current location and request a data signature. The 700 will usually include one or more transceivers 705, or antennas that allow the phone to exchange information with a satellite, cell tower or cell tower (such as to receive GPS signals or signals transmitted from Iridium constellation satellites), etc. Wi-Fi base station and/or similar devices are necessary to fulfill its intended function.
“The 700 has at least one geolocation engine 710 that can compute a current position. The geolocation engine 710, as mentioned above, determines the current location of the device 700 using any or all of the information available to it 700. A GPS receiver and processor is one example of a suitable engine for geolocation. Any known transmitter and/or receiver, and any processing systems that process multiple signals using multi- or trilateration are another example. Cell towers and Wi Fi base stations might have fixed locations. So if 700 is in communication range or connected to a transmitter, it might know that it is within the specified distance of the cell tower or Wi-Fi station to which it’s connected. Geolocation engine 710 can compute the current location using pseudoranges to one of several transmitters with known locations such as satellites, or transmitters with fixed positions on Earth. There are many methods that can be used to estimate the location of a given location using a variety of signals or signal pairs. The geolocation engine is shown in the figures as a single component. However, it is intended to show the combination of hardware and software components that are used to acquire, receive and interpret geolocation data from various sources. In some cases, more than one engine may be represented. The processing software and circuitry used to determine position using multilateration from cell towers will differ from those in a mobile phone’s GPS circuitry.
The invention is capable of accommodating many geolocation systems, including tri- or multilaterations, tri- and multangulations, direct measurement, differential signal arrival time, etc. Tri- and multilateration can be achieved by measuring signal strengths and/or round trip signal transit times to multiple communication towers (such mobile phone towers). One example is the GSM-based telephone system that uses Enhanced Observed Time Difference measurements (E-OTD), which are differences in the arrival times of bursts at base stations. This protocol (RRLP), is used by radio resource location services (LCS). GPS and its algorithms are based on precise times, well-known orbital parameters, and correction signals transmitted from fixed stations within a Differential GPS configuration. Previously, hyperbolic navigation methods like LORAN or DECCA used relative differences in the time-of-arrival of master and slave radio transmitters. Regardless of which geolocation method?or combination of methods?is used in the device 700 by the geolocation engine(s) 710 (which may comprise more than one geolocation mode, such as both GPS and relative signal strength of transmissions between mobile phones and cell tower), what is relevant to embodiments of the invention is that all such systems produce location data that either directly, or after proper processing, provide position information, such as such as latitude/longitude/altitude, other grid coordinates, in any coordinate system, etc. Other information such as satellite or tower IDs, time, signal propagation information and information about the transmission system, such GPS orbital parameters, will be included in location data. The device may include the geolocation engine or may be purchased by the user.
“The concept geo-?location?” Geo-location may also include information about orientation and movement; that is, “location” Any point in an ndimensional parameter space, which does not have to be restricted to an instantaneous location in a fixed, linear coordinate system. Geolocation data may include information about angular positions around x-,y- and/or Z-axes, depending on the algorithms or sensors included in the device 700. This could include roll, pitch, yaw, and/or vs.?rightside up? vs.?rightside down?, velocity?v, acceleration?a (in one direction), position expressed as bearing/range, Cartesian and non-Cartesian coordinates such as lat/long/altitude or hyperbolic coordinates or time-difference coordinates etc. In such cases, signals for such values can be taken from suitable sensors like airspeed or flow sensors or accelerometers. They can also be converted or computed using location difference values, such as changes in GPS-fixed position over a time, etc. In combination with a reliable indication of time (in one embodiment, which is later verifiable), at least one embodiment can establish the device 700’s position for later verification. This may include a verifiable indication or motion and acceleration, etc. Data can also be extracted. For example, flight data recorders (black boxes) might find it useful to extract and sign such information. If so, the signature of the location and other data can be recorded in the data recording or when the recorder case is opened for inspection.”
{“In general, embodiments of the invention may thus accept or compute, as a location data set ?, any or all of n positional or motion vectors such as, for example, ?={(x1 , ?1 , ?1 , ?1 , {dot over (?|”In general, embodiments may accept or compute, in a location data collection??, any or all n positional vectors such ?=(x1 or HTML1_x1.?1??1??1??1??1??1??1??1?.?1??1??1??1??1??1??1 or?1?1?1?1?1?1?1?1?1?1?1?1?1. )}1), . . . {, (xn , ?n , ?n , ?n , . )n)} where x j, ?|, (xn,?n.?n.??n, dot over (???? ). )n?) where x is j} j, ? {j, ?j , j,?j?,?dot over? )j are the j’th position (of any dimension), velocity, acceleration, and rotational velocity and rotational acceleration coordinates, for example, from a j’th geolocation sub-system in the device.|j,?j, dot over (?). )j is the j?th position (of any dimension), velocity/acceleration, rotational velocity and acceleration coordinates, respectively, from a sub-system of the device’s j’th geolocation.} If a mobile phone uses GPS and location based upon multilateration between it, several cell phone towers and other phones, there may be at least two sets, though possibly not with velocity and acceleration data. This data is typically only a small portion of the data submitted as a request to sign.
“In certain embodiments, users of the device 700 may not have access to the data the geolocation engine 710 has. The geolocation engine 710 may have access to information such as identification information for a cell tower or Wi Fi base station, MAC addresses and/or similar. For the purpose of geolocation, the geolocation engine 710 might have access to frames (such GPS frame data or packets transmitted from transmitters with known locations). The geolocation engine 701 may have access to pseudoranges or intermediate calculations that are used by the geolocation engine 710 for determining the current location. These intermediate calculations could include calculations to determine 700’s location and/or calculations that determine transmitter location.
“A signature generation module (720) is designed to create a digital data record, and generate or use an infrastructure such as the one shown in FIGS. 6-10, obtain the digital signature that can be used for verification of the current geolocation 700 at the time the signature was obtained. The digital record could contain additional information that makes it more difficult for an attacker to fake or spoof a location. Digital records could include any lower-level data, such as those generated by the geolocation engine 710 or that are known about it. An attacker may have difficulty determining pseudoranges, Wi-Fi base station identifiers and cell tower identifiers. A calculated position of a moving transmitter and the like might be more difficult.
The general concern is the following: Let’s say that U wants to forge the location of his device to create an alibi at L1. The friend F then compiles and sends to U the location parameters (such GPS coordinates, time, etc.). U then adds his local data (such as his phone SIM) and submits it for signing. U later claims that he was at L2 at the time of t and presents the fake input data along with his signature as proof. You could also fake location data by using a fake GPS signal to fool the device’s GPS engine into generating incorrect data. Although it may not be necessary, it is better to have additional corroborating data such as coordinates or multilateration data derived via secondary sources such as cell towers, multiple times indications such as GPS-derived time, phone network time, GPS time, etc. These data must agree within a certain margin with the signature time. Even though it may not be enough to defeat sophisticated fakers, it will in many cases be more reliable than the prior art, which can, for instance, be used as forensic evidence in a case.
It would also be possible to include in a digital record either pre-stored or computed user-identifying information like a key, password, or other user-input information. If Guardtime’s signing infrastructure is used to create digital Signatures, such a use would not be required of the infrastructure but would be an additional parameter to the signature request to make it more difficult for an attacker to hack, spoof, or fake the request.
“FIG. FIG. 3 shows an alternative embodiment where the signature generation module 755 is embedded in a system outside of the device, but in communication, such as in a base station cell phone 750. The base station 750 may receive any information that the phone requires from the signature generation module 755. This could be done without the user even knowing. The phone could include hardware and software that are necessary to collect and/or combine the information, and send it to signature generation module 755 (although this is not shown).
“As one example of the many additional information that could also be included in your signature request could be any sub-set or all of the GPS frame data used for determining the current location. These words could be useful:
“A digital record can include, just as a few examples of additional arguments in a data input record that relates to the system that generates raw geolocation data, such as:
“If the signature request includes at least some GPS frame parity data (checksum), along with data that the parity bits were derived from, this would increase the difficulty of faking location of the device since it would be a form of ‘built-in? Security algorithm, namely the GPS checksum for received frames or subframes.
“FIG. “FIG. A GPS transmission usually includes a number of data frames (e.g. the data frame 805). Each of these data frames may contain a number of sub-frames (e.g. the sub-frame 810) as well. These sub-frames can contain various types of information that can be used in digital records. A predetermined algorithm may be used to select the frame or sub-frame from where information will be extracted. A frame or subframe that is closest to the time when a position fix was acquired might be chosen. This may also include information about satellites visible to geolocation engines. It may not matter from which frame the information is taken. Digital records may contain information from all transmitting devices.
Different events can be used to trigger the compilation of location data and its signing. A simple trigger event might be the user’s direct request. This could be done by pressing a button or tapping on an icon on the screen. An external source could also trigger the signal that triggers location determination and signature, such as an administrator, law enforcement agency, or an authorized third party (such a parent). Another option would be for the geolocation/signature procedure to be triggered automatically, or periodically, according to a schedule, or, for example, when the device is powered on or off, or when the user accesses or attempts to access or run some feature or application within the device, such as talking a photo, making or receiving a call (possibly from any number or a white or black list), etc., a change in path outside some preset limit, for example, a change in flight path of a plane, change in car route, path, moving outside of or inside of some predetermined boundary, etc. Other triggers include: sensing that a user has been away from (or used) the device for more than a threshold time; sensing that a person has entered / attempted to enter / run some feature or application within the device. Another example of triggers is the detection of a user being away from the device (or using it) for more than a certain time, the detection that a person entered a monitored area, or the detection of an attempt to physically intrude into the device. Note that such trigger events could occur without the knowledge of the user, in which case the geolocation/signature routines may also be run substantially anonymously, as background processes. As long as the event’s occurrence can be detected, it could trigger any other pre-determined or random event.
“Upon sensing a trigger, the signature generation module will input data indicative about a current position from the geolocation engine. This may create the data or retrieve it from an external source. Or both. In response to a trigger event, the signature generator module could submit a query or request to the geolocation engine to obtain the data. The signature generation module may then send commands to an operating platform (e.g. Android, iOS, etc.). Requesting data from the geolocation engine.
“FIG. “FIG.5” 5 shows a flow diagram for a method 900 to sign geolocation information. The method 900 can begin 902 when it is determined that a trigger event has occurred, requiring a signed geolocation. Below are several examples of trigger events. The data, including geolocation parameters and other predetermined arguments, is then accumulated and formatted 904 to form a digital input record that is submitted 906 the signing infrastructure. To enable verification later on, this data record should be stored in the device.
“Depending on how digitally signed input records are created, data that is part of the digital input record must be kept exactly 908. Otherwise, any change in the digital bit or any change of longitude by even a fractional of a second or the smallest deviation in measured signal strength could cause verification failures. While not essential, it is important that the digital input record be able to be used by a third party verifier as a basis. This will increase the reliability of the verification. If the verifier cannot correlate ionospheric data with a given position, it may not be relevant. However, it can still be stored and presented. The idea is that a verifier should have the ability to verify that the data and signature are identical. Additionally, the data should match a geolocation with at least a minimum degree of certainty.
To make it easier for even the most skilled user to modify the digitally signed data, it is better for the signature generation module to extract the geolocation information from the geolocation engine 710. This is best done without any intermediary software or hardware components. The signature generation module 710 and geolocation engine 710 could be combined into one component that can be programmed separately within the device. In some cases, the lower-level data generated by the GPS engine 710 may not be available to the operating systems 725 and 700. Instead, it may be sent raw? ?transferred directly to the signature generation module. 720 as an unprocessed data block. An attacker could then not be able to access at least some of the information in the digital record. To determine the value of the data in the digital record, physical access may be necessary to the hardware.
The digital record may include information from 700, which is part of the signature generation module 720. The signature generation module 720 could include information from the device 700 in the digital record.
The signature generation module 720, which is the executable code that operates the hardware engine(s), extract data and create requests for signatures, may contain sufficient information to allow the device 700 or its SIM card to be identified uniquely. These numbers could include the SIM identifier and/or associated phone number, as well as the serial number and/or a secret number. Number supplied by the manufacturer, or preprogrammed into module 720. In some cases, the signature generation module720 may include a system and geolocation engine 710 times used for computing the digital input record’s geolocation argument. A signature may contain a verifiable indication, depending on the method by which it is generated, of when the signature request was received and/or the date that the signature was generated.
“A digital input record ? may take the general form:\n?=?,M,ID,?,C\nwhere ? is a collection of location data. ID can be any set of data that is optionally included to identify the user, device and/or geolocation source(s), such as GPS satellite identifiers or mobile tower identifiers. ; ? is an optional set data that indicates one or more time measurements; C is any additional optional data included for purposes such as corroboration or administration.
“A parameter M is also shown here for?”. Sometimes, the ability to locate the device at a specific time is not an end in and of itself. It may instead be a message that is associated with another data set M. A user may want to use the system to “location stamp?” A photograph taken using the device or to prove that a document or downloadable app was digitally signed at a specific location. As evidence, location-verified photos (including video-derived), might be more reliable than the current evidence. Customers might feel more confident that the software they download or install is from a trusted and authorized location. This could be combined with other aspects of a digital signature. For example, some countries do not allow the import or export certain types of data files. However, the verifiable geolocation capability in embodiments of the invention might make it possible for reporting and auditing purposes.
“Alongside a reliable date stamp, the system could then verify both the time and the place at which the photo was taken. U.S. patent application Ser. No. No. The combination of the ‘252 and the present invention can create a system that verifies time and place better than anything currently available.
The digital record can be digitally signed by sending it to another party for signature. You have several options to create digital signatures. Common signature schemes use keys issued by a certificate authority. Public Key Infrastructure (PKI), a well-known example, is one such system. Key-based signature schemes have a few problems. Not only do they need to store and manage key sets but they also can expire with the digital certificates. Key-based signature schemes have another disadvantage: they must be trusted by the issuing authority. Another disadvantage of key-based signature systems is their dependence on trust from the issuing authority. They are therefore not quantum immune, meaning they are vulnerable to attacks using quantum-computing systems. While key-based signatures can be used in certain embodiments, there are other more secure and flexible options that use a keyless system for verification of digital certificates.
“In one embodiment, a digital record is? Signed by a distributed, hash-based signing infrastructure, such as Guardtime AS of Tallinn Estonia. This digital signature allows data verification by recomputation of a logically highest value in a Hash Tree. Below is a description of this infrastructure. A storage component 730 (FIG.7) may store the digital record, digital signature and/or highest hash tree value. 10) in the device 700 or in any other entity (FIG. An entity can verify the authenticity of the digital records by providing a purportedly authentic copy or original along with the data signature. The entity can then recompute the highest hash tree value from both the digital signatures and digital records to confirm that the digital records are authentic. You may be able to verify the date the digital record was signed using the digital signature and/or the uppermost hash tree value.
“Hash Tree-Based and Keyless Signature Infrastructure”
“FIG. “FIG. 6” illustrates the hash-tree infrastructure (the?Guardtime sign infrastructure? Guardtime As of Tallinn (Estonia) developed this infrastructure and it is disclosed in U.S. Pat. Nos. 8,347.372; 8,312,528 and 7,698,557 (all Buldas et al.?System and Method for Generating a Digital Certificate? U.S. Pat. No. No. All of these are incorporated by reference. The hash tree infrastructure at Bildas “576 can be used not only to generate signatures 500 but also as a timestamping mechanism for any number of clients 2000. The main features of Guardtime’s signing infrastructure are listed here with reference to FIG. 7.”
“In the contexts of embodiments this invention, either 700 may be a client or connected to a system that acts or is a client with which the device communicates. For example, a server that receives data via an LTE eNodeB or base transceiver station, (BTS), or any other type server that receives or processes signals from 700.”
Guardtime’s hash tree infrastructure requires that the Guardtime does not rely on public/private keys like RSA. This is except for temporary user or client identification during a session and optionally until publication. They can be lost or stolen; they are dependent on a trust authority (in this case a Certificate Authority) that issues them; they need to be stored and maintained which makes them less secure than hash function keys. They may have embedded code or be generated by pseudo-random number seeding programs. This makes them unknowable to users.
The general Guardtime infrastructure consists of several layers. A client layer 2000 includes a number client systems, a layer with gateways 3000, a layer that includes one or more aggregation system 4000, and an uppermost layer 5000 which includes a core. The core, gateways, and aggregators will typically be servers with known network connections.
“The client systems can also be servers but depending on how they are implemented, some or all of them may also include individualized workstations or laptops. The mobile device 700 could be part of or associated with one of these client systems. Any system that allows for the representation of any type information to be input, created, or presented in digital form (with or without human intervention) may be called a client 2000. It can also be used to register the invention using the infrastructure. In the illustrated arrangement, a client is the system where digital records are prepared and entered into the verification/signature system. Any set of binary data can be considered a digital record if it is deemed necessary to verify that the information has not changed after initial registration and signature using infrastructure.
“Although FIG. FIG. 6 clearly shows the different layers, but some implementations might combine or remove some layers. Or might require additional layers to support administrative or other purposes. A gateway at layer 3000 is typically a computer system, such as a server, with which clients can communicate to register digital records submitted by their clients. A gateway in the layer 4000 aggregator will be similar. It is a computer system that receives registration requests after they have been consolidated by their respective gateways. Although the distinction between gateways and aggregators is often dependent on which entity controls them, this is not always necessary. In some cases there are no functional or control differences between the two systems.
“In FIG. FIG. 7. Different clients are represented as 2010-1. . . 2010-n gateways are represented by 3010-1 and 3010-2. . . , 3010 -m; and two aggregaters are shown as 4010-1 and 4010-k. As described below, an aggregator will usually communicate with a lower level core hash tree node. FIG. shows only two aggregators. 7. This is for simplicity’s sake.
“Each client system 2000 may be loaded with software packages or routines to facilitate or even automatic communication and submission. Digital information. The client system 2000 could be the client 200 in the context of the invention. A software package may contain an application program interface (API 2014) that converts digital records submitted into a suitable form for processing. The API 2014 is used to submit a digital record 2012 to a 2016 software module that uses the digital data of the record 2012 as at most one argument in a 2018 transformation function such as a hash operation.
The gateway 3010-2 illustrates the data structure of a binary tree. The gateway hash tree’s lowest nodes will correspond to the 2018 transformed dataset submitted by a client as a request REQ. 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. This is 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.
“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 tree node 5001, the core will compute a single core hash value. . . , tn. This is also known as the ‘calendar value’. ci, or the?current calendar value? for the time interval, ti. Calendar values can be calculated according to precise time values. For example, one calendar value every 1.0 s. Each calendar value will then be a precise representation. Each digital signature that is issued within a calendar interval will be intrinsically and reliably tied to a specific calendar value. This time association is almost impossible to fake due to the non-invertible nature cryptographic hash function.
“If the signature request contains a time parameter such as the time that the device clock 715 is running, this can be later compared to the requested calendar time. This may indicate that the device’s time is different from the requested calendar time by a reasonable amount (taking into account signal and network propagation delays) or some other parameter. The data comprising the request was received much later than the others. This is not suspicious. It is possible to determine the relationship between calendar values, the time used by transmitters with known locations, and/or the processing delay for signature generation module 720 or the signing infrastructure.
“Remember that the root node at the top of the tree 5001 is the root node in the entire tree structure. This will change if a new uppermost hash value is recomputationed at the end the next period of accumulating request and generating signature vectors. (also known as “data signatures?”). containing recomputation parameters. FIG. 9 shows one configuration of Guardtime signature infrastructure. 9 The core system 5000, which is illustrated in FIG. Tp by using a Merkle haveh tree 7002(FIG. Tp using a Merkle hash tree 7002 (FIG. The combined uppermost hash value might be published periodically in a substantially unalterable medium 7000. This could be a newspaper or publicly accessible web site or database, or any internal publication. It would then be virtually impossible to alter or retrieve every newspaper that was distributed to the public.
“In FIG. 7 are designated with an ‘X? on certain hash tree nodes of the gateway 3010-2, aggregator 4010-1 and core 5000. If one follows the tree paths upward starting at the 2018 value in the client 2010, it is possible to calculate every value up in the tree structures, all the way to 5001 given the values of the X-marked nodes (the’siblings?). The nodes in the direct recomputation pathway and the hash functions at each parent node. If a signature is associated to the digital record 2012, it must include all of the?X?marked? If the digital input record 2012 includes all the?X-marked values, then recomputation of the hash value upwards through all the tree structures will yield exactly the same value as the current calendar value. However, this is only true if the original digital record’s starting 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.
“The sibling hash value set, together with any additional information, such as order (since most cryptographic hash function are not commutative), which enable recomputation the corresponding calendar values, may be returned to client system as signature 8000 (FIG. 8 for the digital input. This signature can be later extended by the sibling values in the core’s Merkle haveh tree, which allow recomputation all through the infrastructure up to the highest hash value 7001 for the corresponding calendar year. FIG. FIG. 10 illustrates the use of this option. In which case, the?X?marked? Sibling values may be extended by the?E?marked? sibling values can be extended with the?E-marked? to allow recomputation up to the published value 7001. It will be impossible to alter any input after that point.
“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 digital record 2012. The candidate digital record should be transformed using the same 2016 transformation and the same data signature to compute upward. This will allow the entity to calculate the exact same publication value 7001 as the original digital record request.
“Applying the signature solution in this context, suppose that an entity claims that a data file? is its. * is the same data record?. This could be the original dataset? stored within the storage component 730 on the device 700 and/or another copy stored by a different entity. The digital signature for? may be stored locally, in storage 730 and/or externally.” The digital signature for? may be stored in storage 730 and/or externally.
“Let’s say, for example, that a user states?This device was located at L at the time t? and that information is included in? * is proof. This raises the question of whether or not this is true. For the device with identity ID at the time?. With? With????? * and the digital signature from the signature infrastructure to?, a verifier is able to recompute each chain of hash value?upward? to a final, uppermost value. This can be done offline, and may not require querying the signing infrastructure once again depending on the implementation. ? * will be the same as? Only if recomputation results in the identical calendar value, or, if signature was extended to the correct published value 7001, then * will be the same as? As shown in FIGS. 6-10, the Guardtime signing infrastructure is used. FIGS. 6-10 show how to use the Guardtime signing infrastructure. This can be done without the need for keys and in some cases offline. Assuming all hash functions have been specified or are known, it is possible to do this without relying on keys. The signatures are not created within clients, which can be more vulnerable to malicious manipulation or attacks, but instead within external entities. In other words, the Guardtime infrastructure creates data signatures server-side, though with client-input data records as the basis.
“FIG. FIG. 11 shows how the hash tree signing infrastructure for FIGS. Geolocation data can be added to 6-10. Or maybe only? This data can be entered and hashed into the tree within the hash subtree of one or more gateways and/or aggregaters for the current calendar period. A node may include an identifier ID for each gateway/aggregator. In the data signatures of every data record that has the?location node, the geolocation data for the current period will be included. 9010 (with and without any other data) is a sibling of the recomputation path. This is for all signatures submitted by clients via nodes below node 9012 marked “*?” FIG. 11.”
FIG. 11 shows another consequence to the embodiment. 11. is that the server/gateway/aggregator becomes the device 700 whose position is established. The gateway/aggregator could also request and obtain a digital signature to its own geolocation data. The location signatures can then be stored at the sever or sent to another entity for verification.
“The various operations described in the geolocation component 710, such as extracting and compiling data, submitting it to signature, receiving and storing signatures, etc. will be executed, for instance, in one or more processors (FIG. 10, the executable code may be executed under the guidance of system software, such as an operating program 725. It may be stored in a nontransitory volatile or non-volatile computer readable medium, such as the memory/storage part 730. This storage technology can be used with any combination of technologies. The code that incorporates the various embodiments of the invention can be included in the device 700 at time of manufacture and initial configuration of software, or it may be installed later as a computer program product. FIGS. FIGS. 4 and 5 show how calendar values from a given period are combined in the Merkle to create a composite value that can be published in an unalterable medium.
“FIGS. “FIGS.12 and 13 show an embodiment where the?medium?” A data structure that is easily visible and can be tampered with without detection. A?blockchain’ is one example of such a data structure. 9000. Although the term “blockchain” is not widely accepted, Although the term?blockchain? and related terms do not have an accepted definition, a?blockchain is a data structure that is typically used to describe a block chain. is a data structure that consists of a number of blocks bi, which are usually time-stamped. . . , bj, bj+1, bj+2, bj+3, . . . Each block contains data that corresponds to one or more transactions. The data is hashed together and linked data such as the hash output of the block immediately before it. This chain can be used to create the public ledger. It is usually an append-only database created by distributed consensus among multiple participants. The entry of data into a block in the chain is irrefutable. Any tampering would be reflected on the chained hash calculations, and thus can easily be detected.
The concept of a “blockchain” is a current topic of disagreement. The question of whether any entity can submit blocks to the blockchain and verify them is a matter of dispute. This may depend on meeting some proof-of work requirements (e.g. Bitcoin’s mining?). ) or whether entities that can submit to and verify the blocks in the datastructure must be authorized by a central authority. Also, it is not clear whether “blockchain” means “open?” By definition, ‘blockchain? implies?open? Or not. “Embodiments of this invention don’t presuppose, or require either definition.”
“In FIG. “In FIG. 12, the composite calendar value of each calendar period is entered using any appropriate mechanism. This could include proof-of-work or multi-entity consensus. In the case of open blockchains, trust will not be required for any entity, even if they present a copy of a newspaper or keep a database.
“Some blockchains require a non-trivial settlement period. An example is that a Bitcoin blockchain update may take up to ten minutes before it can be accepted. It may be more convenient to combine several calendar values into one transaction. As shown in FIG. 12, the composite calendar value that forms the root of Merkle tree in core 5000 is one way to accomplish this. 12 is a consolidation of multiple calendar values. The transaction submitted at each end of each period Tp may then be considered the composite value. According to the blockchain settlement time, the period Tp can be adjusted.”
“Assuming that the blockchain can be added quickly enough, it would be possible to submit each calendar values as a separate transaction on the blockchain. FIG. 13. These cases may be a good example of why a Merkle Tree to consolidate calendar value into a composite value is not necessary. In essence, the blockchain could fulfill the function of the calendar.
“Regardless of the value (each calendar or composite calendar) submitted as blockchain transactions signatures may be extended to include parameters identifying the transaction, that is block, in which the input’s calendar value was part. Given a purportedly true copy of the original input record, its corresponding signature, and this blockchain-identifying information, one would then be able to verify the signature up to the level of the calendar value, and onward to the blockchain, thereby totally verifying (or confirming alteration of) the input record.”
“Embodiments can also be used for geofencing. A schedule or administrator may trigger the device to request a signature to verify its current location. The signature value may be added to the blockchain as a calendar value or as part the core-level Merkle Tree computation, thereby creating an irrefutable record that contains the location data encoded within the signature. If the location determined is outside or within a boundary (for instance, defined as a threshold distance from an “allowed”? Or?operational? central point), or?operational?
Summary for “Blockchain-supported device location verification with digital signatures”
“It is sometimes necessary for an entity verify the location of a specific device. It could be owned by the entity, an employee, customer, or other person. In some cases, even the user/owner of the device might want to prove his/her location at a particular time.
The device may provide a simple text or graphical indication of its location to the entity. Many smart phones include a built-in GPS engine. This sub-system interfaces with an internal, or network-accessible, mapping routine. The transmitted indication could be spoofed by, for instance, substituting another geolocation.
“In some cases, system administrators?either human or automated?can locate a device using existing technology. Administrators of mobile telephones, in particular, can find a phone (and its SIM card) by sensing its strength at different cell towers. One disadvantage of such known multilateration/hyperbolic capabilities is that they do not provide a method to verify such geolocation information to an acceptable degree of reliability.”
“A system that provides non-repudiable evidence about the location of an entity that can be verified to high levels of reliability is needed.”
“Embodiments enable geolocation of devices with strong verifiability. FIG. FIG. 1 shows one example of a system 100 that can be used to verify the geolocation of any device within the system. FIG. FIG. 1 shows a user of a cell phone 611 and a vehicle communication system 612 as they transmit to reception systems, such as satellites 630 and cell phone towers 612. The invention’s potential uses will increase as wireless devices become more common. It is not required that the device being tracked by the geolocation software according to the embodiments of the invention be mobile. The system can be used to prove that a device has moved beyond or within a boundary. The invention could also be integrated into a remote-controlled device or device that is not subject to human interaction. The term “device” is used for convenience. It can be used to refer to any device that receives data from a geolocation engine, and whose location is to verified using a data signature.”
“FIG. 2. illustrates an embodiment for a mobile device 700 that can determine its current location and request a data signature. The 700 will usually include one or more transceivers 705, or antennas that allow the phone to exchange information with a satellite, cell tower or cell tower (such as to receive GPS signals or signals transmitted from Iridium constellation satellites), etc. Wi-Fi base station and/or similar devices are necessary to fulfill its intended function.
“The 700 has at least one geolocation engine 710 that can compute a current position. The geolocation engine 710, as mentioned above, determines the current location of the device 700 using any or all of the information available to it 700. A GPS receiver and processor is one example of a suitable engine for geolocation. Any known transmitter and/or receiver, and any processing systems that process multiple signals using multi- or trilateration are another example. Cell towers and Wi Fi base stations might have fixed locations. So if 700 is in communication range or connected to a transmitter, it might know that it is within the specified distance of the cell tower or Wi-Fi station to which it’s connected. Geolocation engine 710 can compute the current location using pseudoranges to one of several transmitters with known locations such as satellites, or transmitters with fixed positions on Earth. There are many methods that can be used to estimate the location of a given location using a variety of signals or signal pairs. The geolocation engine is shown in the figures as a single component. However, it is intended to show the combination of hardware and software components that are used to acquire, receive and interpret geolocation data from various sources. In some cases, more than one engine may be represented. The processing software and circuitry used to determine position using multilateration from cell towers will differ from those in a mobile phone’s GPS circuitry.
The invention is capable of accommodating many geolocation systems, including tri- or multilaterations, tri- and multangulations, direct measurement, differential signal arrival time, etc. Tri- and multilateration can be achieved by measuring signal strengths and/or round trip signal transit times to multiple communication towers (such mobile phone towers). One example is the GSM-based telephone system that uses Enhanced Observed Time Difference measurements (E-OTD), which are differences in the arrival times of bursts at base stations. This protocol (RRLP), is used by radio resource location services (LCS). GPS and its algorithms are based on precise times, well-known orbital parameters, and correction signals transmitted from fixed stations within a Differential GPS configuration. Previously, hyperbolic navigation methods like LORAN or DECCA used relative differences in the time-of-arrival of master and slave radio transmitters. Regardless of which geolocation method?or combination of methods?is used in the device 700 by the geolocation engine(s) 710 (which may comprise more than one geolocation mode, such as both GPS and relative signal strength of transmissions between mobile phones and cell tower), what is relevant to embodiments of the invention is that all such systems produce location data that either directly, or after proper processing, provide position information, such as such as latitude/longitude/altitude, other grid coordinates, in any coordinate system, etc. Other information such as satellite or tower IDs, time, signal propagation information and information about the transmission system, such GPS orbital parameters, will be included in location data. The device may include the geolocation engine or may be purchased by the user.
“The concept geo-?location?” Geo-location may also include information about orientation and movement; that is, “location” Any point in an ndimensional parameter space, which does not have to be restricted to an instantaneous location in a fixed, linear coordinate system. Geolocation data may include information about angular positions around x-,y- and/or Z-axes, depending on the algorithms or sensors included in the device 700. This could include roll, pitch, yaw, and/or vs.?rightside up? vs.?rightside down?, velocity?v, acceleration?a (in one direction), position expressed as bearing/range, Cartesian and non-Cartesian coordinates such as lat/long/altitude or hyperbolic coordinates or time-difference coordinates etc. In such cases, signals for such values can be taken from suitable sensors like airspeed or flow sensors or accelerometers. They can also be converted or computed using location difference values, such as changes in GPS-fixed position over a time, etc. In combination with a reliable indication of time (in one embodiment, which is later verifiable), at least one embodiment can establish the device 700’s position for later verification. This may include a verifiable indication or motion and acceleration, etc. Data can also be extracted. For example, flight data recorders (black boxes) might find it useful to extract and sign such information. If so, the signature of the location and other data can be recorded in the data recording or when the recorder case is opened for inspection.”
{“In general, embodiments of the invention may thus accept or compute, as a location data set ?, any or all of n positional or motion vectors such as, for example, ?={(x1 , ?1 , ?1 , ?1 , {dot over (?|”In general, embodiments may accept or compute, in a location data collection??, any or all n positional vectors such ?=(x1 or HTML1_x1.?1??1??1??1??1??1??1??1?.?1??1??1??1??1??1??1 or?1?1?1?1?1?1?1?1?1?1?1?1?1. )}1), . . . {, (xn , ?n , ?n , ?n , . )n)} where x j, ?|, (xn,?n.?n.??n, dot over (???? ). )n?) where x is j} j, ? {j, ?j , j,?j?,?dot over? )j are the j’th position (of any dimension), velocity, acceleration, and rotational velocity and rotational acceleration coordinates, for example, from a j’th geolocation sub-system in the device.|j,?j, dot over (?). )j is the j?th position (of any dimension), velocity/acceleration, rotational velocity and acceleration coordinates, respectively, from a sub-system of the device’s j’th geolocation.} If a mobile phone uses GPS and location based upon multilateration between it, several cell phone towers and other phones, there may be at least two sets, though possibly not with velocity and acceleration data. This data is typically only a small portion of the data submitted as a request to sign.
“In certain embodiments, users of the device 700 may not have access to the data the geolocation engine 710 has. The geolocation engine 710 may have access to information such as identification information for a cell tower or Wi Fi base station, MAC addresses and/or similar. For the purpose of geolocation, the geolocation engine 710 might have access to frames (such GPS frame data or packets transmitted from transmitters with known locations). The geolocation engine 701 may have access to pseudoranges or intermediate calculations that are used by the geolocation engine 710 for determining the current location. These intermediate calculations could include calculations to determine 700’s location and/or calculations that determine transmitter location.
“A signature generation module (720) is designed to create a digital data record, and generate or use an infrastructure such as the one shown in FIGS. 6-10, obtain the digital signature that can be used for verification of the current geolocation 700 at the time the signature was obtained. The digital record could contain additional information that makes it more difficult for an attacker to fake or spoof a location. Digital records could include any lower-level data, such as those generated by the geolocation engine 710 or that are known about it. An attacker may have difficulty determining pseudoranges, Wi-Fi base station identifiers and cell tower identifiers. A calculated position of a moving transmitter and the like might be more difficult.
The general concern is the following: Let’s say that U wants to forge the location of his device to create an alibi at L1. The friend F then compiles and sends to U the location parameters (such GPS coordinates, time, etc.). U then adds his local data (such as his phone SIM) and submits it for signing. U later claims that he was at L2 at the time of t and presents the fake input data along with his signature as proof. You could also fake location data by using a fake GPS signal to fool the device’s GPS engine into generating incorrect data. Although it may not be necessary, it is better to have additional corroborating data such as coordinates or multilateration data derived via secondary sources such as cell towers, multiple times indications such as GPS-derived time, phone network time, GPS time, etc. These data must agree within a certain margin with the signature time. Even though it may not be enough to defeat sophisticated fakers, it will in many cases be more reliable than the prior art, which can, for instance, be used as forensic evidence in a case.
It would also be possible to include in a digital record either pre-stored or computed user-identifying information like a key, password, or other user-input information. If Guardtime’s signing infrastructure is used to create digital Signatures, such a use would not be required of the infrastructure but would be an additional parameter to the signature request to make it more difficult for an attacker to hack, spoof, or fake the request.
“FIG. FIG. 3 shows an alternative embodiment where the signature generation module 755 is embedded in a system outside of the device, but in communication, such as in a base station cell phone 750. The base station 750 may receive any information that the phone requires from the signature generation module 755. This could be done without the user even knowing. The phone could include hardware and software that are necessary to collect and/or combine the information, and send it to signature generation module 755 (although this is not shown).
“As one example of the many additional information that could also be included in your signature request could be any sub-set or all of the GPS frame data used for determining the current location. These words could be useful:
“A digital record can include, just as a few examples of additional arguments in a data input record that relates to the system that generates raw geolocation data, such as:
“If the signature request includes at least some GPS frame parity data (checksum), along with data that the parity bits were derived from, this would increase the difficulty of faking location of the device since it would be a form of ‘built-in? Security algorithm, namely the GPS checksum for received frames or subframes.
“FIG. “FIG. A GPS transmission usually includes a number of data frames (e.g. the data frame 805). Each of these data frames may contain a number of sub-frames (e.g. the sub-frame 810) as well. These sub-frames can contain various types of information that can be used in digital records. A predetermined algorithm may be used to select the frame or sub-frame from where information will be extracted. A frame or subframe that is closest to the time when a position fix was acquired might be chosen. This may also include information about satellites visible to geolocation engines. It may not matter from which frame the information is taken. Digital records may contain information from all transmitting devices.
Different events can be used to trigger the compilation of location data and its signing. A simple trigger event might be the user’s direct request. This could be done by pressing a button or tapping on an icon on the screen. An external source could also trigger the signal that triggers location determination and signature, such as an administrator, law enforcement agency, or an authorized third party (such a parent). Another option would be for the geolocation/signature procedure to be triggered automatically, or periodically, according to a schedule, or, for example, when the device is powered on or off, or when the user accesses or attempts to access or run some feature or application within the device, such as talking a photo, making or receiving a call (possibly from any number or a white or black list), etc., a change in path outside some preset limit, for example, a change in flight path of a plane, change in car route, path, moving outside of or inside of some predetermined boundary, etc. Other triggers include: sensing that a user has been away from (or used) the device for more than a threshold time; sensing that a person has entered / attempted to enter / run some feature or application within the device. Another example of triggers is the detection of a user being away from the device (or using it) for more than a certain time, the detection that a person entered a monitored area, or the detection of an attempt to physically intrude into the device. Note that such trigger events could occur without the knowledge of the user, in which case the geolocation/signature routines may also be run substantially anonymously, as background processes. As long as the event’s occurrence can be detected, it could trigger any other pre-determined or random event.
“Upon sensing a trigger, the signature generation module will input data indicative about a current position from the geolocation engine. This may create the data or retrieve it from an external source. Or both. In response to a trigger event, the signature generator module could submit a query or request to the geolocation engine to obtain the data. The signature generation module may then send commands to an operating platform (e.g. Android, iOS, etc.). Requesting data from the geolocation engine.
“FIG. “FIG.5” 5 shows a flow diagram for a method 900 to sign geolocation information. The method 900 can begin 902 when it is determined that a trigger event has occurred, requiring a signed geolocation. Below are several examples of trigger events. The data, including geolocation parameters and other predetermined arguments, is then accumulated and formatted 904 to form a digital input record that is submitted 906 the signing infrastructure. To enable verification later on, this data record should be stored in the device.
“Depending on how digitally signed input records are created, data that is part of the digital input record must be kept exactly 908. Otherwise, any change in the digital bit or any change of longitude by even a fractional of a second or the smallest deviation in measured signal strength could cause verification failures. While not essential, it is important that the digital input record be able to be used by a third party verifier as a basis. This will increase the reliability of the verification. If the verifier cannot correlate ionospheric data with a given position, it may not be relevant. However, it can still be stored and presented. The idea is that a verifier should have the ability to verify that the data and signature are identical. Additionally, the data should match a geolocation with at least a minimum degree of certainty.
To make it easier for even the most skilled user to modify the digitally signed data, it is better for the signature generation module to extract the geolocation information from the geolocation engine 710. This is best done without any intermediary software or hardware components. The signature generation module 710 and geolocation engine 710 could be combined into one component that can be programmed separately within the device. In some cases, the lower-level data generated by the GPS engine 710 may not be available to the operating systems 725 and 700. Instead, it may be sent raw? ?transferred directly to the signature generation module. 720 as an unprocessed data block. An attacker could then not be able to access at least some of the information in the digital record. To determine the value of the data in the digital record, physical access may be necessary to the hardware.
The digital record may include information from 700, which is part of the signature generation module 720. The signature generation module 720 could include information from the device 700 in the digital record.
The signature generation module 720, which is the executable code that operates the hardware engine(s), extract data and create requests for signatures, may contain sufficient information to allow the device 700 or its SIM card to be identified uniquely. These numbers could include the SIM identifier and/or associated phone number, as well as the serial number and/or a secret number. Number supplied by the manufacturer, or preprogrammed into module 720. In some cases, the signature generation module720 may include a system and geolocation engine 710 times used for computing the digital input record’s geolocation argument. A signature may contain a verifiable indication, depending on the method by which it is generated, of when the signature request was received and/or the date that the signature was generated.
“A digital input record ? may take the general form:\n?=?,M,ID,?,C\nwhere ? is a collection of location data. ID can be any set of data that is optionally included to identify the user, device and/or geolocation source(s), such as GPS satellite identifiers or mobile tower identifiers. ; ? is an optional set data that indicates one or more time measurements; C is any additional optional data included for purposes such as corroboration or administration.
“A parameter M is also shown here for?”. Sometimes, the ability to locate the device at a specific time is not an end in and of itself. It may instead be a message that is associated with another data set M. A user may want to use the system to “location stamp?” A photograph taken using the device or to prove that a document or downloadable app was digitally signed at a specific location. As evidence, location-verified photos (including video-derived), might be more reliable than the current evidence. Customers might feel more confident that the software they download or install is from a trusted and authorized location. This could be combined with other aspects of a digital signature. For example, some countries do not allow the import or export certain types of data files. However, the verifiable geolocation capability in embodiments of the invention might make it possible for reporting and auditing purposes.
“Alongside a reliable date stamp, the system could then verify both the time and the place at which the photo was taken. U.S. patent application Ser. No. No. The combination of the ‘252 and the present invention can create a system that verifies time and place better than anything currently available.
The digital record can be digitally signed by sending it to another party for signature. You have several options to create digital signatures. Common signature schemes use keys issued by a certificate authority. Public Key Infrastructure (PKI), a well-known example, is one such system. Key-based signature schemes have a few problems. Not only do they need to store and manage key sets but they also can expire with the digital certificates. Key-based signature schemes have another disadvantage: they must be trusted by the issuing authority. Another disadvantage of key-based signature systems is their dependence on trust from the issuing authority. They are therefore not quantum immune, meaning they are vulnerable to attacks using quantum-computing systems. While key-based signatures can be used in certain embodiments, there are other more secure and flexible options that use a keyless system for verification of digital certificates.
“In one embodiment, a digital record is? Signed by a distributed, hash-based signing infrastructure, such as Guardtime AS of Tallinn Estonia. This digital signature allows data verification by recomputation of a logically highest value in a Hash Tree. Below is a description of this infrastructure. A storage component 730 (FIG.7) may store the digital record, digital signature and/or highest hash tree value. 10) in the device 700 or in any other entity (FIG. An entity can verify the authenticity of the digital records by providing a purportedly authentic copy or original along with the data signature. The entity can then recompute the highest hash tree value from both the digital signatures and digital records to confirm that the digital records are authentic. You may be able to verify the date the digital record was signed using the digital signature and/or the uppermost hash tree value.
“Hash Tree-Based and Keyless Signature Infrastructure”
“FIG. “FIG. 6” illustrates the hash-tree infrastructure (the?Guardtime sign infrastructure? Guardtime As of Tallinn (Estonia) developed this infrastructure and it is disclosed in U.S. Pat. Nos. 8,347.372; 8,312,528 and 7,698,557 (all Buldas et al.?System and Method for Generating a Digital Certificate? U.S. Pat. No. No. All of these are incorporated by reference. The hash tree infrastructure at Bildas “576 can be used not only to generate signatures 500 but also as a timestamping mechanism for any number of clients 2000. The main features of Guardtime’s signing infrastructure are listed here with reference to FIG. 7.”
“In the contexts of embodiments this invention, either 700 may be a client or connected to a system that acts or is a client with which the device communicates. For example, a server that receives data via an LTE eNodeB or base transceiver station, (BTS), or any other type server that receives or processes signals from 700.”
Guardtime’s hash tree infrastructure requires that the Guardtime does not rely on public/private keys like RSA. This is except for temporary user or client identification during a session and optionally until publication. They can be lost or stolen; they are dependent on a trust authority (in this case a Certificate Authority) that issues them; they need to be stored and maintained which makes them less secure than hash function keys. They may have embedded code or be generated by pseudo-random number seeding programs. This makes them unknowable to users.
The general Guardtime infrastructure consists of several layers. A client layer 2000 includes a number client systems, a layer with gateways 3000, a layer that includes one or more aggregation system 4000, and an uppermost layer 5000 which includes a core. The core, gateways, and aggregators will typically be servers with known network connections.
“The client systems can also be servers but depending on how they are implemented, some or all of them may also include individualized workstations or laptops. The mobile device 700 could be part of or associated with one of these client systems. Any system that allows for the representation of any type information to be input, created, or presented in digital form (with or without human intervention) may be called a client 2000. It can also be used to register the invention using the infrastructure. In the illustrated arrangement, a client is the system where digital records are prepared and entered into the verification/signature system. Any set of binary data can be considered a digital record if it is deemed necessary to verify that the information has not changed after initial registration and signature using infrastructure.
“Although FIG. FIG. 6 clearly shows the different layers, but some implementations might combine or remove some layers. Or might require additional layers to support administrative or other purposes. A gateway at layer 3000 is typically a computer system, such as a server, with which clients can communicate to register digital records submitted by their clients. A gateway in the layer 4000 aggregator will be similar. It is a computer system that receives registration requests after they have been consolidated by their respective gateways. Although the distinction between gateways and aggregators is often dependent on which entity controls them, this is not always necessary. In some cases there are no functional or control differences between the two systems.
“In FIG. FIG. 7. Different clients are represented as 2010-1. . . 2010-n gateways are represented by 3010-1 and 3010-2. . . , 3010 -m; and two aggregaters are shown as 4010-1 and 4010-k. As described below, an aggregator will usually communicate with a lower level core hash tree node. FIG. shows only two aggregators. 7. This is for simplicity’s sake.
“Each client system 2000 may be loaded with software packages or routines to facilitate or even automatic communication and submission. Digital information. The client system 2000 could be the client 200 in the context of the invention. A software package may contain an application program interface (API 2014) that converts digital records submitted into a suitable form for processing. The API 2014 is used to submit a digital record 2012 to a 2016 software module that uses the digital data of the record 2012 as at most one argument in a 2018 transformation function such as a hash operation.
The gateway 3010-2 illustrates the data structure of a binary tree. The gateway hash tree’s lowest nodes will correspond to the 2018 transformed dataset submitted by a client as a request REQ. 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. This is 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.
“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 tree node 5001, the core will compute a single core hash value. . . , tn. This is also known as the ‘calendar value’. ci, or the?current calendar value? for the time interval, ti. Calendar values can be calculated according to precise time values. For example, one calendar value every 1.0 s. Each calendar value will then be a precise representation. Each digital signature that is issued within a calendar interval will be intrinsically and reliably tied to a specific calendar value. This time association is almost impossible to fake due to the non-invertible nature cryptographic hash function.
“If the signature request contains a time parameter such as the time that the device clock 715 is running, this can be later compared to the requested calendar time. This may indicate that the device’s time is different from the requested calendar time by a reasonable amount (taking into account signal and network propagation delays) or some other parameter. The data comprising the request was received much later than the others. This is not suspicious. It is possible to determine the relationship between calendar values, the time used by transmitters with known locations, and/or the processing delay for signature generation module 720 or the signing infrastructure.
“Remember that the root node at the top of the tree 5001 is the root node in the entire tree structure. This will change if a new uppermost hash value is recomputationed at the end the next period of accumulating request and generating signature vectors. (also known as “data signatures?”). containing recomputation parameters. FIG. 9 shows one configuration of Guardtime signature infrastructure. 9 The core system 5000, which is illustrated in FIG. Tp by using a Merkle haveh tree 7002(FIG. Tp using a Merkle hash tree 7002 (FIG. The combined uppermost hash value might be published periodically in a substantially unalterable medium 7000. This could be a newspaper or publicly accessible web site or database, or any internal publication. It would then be virtually impossible to alter or retrieve every newspaper that was distributed to the public.
“In FIG. 7 are designated with an ‘X? on certain hash tree nodes of the gateway 3010-2, aggregator 4010-1 and core 5000. If one follows the tree paths upward starting at the 2018 value in the client 2010, it is possible to calculate every value up in the tree structures, all the way to 5001 given the values of the X-marked nodes (the’siblings?). The nodes in the direct recomputation pathway and the hash functions at each parent node. If a signature is associated to the digital record 2012, it must include all of the?X?marked? If the digital input record 2012 includes all the?X-marked values, then recomputation of the hash value upwards through all the tree structures will yield exactly the same value as the current calendar value. However, this is only true if the original digital record’s starting 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.
“The sibling hash value set, together with any additional information, such as order (since most cryptographic hash function are not commutative), which enable recomputation the corresponding calendar values, may be returned to client system as signature 8000 (FIG. 8 for the digital input. This signature can be later extended by the sibling values in the core’s Merkle haveh tree, which allow recomputation all through the infrastructure up to the highest hash value 7001 for the corresponding calendar year. FIG. FIG. 10 illustrates the use of this option. In which case, the?X?marked? Sibling values may be extended by the?E?marked? sibling values can be extended with the?E-marked? to allow recomputation up to the published value 7001. It will be impossible to alter any input after that point.
“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 digital record 2012. The candidate digital record should be transformed using the same 2016 transformation and the same data signature to compute upward. This will allow the entity to calculate the exact same publication value 7001 as the original digital record request.
“Applying the signature solution in this context, suppose that an entity claims that a data file? is its. * is the same data record?. This could be the original dataset? stored within the storage component 730 on the device 700 and/or another copy stored by a different entity. The digital signature for? may be stored locally, in storage 730 and/or externally.” The digital signature for? may be stored in storage 730 and/or externally.
“Let’s say, for example, that a user states?This device was located at L at the time t? and that information is included in? * is proof. This raises the question of whether or not this is true. For the device with identity ID at the time?. With? With????? * and the digital signature from the signature infrastructure to?, a verifier is able to recompute each chain of hash value?upward? to a final, uppermost value. This can be done offline, and may not require querying the signing infrastructure once again depending on the implementation. ? * will be the same as? Only if recomputation results in the identical calendar value, or, if signature was extended to the correct published value 7001, then * will be the same as? As shown in FIGS. 6-10, the Guardtime signing infrastructure is used. FIGS. 6-10 show how to use the Guardtime signing infrastructure. This can be done without the need for keys and in some cases offline. Assuming all hash functions have been specified or are known, it is possible to do this without relying on keys. The signatures are not created within clients, which can be more vulnerable to malicious manipulation or attacks, but instead within external entities. In other words, the Guardtime infrastructure creates data signatures server-side, though with client-input data records as the basis.
“FIG. FIG. 11 shows how the hash tree signing infrastructure for FIGS. Geolocation data can be added to 6-10. Or maybe only? This data can be entered and hashed into the tree within the hash subtree of one or more gateways and/or aggregaters for the current calendar period. A node may include an identifier ID for each gateway/aggregator. In the data signatures of every data record that has the?location node, the geolocation data for the current period will be included. 9010 (with and without any other data) is a sibling of the recomputation path. This is for all signatures submitted by clients via nodes below node 9012 marked “*?” FIG. 11.”
FIG. 11 shows another consequence to the embodiment. 11. is that the server/gateway/aggregator becomes the device 700 whose position is established. The gateway/aggregator could also request and obtain a digital signature to its own geolocation data. The location signatures can then be stored at the sever or sent to another entity for verification.
“The various operations described in the geolocation component 710, such as extracting and compiling data, submitting it to signature, receiving and storing signatures, etc. will be executed, for instance, in one or more processors (FIG. 10, the executable code may be executed under the guidance of system software, such as an operating program 725. It may be stored in a nontransitory volatile or non-volatile computer readable medium, such as the memory/storage part 730. This storage technology can be used with any combination of technologies. The code that incorporates the various embodiments of the invention can be included in the device 700 at time of manufacture and initial configuration of software, or it may be installed later as a computer program product. FIGS. FIGS. 4 and 5 show how calendar values from a given period are combined in the Merkle to create a composite value that can be published in an unalterable medium.
“FIGS. “FIGS.12 and 13 show an embodiment where the?medium?” A data structure that is easily visible and can be tampered with without detection. A?blockchain’ is one example of such a data structure. 9000. Although the term “blockchain” is not widely accepted, Although the term?blockchain? and related terms do not have an accepted definition, a?blockchain is a data structure that is typically used to describe a block chain. is a data structure that consists of a number of blocks bi, which are usually time-stamped. . . , bj, bj+1, bj+2, bj+3, . . . Each block contains data that corresponds to one or more transactions. The data is hashed together and linked data such as the hash output of the block immediately before it. This chain can be used to create the public ledger. It is usually an append-only database created by distributed consensus among multiple participants. The entry of data into a block in the chain is irrefutable. Any tampering would be reflected on the chained hash calculations, and thus can easily be detected.
The concept of a “blockchain” is a current topic of disagreement. The question of whether any entity can submit blocks to the blockchain and verify them is a matter of dispute. This may depend on meeting some proof-of work requirements (e.g. Bitcoin’s mining?). ) or whether entities that can submit to and verify the blocks in the datastructure must be authorized by a central authority. Also, it is not clear whether “blockchain” means “open?” By definition, ‘blockchain? implies?open? Or not. “Embodiments of this invention don’t presuppose, or require either definition.”
“In FIG. “In FIG. 12, the composite calendar value of each calendar period is entered using any appropriate mechanism. This could include proof-of-work or multi-entity consensus. In the case of open blockchains, trust will not be required for any entity, even if they present a copy of a newspaper or keep a database.
“Some blockchains require a non-trivial settlement period. An example is that a Bitcoin blockchain update may take up to ten minutes before it can be accepted. It may be more convenient to combine several calendar values into one transaction. As shown in FIG. 12, the composite calendar value that forms the root of Merkle tree in core 5000 is one way to accomplish this. 12 is a consolidation of multiple calendar values. The transaction submitted at each end of each period Tp may then be considered the composite value. According to the blockchain settlement time, the period Tp can be adjusted.”
“Assuming that the blockchain can be added quickly enough, it would be possible to submit each calendar values as a separate transaction on the blockchain. FIG. 13. These cases may be a good example of why a Merkle Tree to consolidate calendar value into a composite value is not necessary. In essence, the blockchain could fulfill the function of the calendar.
“Regardless of the value (each calendar or composite calendar) submitted as blockchain transactions signatures may be extended to include parameters identifying the transaction, that is block, in which the input’s calendar value was part. Given a purportedly true copy of the original input record, its corresponding signature, and this blockchain-identifying information, one would then be able to verify the signature up to the level of the calendar value, and onward to the blockchain, thereby totally verifying (or confirming alteration of) the input record.”
“Embodiments can also be used for geofencing. A schedule or administrator may trigger the device to request a signature to verify its current location. The signature value may be added to the blockchain as a calendar value or as part the core-level Merkle Tree computation, thereby creating an irrefutable record that contains the location data encoded within the signature. If the location determined is outside or within a boundary (for instance, defined as a threshold distance from an “allowed”? Or?operational? central point), or?operational?
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