[go: up one dir, main page]

WO2018130994A1 - Système et procédé de vérification et d'authentification de données - Google Patents

Système et procédé de vérification et d'authentification de données Download PDF

Info

Publication number
WO2018130994A1
WO2018130994A1 PCT/IB2018/050225 IB2018050225W WO2018130994A1 WO 2018130994 A1 WO2018130994 A1 WO 2018130994A1 IB 2018050225 W IB2018050225 W IB 2018050225W WO 2018130994 A1 WO2018130994 A1 WO 2018130994A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
data object
hub
verifier
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2018/050225
Other languages
English (en)
Inventor
Tarique Bhuiyan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hashkloud Pty Ltd
Original Assignee
Hashkloud Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2017900102A external-priority patent/AU2017900102A0/en
Application filed by Hashkloud Pty Ltd filed Critical Hashkloud Pty Ltd
Priority to AU2018207471A priority Critical patent/AU2018207471A1/en
Publication of WO2018130994A1 publication Critical patent/WO2018130994A1/fr
Anticipated expiration legal-status Critical
Priority to AU2020101073A priority patent/AU2020101073A4/en
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • This invention relates to the verification and authentication of a data object, in particular concerning an entity, be it a device, such as a data signal- emitting 'thing' on the internet of things ( ⁇ '), document meta-data, a person, an agency, a corporation or other organisation.
  • a data object in particular concerning an entity, be it a device, such as a data signal- emitting 'thing' on the internet of things ( ⁇ '), document meta-data, a person, an agency, a corporation or other organisation.
  • the term 'data object' refers to multiple pieces of data or meta-data about an entity or about some specific data that the entity holds or owns, including digital assets, digital instructions of transactions and financial transactions.
  • the data object typically contains data arranged in two or more data fields. If a data field is detected to contain data, it is reported to be populated. If there is no data in the field, the field is considered unpopulated. Whether a field is populated or unpopulated has significance, irrespective of the data contained in the field if populated.
  • the non-device entity would have associated computers and communications systems which they would use to transmit data about themselves or entities or things with which they interact.
  • the data object may for example include or relate to digital instructions concerning transactions, including financial transactions.
  • the data object may comprise condition monitoring measurements.
  • Extensible mark-up language data (XML data) and Java-Script Object Notation (JSON) data are considered to be self-describing or self-defining, meaning that the structure of the data is embedded with the data, so that when the data is received by a recipient device, there is no need to pre-build the structure to store the data: It is dynamically understood within the XML or JSON data.
  • the XML and JSON formats can be used by any entity or group that wants to share information in a consistent way.
  • a secure hash algorithm is a set of algorithms developed by the US National Institutes of Standards and Technology (NIST) and other government and private parties. These provide secure encryption or "file check" functions and have arisen to meet some of the top cybersecurity challenges being encountered, as public service groups work with government agencies to provide better online security standards, both for organizations and the public.
  • Computing the hash value (or 'hash') of a downloaded file and comparing the result to a previously published hash for that file can show whether the download has been modified or tampered with.
  • Blockchain is a known distributed ledger technology that assists in the transfer of data through a plurality of routes and the checking at the receiving end for correspondence between the data files received and the data sent.
  • a blockchain receipt is digital, algorithm-produced, cost-efficient and permanent evidence of a Blockchain transaction. It proves that data was recorded in the blockchain and can be used to verify the contents and timestamp of any file, database record, photo, etc. It eliminates the need for middlemen, transaction processors and verifiers.
  • US patent application publication no. 2008/0172339 discusses methods of authenticating transactions using a computer program wherein a first data pattern is sent to a mobile telephone requesting a transaction and a second data pattern is sent to a verifier system by a device managing a transaction for a business.
  • the respective data patterns are encrypted using a private key and decrypted using a public key with correspondence being tested.
  • the issue of the irrefutability of the data underlying the data pattern is not addressed.
  • Patent US 8,386,774 makes use of a one-way hash function in verification of a transaction- or event-logging system, when testing the integrity of a transaction data set.
  • the trusted third party is not required to perform any hashing on the data that it holds about the transacting party, leaving open an opportunity of compromising the security of the transaction.
  • the invention provides for achieving verification and authentication (V&A) of a data object using cryptographic technologies, such as secure hash algorithms (or SHA), without the need for the party that owns the data, or a party requesting the data, who wishes to have at least a portion of said data verified, to give out or to divulge any of the actual data to each other or to a data verification engine operable by an independent third party.
  • This is achieved by utilising Blockchain techniques to verify and authenticate, as well as prove the existence and irrefutability of at least a portion of, the data object.
  • the data not to be divulged to requestor or hub will be referred to as 'restricted data' and will generally be of a confidential or personal nature. By way of example, it may relate to the financial position or the financial transactions of a subject.
  • a method of verifying and confirming the existence and irrefutability of a data object, the veracity of which is being queried in relation to a subject comprising the steps of: a. Providing a communications hub configured to communicate with a verifier holding data pertaining to a designated subject; b. Compiling a verification request in respect of the data object being queried, c. Applying to the queried data object a predetermined function known to both the verifier and the hub to generate a data object value specific to the queried data; d.
  • the hub is equipped with an access portal allowing remote authorised access thereto.
  • the method includes providing the data object in a pre-arranged data object pattern.
  • the request includes the data object pattern.
  • the method further includes holding data object patterns at the hub and making said patterns accessible to external requestors.
  • the predetermined function is one that has been agreed on by requestor and hub.
  • the function is agreed between requestor and verifier (the latter being the entity that performs the verification, not the one that instigates or requests it).
  • the verifier returns the comparison value to the hub for comparison.
  • the request further comprises a first information item relating to the subject.
  • the method preferably also includes:
  • the step of applying the predetermined function comprises processing the data according to a data object pattern.
  • the data object pattern is held in a bank of data object patterns saved to be accessible from a server associated with the hub.
  • the method may further comprise the steps of causing the hub to apply the predetermined hash function to generate a second hash value relating to the data object pattern, recording to a Blockchain the second value and obtaining a Blockchain receipt in respect thereof.
  • the method further may include causing the hub to communicate the Blockchain receipt to the verifier.
  • a system of verifying and confirming the existence and irrefutability of a data object being queried as to its veracity in relation to a subject comprising a communications hub configured to communicate with a verifier holding data pertaining to a designated subject; and programmed with executable instructions for:
  • the data object is provided in a pre-arranged data object pattern.
  • the data object pattern is included in the request.
  • the predetermined function preferably comprises a hash function agreed on by the verifier and the hub.
  • the system preferably configured for the hub to be programmed to receive from the verifier the comparison value for comparison.
  • the request may comprise a first information item relating to the subject.
  • the system may further be set up so that a unique request identifier is allocated to the request, and is sent to the verifier along with the first information item and the hub is programmed to cause the verifier to provide a second information item to the subject and to invite the subject to present both first and second information items to an access portal of the hub.
  • the hub in a preferred embodiment, is configured for selecting the predetermined function from a bank of selectable logical functions that are executable on data the veracity of which is being queried.
  • the hub in a further preferred embodiment is configured for communication with a device from which it receives a query for data verification and compiles the request
  • a verification system in respect of restricted data comprises a communications hub operable intermediate a verification requestor and a verifier, the hub being configured to provide access to a bank of selectable logical functions that are executable on data in respect of which verification is to be sought, and computation means for executing a function once selected to generate a function value, the system also at least transiently comprising:
  • the hub is further configured to receive the verification request message from the requestor, to add a request identifier to the message and forward the message with the identifier to the verifier.
  • the hub comprises an online portal configured for communication with the subject associated with the restricted data.
  • the hub is configured for Blockchain interaction.
  • the verifier is likewise Blockchain-configured.
  • the hub is configured for holding data object patterns and making the data patterns accessible to external requestors.
  • the first and second function values are computed independently by the verifier and the hub or requestor.
  • a method of data verification comprising the steps of: a. Providing a data hub configured for holding data object patterns, b. Charging the hub with data object patterns to be held thereon and causing the data patterns to held to be accessible to external entities; c. Sending to the hub a request to verify data in relation to a data object associated with a subject, the request comprising a data object in a selected pattern; and d. Responsive to said verification request, causing the hub to confirm the data object with a verifier having communication with the subject.
  • the hub comprises a data processing platform having a data processor.
  • the step of causing the hub to confirm the data object comprises confirming said object via an entity that independently of the hub holds original data associated with the subject.
  • the step of confirming the data object portion comprises applying cryptographic methods to the data object.
  • the method includes applying a nested hash function to the data object.
  • the method preferably further includes the step of establishing the existence of the data for which verification is to be sought.
  • the existence of otherwise of the data is established by recording a file containing information derived from the data to Blockchain.
  • Figure 1 shows in schematic view a preferred embodiment of the process of this invention.
  • Figure 2 is a table showing the data and information flow paths between entities when the process is implemented.
  • the invention provides for achieving verification and authentication of data objects comprising data that has been arranged in an agreed, preferably standardized, form.
  • the invention makes use of cryptographic technologies, for example Secure Hash Algorithms (SHA), without the need for a primary verification-capable entity - such as a party that holds (for example on the basis that it owns) the data - or the requesting entity, who wishes to establish the validity of at least a portion of said data before entering into a transaction with the data owner, to give out or to divulge any of the actual data to each other, or to a data hub having a verification platform engine.
  • the hub is operated independently of requestor and verifier, for example by a third party.
  • Blockchain techniques are employed to prove the existence and irrefutability of the data being verified.
  • the data may include financial transaction instructions and data relating to digital assets.
  • the implementation of the invention is in a context of verifying data concerning parties to a proposed financial transaction.
  • the invention is not confined to this field and transactions between different entities need not necessarily be involved.
  • the data object is provided in a specific data format, non-limiting examples including XML (Extensible Mark-up Language) and, preferably JSON (Java Script Object Notification). Data structures in JSON are based on key / value pairs.
  • the key is a string, while the value may be numerical, Boolean (true or false), an object, or a combination of any of these.
  • Any data able to be held and communicated in a standardized format is able to be verified using the data hub method of this invention. If a data set requires verification and authentication (V&A), but no standard exists for that data set, then the requestor will need to attach the data schema or data object pattern (but not the actual data) with their request message.
  • V&A verification and authentication
  • a disinterested party operates the data hub and publishes data object patterns, which are identified to users by way of unique object pattern identification (ID) strings.
  • the hub includes a processor, a search engine and communications hardware and software.
  • a requestor 12 issues an online request 14 to a data hub 16.
  • the data hub comprises a data processing platform having data processing hardware and software defining a data search engine, as well as digital communications capacity including an email client and communications hardware, including for text messaging, such as via a short messaging system (SMS).
  • SMS short messaging system
  • the request is sent by way of a data file in any acceptable format, for example using XML or preferably JSON via REST services over the web, or even via a secured electronic mail service.
  • the data object is attached to the email as a JSON or XML object.
  • it may be sent as an XML or a JSON file, or even as a text file (.TXT).
  • the data object in request 14 is made up of a plurality of data blocks. In this embodiment, they are:
  • a header block, 'a' This comprises fields providing limited data about a subject 22 of a verifying entity 18, in whom requestor 12 has an interest.
  • the subject is associated with the verifier. It may, for example, be a customer of verifier 18 and a prospective customer of requestor 12.
  • Non-limiting examples of these fields are: I.
  • a request identifier (ID) preferably allocated by the requestor to identify its request for future reference and response. However, it may alternatively be allocated by the data hub operator, or according to a protocol prescribed or agreed between requestor and hub operator.
  • An indicator of the request type The type may, for example, be for verification and authentication (V&A) of a data object. This is referred to below as a 'type V request.
  • the type of request may alternatively be or relate to an instruction for performing a financial transaction for both V&A and transaction processing - referred to as a 'type 2' request.
  • a customer reference number This is a reference number previously allocated by verifying entity 18 to the subject.
  • the CRN will identify the requestor's subject of interest to the verifier.
  • the CRN is held in a database of entity 18.
  • An access identifier in respect of data hub 16 This is a string furnished to the subject for use in gaining access to a portal for obtaining access to the hub.
  • the access identifier may be, for example, an email address of the subject, or a user ID of a different form, which has been allocated and recognized by the data hub, as an access ID for use by the subject.
  • V The subject's first name, last name and date of birth (in the case of an individual) or entity name and date of incorporation or registration number for a corporate body.
  • Instruction data block 'b' If request 14 is a transaction instruction (a type 2 request), this block will set out the instruction/s for the transaction.
  • the instructions are arranged according to a predefined data object pattern. This data block is of course not required for a type 1 request, where no transaction is being actuated.
  • block 'b' will, in addition to the instructions, contain a status code, which may have any of the following values:
  • a hash value (H Request ) block 'c' This provides the value of the total hash (also known as the message digest) of the data that belongs to the data object pattern in block 'b'. This hash value is recorded onto a Blockchain and the Blockchain receipt is separately sent to the verifier.
  • the hash value in block 'c' (H Request ) is therefore the hash of the instructions of block 'b'.
  • the invention thus includes hashing the data object and recording the hash onto a Blockchain, with the Blockchain receipt separately being sent to the verifier, proving the existence of the data object and data.
  • data hub 16 On receiving request 14, data hub 16 forwards it, as denoted by the label 14', to an entity 18, which is known to hold or be otherwise enabled to access the subject data to be verified.
  • entity 18 By way of example, the situation may involve a business A (as requestor 12) requesting verification of an account number NNN held by subject B (subject 22) at Bank C, which is in the role of verifier 18.
  • Forwarded request 14' is supplemented by a request identifier block, 'd', which the data hub uniquely allocates to this request.
  • Block 'd' represents an additional data item, as seen at step 2 in Figure 1 . Together with forwarded request 14', it constitutes a new request 20.
  • Bank C in this example represents the entity 18 that is called on to verify the data object contained in original request 14. It is therefore referred to as the 'verifier'.
  • the verifier receives new request 20 from data hub 16 and, at step 3, sends to the customer concerned, being subject 22, a confirmation code 24, together with the request ID generated within block 'a' (which hub 16 had received from requestor 12).
  • These data items are sent to subject 22 via a mobile telephone text message in this embodiment, although any other suitable known communication means (preferably digital) may be used as an alternative.
  • Verifier 18 applies the predesignated hash function used by hub 16 (or requestor 12 as the case requires), for example SHA512, to the variables below:
  • Verifier 18 then makes a record of the verification request it has received. In this record it stores the hash value computed above. Alternative functions may of course be used.
  • Subject 22 having received code 24 and the original request ID, with instructions relating to their use, carries out the instructions by logging on to an access portal associated with data hub 16 and inputs the code and the request ID when prompted (see step 4).
  • An alternative way of confirming the instruction is 2- Factor Authentication (2FA), using a mobile telephone handset or equivalently 2FA-capable device.
  • 2FA 2- Factor Authentication
  • a data processor associated with data hub 16 is operated to apply SHA512 again to the hash value computed above, plus the variable of block 'c', thereby determining a further hash value as follows:
  • H NewRequest SHA512((SHA512(hub confirmation code 24 + Requestor's original request ID + Hub-generated request ID 'd' + Request date) + 'c'))
  • hub operator 16 records the value H NewRequest on to Blockchain 30, for which it receives a Blockchain receipt 32, proving the fact that the data has existed.
  • Data hub 16 then, at step 6, responds by sending a file containing the value it has calculated for H NewRequest to verifier 18, along with the following:
  • verifier 18 extracts the requested data from its database against the CRN number supplied and then applies the same secure hash logic to the data to find the Hash value (H Res P° nse ).
  • the outcome is the result of performing the following logic:
  • H Response SHA512((SHA512(Code + Original Request ID + Data hub
  • H NewRequest H Response
  • verifier 18 sends a positive response 36 back to data hub 16 - see step 7.
  • Failing hash value parity a negative response is returned, by way of verifier 18 logging the appropriate process status code (from the options 0, 1 , 2 and 9 listed above) in the header data block.
  • Data hub 16 records the request and response details onto Blockchain and thereafter, in step 8, forwards the positive / negative response received from verifier 18 to the third party requestor 12.
  • Verifier 18 verifies that the H NewRequest has not been tampered with, by making use of Blockchain receipt 32 it received at step 6.
  • step 6 The following steps will be implemented subsequent to step 6, when the request is of type 2, i.e. where the data object is in the form of or comprises a financial transaction instruction and where the request is for V&A as well as transaction processing.
  • Verifier 18 checks the file it receives from the hub for signs of tampering: It locates SHA512, computes SHA512('b') and SHA512('c'). Parity on comparison will confirm the data in 'b' has not been tampered with. • Verifier 18 then extracts the data from its database against the subject's CRN number supplied. It then applies the same logic to the data, i.e. SHA512((SHA512(Code + Original Request ID + Hub 16's Request ID 'd' + Request Date) + 'c')) to determine a response hash value, H Response .
  • Verifier 18 adds the further step of verifying that the H NewRequest has not been tampered with, by using Blockchain receipt 32 that it received from hub 16.
  • H NewRequest H Response
  • the verifier processes the requested financial transaction in relation to the subject customer associated with the CRN in block 'a'.
  • Verifier 18 thereafter sends a positive or a negative response back to data hub 16 with the same data fields as header data block 'a', but having changed the 'Process Status' code either to , meaning a Positive, or '2', meaning a Negative, response.
  • Verifier financial institution 18 processes the first leg of the transactions: debit to ordering subject account (A) and ⁇ credit to the data hub Interbank Settlement account B (if in the same country) or credit to Interbank Nostro Settlement account (if in different countries).
  • Verifier financial institution 18 sends a 'positive' or a 'negative' response back to data hub 16 with the same data fields as 'a', but having changed the 'Process Status' code either to , meaning a positive, or '2' meaning a negative, response.
  • Data hub 16 then records the request / response details onto Blockchain and forwards the positive / negative response received from the verifier 18 to third party requestor 12.
  • the second leg of the transaction in this embodiment is processed by a second verifying entity 34 (see Figure 1 ), according to the following protocol:
  • Second verifier 34 processes the second leg of the transaction, namely: It debits either the Interbank Settlement account B, if located in the same country as verifier 18, or the Interbank Nostro Settlement account of platform 16, if located in a different country, and credits the nominated beneficiary account.
  • Second verifier 34 sends a response 42 to the data hub with the same data fields as header data block 'a' but with the 'Process Status' code changed either to '1 ' meaning 'Positive' or a '2' meaning 'Negative'.
  • the hub provides appropriate confirmation to the requestor.
  • DOPs data object patterns
  • DOPs are provided below:
  • Example of documents include Application form as a
  • restricted data may be personal data relating to a subject and defines a data object in this invention.
  • the data object consists of a range of data types. These may be stored in data fields in a database operated by third party agency, such as a regulatory authority, or an educational, financial or commercial institution.
  • third party agency such as a regulatory authority, or an educational, financial or commercial institution.
  • the invention provides for the use of data object patterns created in relation to selected data combinations from various data types.
  • the data object patterns (but not the actual data) are retained on a purpose-built platform, for example a hub, and made available via a web portal to requestors.
  • a requestor wants to verify data about a subject, that requestor will send a V&A request to the platform or hub operator and, in response, the data hub engine will confirm (or refute) the data or data object sent by the requestor. Since the data object pattern exists and can be verified using the Blockchain receipt, it can be assumed the data that forms the pattern has integrity.
  • the data hub will also record particular requests and response combinations on to Blockchain, as proof of existence and integrity (E&l), as well as for audit purposes for the data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé et un système, permettant de confirmer et de vérifier l'existence d'un objet de données dont la véracité est interrogée par rapport à un sujet, qui utilise un concentrateur de communications configuré pour communiquer avec un vérificateur contenant des données concernant un sujet désigné. Une requête de vérification est compilée, une fonction prédéfinie connue à la fois du vérificateur et du concentrateur est appliquée à l'objet de données, générant ainsi une valeur d'objet de données spécifique aux données. Celle-ci est enregistrée dans un système de registre électronique distribué, pour obtenir un reçu permettant de fournir un enregistrement permanent de la valeur d'objet de données et ainsi des données. Le vérificateur reçoit la requête et le reçu, en tant que preuve de l'existence de l'objet de données. Le vérificateur applique la fonction prédéfinie aux données qu'il contient pour générer une valeur d'objet de données de comparaison. La correspondance entre les valeurs confirme la véracité de l'objet de données interrogé.
PCT/IB2018/050225 2017-01-13 2018-01-14 Système et procédé de vérification et d'authentification de données Ceased WO2018130994A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2018207471A AU2018207471A1 (en) 2017-01-13 2018-01-14 Data verification and authentication system and method
AU2020101073A AU2020101073A4 (en) 2017-01-13 2020-06-21 Data verification system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2017900102A AU2017900102A0 (en) 2017-01-13 Data verification system and method
AU2017900102 2017-01-13

Publications (1)

Publication Number Publication Date
WO2018130994A1 true WO2018130994A1 (fr) 2018-07-19

Family

ID=62839738

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2018/050225 Ceased WO2018130994A1 (fr) 2017-01-13 2018-01-14 Système et procédé de vérification et d'authentification de données

Country Status (2)

Country Link
AU (2) AU2018207471A1 (fr)
WO (1) WO2018130994A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107493340A (zh) * 2017-08-23 2017-12-19 广州市易彩乐网络科技有限公司 区块链网络中的数据分发校验方法、装置及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030074327A1 (en) * 2001-10-15 2003-04-17 Payformance Corporation Check based online payment and verification system and method
WO2009039600A1 (fr) * 2007-09-24 2009-04-02 International Business Machines Coporation Système et procédé pour une vérification sécurisée de transactions électroniques
US8280776B2 (en) * 2008-11-08 2012-10-02 Fon Wallet Transaction Solutions, Inc. System and method for using a rules module to process financial transaction data
US8386774B2 (en) * 2008-03-04 2013-02-26 Industrial Technology Research Institute Logging system and method based on one-way hash function
US20160283920A1 (en) * 2015-03-28 2016-09-29 Justin Fisher Authentication and verification of digital data utilizing blockchain technology
US20160330027A1 (en) * 2015-05-05 2016-11-10 ShoCard, Inc. Identity Management Service Using A Blockchain Providing Certifying Transactions Between Devices

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030074327A1 (en) * 2001-10-15 2003-04-17 Payformance Corporation Check based online payment and verification system and method
WO2009039600A1 (fr) * 2007-09-24 2009-04-02 International Business Machines Coporation Système et procédé pour une vérification sécurisée de transactions électroniques
US8386774B2 (en) * 2008-03-04 2013-02-26 Industrial Technology Research Institute Logging system and method based on one-way hash function
US8280776B2 (en) * 2008-11-08 2012-10-02 Fon Wallet Transaction Solutions, Inc. System and method for using a rules module to process financial transaction data
US20160283920A1 (en) * 2015-03-28 2016-09-29 Justin Fisher Authentication and verification of digital data utilizing blockchain technology
US20160330027A1 (en) * 2015-05-05 2016-11-10 ShoCard, Inc. Identity Management Service Using A Blockchain Providing Certifying Transactions Between Devices

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107493340A (zh) * 2017-08-23 2017-12-19 广州市易彩乐网络科技有限公司 区块链网络中的数据分发校验方法、装置及系统
CN107493340B (zh) * 2017-08-23 2020-02-11 广州市易彩乐网络科技有限公司 区块链网络中的数据分发校验方法、装置及系统

Also Published As

Publication number Publication date
AU2018207471A1 (en) 2019-05-30
AU2020101073A4 (en) 2020-07-23

Similar Documents

Publication Publication Date Title
CN111095327B (zh) 用于验证可验证声明的系统和方法
CN111066020B (zh) 用于创建去中心化标识的系统和方法
US11356270B2 (en) Blockchain-based smart contract pools
US11307775B2 (en) Distributed storage of custom clearance data
US20220084013A1 (en) Identity management, smart contract generator, and blockchain mediating system, and related methods
US11372695B2 (en) Blockchain-based import custom clearance data processing
US11416418B2 (en) Managing user authorizations for blockchain-based custom clearance services
EP3073670A1 (fr) Système et procédé d'identification personnelle et de vérification
US11418511B2 (en) User management of blockchain-based custom clearance service platform
US11449911B2 (en) Blockchain-based document registration for custom clearance
EP3841550B1 (fr) Gestion de stockage basée sur une rétroaction de message
AU2020101073A4 (en) Data verification system and method
WO2025002735A1 (fr) Transaction de chaîne de blocs
WO2021153421A1 (fr) Procédé de commande, serveur et programme
WO2025002725A1 (fr) Transaction de chaîne de blocs
HK40040213A (en) Blockchain-based import custom clearance data processing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18738466

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018207471

Country of ref document: AU

Date of ref document: 20180114

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18738466

Country of ref document: EP

Kind code of ref document: A1