AU2019100668A4 - A Method of Providing Secure Ownership of an Object - Google Patents

Abstract

This disclosure relates to a system for recording ownership information of an object. A microchip tag is attached to the object. The microchip tag detects a requesting device, generates a rolling code, creates a weblink based on: the rolling code; and an object identifier, and provides the weblink to the requesting device. The requesting device receives the weblink and directs a browser application to request a website indicated by the weblink. A webserver receives the request for the website extracts from the weblink the: rolling code; and object identifier. The webserver then verifies the rolling code using the object identifier and receives user input from the requesting device indicative of ownership information entered by a user of the requesting device and to be recorded for the object. Upon verification of the rolling code, the webserver records the ownership information on a blockchain by creating a blockchain record based on the: object identifier; and ownership information. - 102 104 i111 113 114 116 i,107 Ob ect ID Ownershiit Fig. 1

Description

A Method of Providing Secure Ownership of an Object

Technical Field [0001] This disclosure relates to providing secure ownership of an object on a blockchain.

Background [0002] Various blockchains have become popular for the ability to record information in a way that is practically immutable. For example, Bitcoin records transactions of coins and Ethereum can record transactions of tokens involving smart contracts that execute automatically on certain conditions. Typically, users are represented by public keys in the broad sense that each user keeps their private key and publishes their public key. Users can create cryptographic signatures using their private keys and other users can verify this signature by using the corresponding public key.

[0003] Hash functions are similar but without a key. These functions generate a number called ‘hash’ akin to a signature. The number is generated from data so that the number is typically of fixed length, while the data could be arbitrary in size and significantly larger than the hash. All users can re-create the hash from the data to verify that the given hash is correct. Importantly, changing the data by just one single bit will result in a completely different hash. Therefore, it is very difficult to alter the data so that it still generates the same hash as the original data. The data can be a transaction, for example, so all users can calculate the hash of the transaction and compare it to the original hash to detect whether the transaction has been tampered with, such as by changing the recipient of the transaction.

[0004] As can be seen from the above explanation, such cryptographic methods lend themselves for applications where numbers are originally involved. For example, a software package can be represented by a number, such as a hash. Or a user can be represented by a number (the public key) and song can be represented by a number ( such as a hash of the mp3 file).

[0005] However, it remains difficult to apply the above methods to real-world physical objects. How can a user be sure that a given object, that is physically present, is represented by a given number? And how can a user record and access ownership of this physical object?

2019100668 19 Jun 2019 [0006] Therefore, there is a need for an improved system for recording ownership of an object. Preferably, this system ought to work without the user first setting up a crypto wallet or key pair, which would be too onerous for many users.

[0007] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.

[0008] Throughout this specification the word comprise, or variations such as comprises or comprising, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Summary [0009] The system disclosed herein uses a Near Field Communication (NFC) tag attached to an object in a tamper-proof manner. The microchip within the NFC tag is coded so that it generates a rolling code that changes every time the NFC tag is read. The rolling code together with an object identifier is then used as a web link to a webserver, which records ownership of the object on a blockchain.

[0010] A system for recording ownership information of an object comprises:

a microchip tag attached to the object, the microchip tag being configured to:

detect a requesting device, upon detecting the requesting device, generate a rolling code, create a web link based on the:

rolling code; and an object identifier, and provide the web link to the requesting device;

the requesting device being configured to:

receive the weblink generated by the microchip tag; and direct a browser application to request a website indicated by the weblink;

a webserver configured to receive the request for the website from the requesting device,

2019100668 19 Jun 2019 extract from the weblink:

the rolling code and the object identifier, verify the rolling code using the object identifier, receive user input from the requesting device indicative of ownership information entered by a user of the requesting device and to be recorded for the object; and upon verification of the rolling code, recording the ownership information on a blockchain by creating a blockchain record based on the: object identifier; and ownership information.

[0011] The microchip tag may comprise a tamper detection device and the weblink is generated based on a reading from the tamper detection device.

[0012] The rolling code may be a cryptographic rolling code based on a production key stored in the microchip tag and stored in the webserver.

[0013] The webserver may be further configured to create user credentials for the user to allow later access to the recorded ownership information or changing the recorded ownership information upon verification of the rolling code.

[0014] A method for providing ownership information of an object comprises:

receiving, at a webserver, a request for a website from a requesting device, the request comprising a request URL generated by a microchip tag, extracting, at the webserver, a rolling code and an object identifier from the URL, verifying, at the webserver, the rolling code using the object identifier, querying, at the webserver, a blockchain for the object identifier to retrieve ownership information for the object and to check the blockchain for authenticity of the ownership information, and upon verifying the rolling code and verifying the authenticity of the ownership information, creating a website, the website indicating successful verification of the rolling code, ownership indication and indication of a validity of the ownership information.

2019100668 19 Jun 2019

Brief Description of Drawings [0015] An example will now be described with reference to the following drawings:

[0016] Fig. 1 illustrates a system for recording ownership information of an object.

[0017] Fig. 2 illustrates a user interface for entering ownership information.

[0018] Fig. 3 illustrates a user interface that displays recorded ownership information.

Description of Embodiments [0019] Fig. 1 illustrates a system 100 for recording ownership information of an object 101. The object may be a valuable object, such as a bottle of premium wine, a piece of art, such as a painting, a fashion accessory, such as a handbag or jacket, a package of goods, a freight container or other object. System 100 comprises:

(a) a microchip tag 102 attached to the object 101;

(b) a mobile device 103;

(c) a webserver 104;

(d) a database 105 to store an object identifier;

(e) a blockchain 106;

(f) antenna 107; and (g) tamper detection apparatus 108.

[0020] The microchip tag 102 may be a Near Field Communication (NFC) tag and is powered by an antenna 107. More particularly, as the mobile device 103 moves closer to the tag 102, the NFC module of the mobile device 103 generates a varying electromagnetic field that induces a current in the antenna 107, which is then used to power up tag 102. Essentially, tag 102 comprises an ultra-low-power microprocessor with program and data memory. In that sense, tag 102 can

2019100668 19 Jun 2019 store keys to perform cryptographic operations as described in further detail below. Importantly, tag 102 is hardened against physical attacks, such as power consumption attacks and physical field or current sensing attacks, so it is practically impossible to extract the keys stored on tag 102 or to guess the keys based on any physical observations.

[0021] One particular feature of tag 102 is that it comprises a tamper detection apparatus 108. This may be a conductor loop that extends from the tag 102 and the antenna 107. The conductor loop 108 is also attached to object 101 in a way that an attempt to remove the tag 102 from the object will likely break or at least damage the conductor loop 108. The microprocessor in tag 102 can measure the conductance of loop 108 and use that as an tampering indicator. That is, if the measured conductance is lower than the specified value, the microprocessor can conclude that the tag has been tampered with.

[0022] Tag 102 is configured (i.e. programmed) to detect a requesting device. This would be achieved according to the NFC protocol and power-up and handshake routines. Once the processor in tag 102 is started up, that is, upon detecting the requesting device, the processor generates a rolling code. A rolling code (also called a hopping code) is used here to prevent replay attacks, where an eavesdropper records the transmission and replays it at a later time to impersonate the original tag.

[0023] In one example, tag 102 implements a mutual irregular clocking key stream generator, such as MICKEY, AES or others, which can be used in hardware platforms with limited resources. This cipher maps an 80-bit key and a variable length initialization vector (0 to 80 bits) to a keystream with a maximum length of 2^Λ40 bits. The keystream generator makes use of two registers R and S (100 bits each). The registers are updated in a non-linear manner using the control variables: INPUT BIT R, INPUT BIT S, CONTROL BIT R, CONTROL BIT S. The implementation of the cipher may contain flip-flops for the R, S registers and the 4 control variables. Furthermore, there are 7 flip-flops for the counter register to keep track of the number of rounds in the Preclock stage. The keystream production stage in MICKEY 2.0 is preceded by the three stages:- IV Loading, Key Loading and Preclock. Initially the R, S registers are initialized to the all zero state.

[0024] When the object 101 is released to the market after manufacture, the manufacturer registers the object 101 with server 104. In response, server 104 generates a unique identifier (UID) for that object. In other examples, server 104 provides blocks, ranges or sets of generated

2019100668 19 Jun 2019

UIDs to the manufacturer and the manufacturer assigns those UIDs to objects as they leave the manufacturer for their retail distribution channels. In yet another example, the UID for each chip is assigned during manufacture. When the chip is placed on an inlay (substrate with antenna) it is initialised with a key as described below and the UID is read. The UID is sent to server 105 and may be batched at the end of batch production.

[0025] The manufacturer is also provided with a number of tags, such as tag 102, and each tag has a UID stored on data memory (may be write-once/read-only or in a read-only header which contains manufacturer data). Each of the tags has a different UID. In other examples, the tags are combined into batches and each tag of one batch has the same UID. This may be useful for wine, as there are typically many bottles of the same wine sold. Either way, the manufacturer can make the link between UIDs and objects and sends information about the object and corresponding UIDs back to the server 104. The server stores, for each UID, the object information, such as brand, model, date of manufacture, a photograph or video of the object etc.

[0026] Tag 102 can now execute the key stream generator function using the UID as a function parameter. The result is a rolling code that is different for every tag with a different UID. Tag 102 may further store a production key. The production key is a key that is unique to that tag and can only be generated with the use of a secret key. For example, the production key may be calculated by the Triple Data Encryption Algorithm (3DES) algorithm with the UID, a batch identifier and a master key as the key arguments.

productionKey = 3DES(UID, batchlD, masterKey) [0027] The master key is kept secret on server 104 or a separate key store. Before deployment, the production key is generated and stored on the corresponding tag. The key stream function can then be invoked using the production key, the UID and preferably a nonce. The nonce is a number that is automatically incremented each time the key stream function generates a rolling code to ensure that the rolling code is different each time.

[0028] Tag 102 now creates a web link based on the rolling code and based on an object identifier. The weblink also includes a base address, such as www.bestbagsever.com/verify/. Tag 102 appends to this base address the rolling code and the UID in an arbitrary but defined order. In an example, tag 102 also adds a tamper number to the weblink. Essentially the tamper number

2019100668 19 Jun 2019 reflects the conductance of the loop 108 or other number that reflects a difference in electrical or other characteristics of loop 108 compared to the original characteristics to indicate tamper.

[0029] Finally, tag 102 provides the web link to the requesting device, such as by using the NFC protocol which readily allows providing weblinks to devices, noting that the weblink here has the special functionality of including a rolling code and a UID.

[0030] The requesting device 103 is configured to receive the weblink generated by the microchip tag and to automatically direct a browser application to request a website indicated by the weblink. This may be by way of a generic NFC app installed on device 103. Some devices may also have native support for automatically opening weblinks provided through NFC. Advantageously, with the native support or where a generic NFC app is already installed for other uses, the user does not need to install any further software or even enter any data. Importantly, requesting the website causes device 103 to contact webserver 104 at the base address (www.bestbags.com) and request the page “verify/rollingcode_UID_tamperNumber” where “rolling code”, “UID” and “tamperNumber” are replaced by the actual respective values.

[0031] Webserver 104 is configured to receive the request for the website from the device 103 and as part of that request, the webserver 104 has available the UID and the rolling code as generated by the tag. Webserver 104 can now extract the rolling code and the object identifier from the weblink, such as by reading a specified number of characters from the HTML request or by searching for predefined separators, such as It is noted here that the UID and the rolling code are not passed as parameter/value pairs but as the actual weblink.

[0032] Since webserver 104 also has the production code and the UID stored, it is possible to also create the rolling code at the webserver 104 and compare the result with the received rolling code. If the locally generated rolling code matches with the received rolling code, web server 104 has verified the rolling code using the object identifier. If they do not match, web server 104 generates an error page.

[0033] It is noted that webserver 104 also keeps a nonce that is incremented each time a request is received for that UID. If the starting value is the same at server 104 and tag 102, the same nonce is used each time. It is also possible to generate multiple rolling codes, such as five or ten, at the webserver 104 and match the received rolling code against each of them to account for accidental offsets in the nonce, such as by NFC reads without internet connection.

2019100668 19 Jun 2019 [0034] At this stage, the webserver 104 has verified that tag 102 truly corresponds to the UID stored in the server. So, there is a verified link between the object 101 and the server 104. In other words, a tag that has been tampered with or created fraudulently to have the same UID, would not be verified because the rolling code would be different as the production key would not be available to the impostor tag. So only the one object, as provided and registered by the manufacture, would validate correctly with webserver 104.

[0035] At the point of sale, where the object 101 is sold for the first time, there is no ownership information available since the purchaser is the first owner. Therefore, webserver 104 can receive and record ownership information. More specifically, web server 104 generates and delivers to the device 103 a website that includes object information as provided by the manufacturer. Further, the website includes a form to enter new ownership information. As the user fills-in and submits the online form, webserver 104 receives user input from the requesting device indicative of ownership information entered by a user of the requesting device and to be recorded for the object, such as on webserver 104 or database 105. In one example, webserver 104 creates a user account including user credentials, such as a username and password. The above online form for entering new ownership information may include an email field and webserver 104 may simply use the email address as username. The online form may also include a password field for the user to set a password for later use. The online form may also include fields for personal information of the owner, such as name, address or photo upload or capture of face or identification documents, such as driver licences.

[0036] Upon verification of the rolling code, webserver 104 records the ownership information on a blockchain by creating a blockchain record based on the object identifier (as stored on database 105) and the ownership information. The object identifier may be a numeric, alphanumeric or ASCII array or a string of characters to uniquely identify the object.

[0037] The above process may be suitable for cases where physical access to the item is only possible once the item has been purchased. In other cases where there is a risk that an unauthorised person enters ownership information without purchasing the item, the data entry may be further protected by authenticating the purchaser before allowing entry of ownership information.

[0038] For example, the online form may include a further password field. When the user purchases the item, the item manufacturer or the retailer may provide a password for the user over a different channel, similar to two-factor authentication. In particular, the purchaser may receive

2019100668 19 Jun 2019 a password on a print out of a Point Of Sale (POS) receipt. Alternatively, the user may register the item similar to current warranty registration processes, with the manufacturer and receives a password in return by email, SMS or other means or the user may install an authenticator app, such as Google Authenticator, which provides an access code for the user to enter as a password. In yet another example, the website generated by server 105 may comprise a link to the manufacturer’s website to ‘unlock’ the ownership recording in the sense that the manufacturer’s website returns a token or other secure message back to the webserver 105 upon successful authentication of the purchaser. The manufacturer’s website may also be embedded in the website 200 generated by webserver 105, such as by using an iframe construct. It is noted that until the ownership recording is unlocked, the input fields for ownership information as described below may be disabled or invisible. In yet a further example, the manufacturer of the item may be recorded as the initial owner by using a pre-set manufacturer user name/ID and a item-specific password that may be provided to the first purchaser. The first purchaser can then enter this information just as the second purchaser would and as described below.

[0039] In order to record ownership information, system 100 uses a database 105 and a blockchain 107 in combination. That is, the current ownership information is stored in database 105 while the historical chain of ownership can be verified using blockchain 107. When the first purchaser enters the ownership information for the first time (and the server 104 validates the rolling code), server 104 enters the ownership information into database 105. In the example of Fig. 1, the UID of the object is ‘ 1 ’ and the ownership information is the name of the first purchaser “Jane Smith”.

[0040] Server 104 also generates a first block 111 on blockchain 107. First block 111 comprises payload data 112 which represents the ownership information. In one example, the ownership information itself is not stored in payload data 112 simply to reduce the size of blockchain 107. Instead, the payload data 112 may be a hash of the ownership information, such as a hash of all fields of one row in database 105, or all data elements associated with this UID if the database has multiple tables or is a non-relational/graph database, for example.

[0041] Server 104 then calculates a hash 113 of the first block 111. Any user can now recalculate the hash for the ownership information in database 105 and check whether it is identical to the hash 113 in blockchain 107. This makes it practically impossible to alter the ownership information in database 105 without that alteration being detected. As a result, the ownership information is securely recorded on blockchain 107.

2019100668 19 Jun 2019 [0042] In summary, the process described above is very convenient from a user perspective. All the user needs to do is hold the mobile device 103 against the tag 102 attached to the object 101. The phone is automatically directed to a webpage that also automatically verifies the authenticity of the tag by checking the rolling code. The user does not need to enter any product information or keys, etc. but can be notified immediately whether or not the verification was successful. Otherwise, the user can be warned that there is something wrong with the tag. Of course, the webserver 104 can display object information, such as brand, model, photo, etc. to the user. In order to make herself the recorded owner, the user simply enters her personal details and creates a password, which creates an immutable record on blockchain 107.

[0043] When the first owner wishes to sell the object on to a second owner, the first owner scans the tag 103 using her mobile device 103 noting that any smartphone would work but the first owner’s smartphone may already have stored the created password locally. The first owner enters the password, which webserver validates 104. Upon validation, webserver 104 creates a user interface that allows entering new ownership details. The new owner may also create a new password at this point. Alternatively, the new owner may have created an account beforehand and simply enter her user name, such as email address. In this way, the first owner can also enter the new ownership information because all that is needed is the first owner’s password and the second owner’s username.

[0044] Upon entering and submitting the new ownership information, webserver 104 updates the record in database 105 by overwriting the ownership information. Webserver 104 then creates a second block 114 on the blockchain where the updated record of database 105 is represented by payload data 115. Again, this may be a hash of the updated ownership information. Again, webserver 104 calculates a hash value 116 of the new block 114. Importantly, the hash value is calculated of the payload data 115 and also the first hash value 113 of the previous block 111. As a result, the hash is a hash of hashes and any alteration to a previous block can be detecting by recalculating the hash value 116. Similarly, the next transfer of ownership results in a third block 115 and so on.

[0045] While the operations of the back-end related to database 105 and blockchain 107 are performed by webserver 104 in the above example, it is noted that this choice was simply for clarity of presentation. In other examples, there are separate servers or distributed/cloud processing systems that maintain database 105 and create blocks in blockchain 107 based on,

2019100668 19 Jun 2019 triggered by or instructed by webserver 104. In one example, the blockchain is based on the Hyperledger Fabric Blockchain by The Linux Foundation.

[0046] Fig. 2 illustrates a mobile web browser interface 200 showing the website 201 that is generated by webserver 104 when the webserver 104 receives the weblink request from mobile device 103. The weblink is shown in address field 202 of browser 200. Website 201 comprises a header greeting 203 and a notification 204 to the user to check the URL displayed in the address field 202 at the top of the browser window interface 200 to avoid any attacks where entirely different tags are attached to the object which direct the mobile device 103 to a fraudulent webserver.

[0047] Website 201 further comprises an image 205 of the object (here a handbag) and may comprise a detailed description or other information, such as origin, designer, history, celebrities endorsing this handbag, etc. Importantly, website 201 comprises an ownership section 206, which comprises user entry fields to enter ownership information. Here, the ownership section comprises an email field 207, a name field 208 and a camera button 209 that launches a camera interface to allow the user to capture an image of the user’s face or driver’s licence etc. Of course, there may be further fields to enter further information. A submit button 210 finally submits the information to webserver 104 such that the database 105 is updated and the information is secured on blockchain 107.

[0048] Fig. 3 illustrates a browser interface 300 that webserver 104 generates when the tag 102 is scanned a second time after ownership information has been entered as explained with reference to Fig. 3. In other words, each time webserver 104 receives a request, webserver 104 checks database 105 and if no owner is entered yet, webserver generates website 201 as shown in Fig. 2. If an owner is recorded, webserver 104 generates website 301 as shown in Fig. 3. In Fig. 3, the first elements are the same as in Fig. 2 so they are labelled by the same reference numerals. 202 to 205 noting that there is now a different weblink due to the different rolling code this time (but the UID in the weblink stays the same).

[0049] However, the ownership section 306 is different to Fig. 2, as website 301 now shows the current owner including an indication 307 that ownership was verified by the blockchain, the owner’s name 308 and face image 309. The user may tap on “Blockchain” to get more information or even retrieve the hash value for independent verification.

2019100668 19 Jun 2019 [0050] Ownership section 306 also comprises an input field 310 to enter a password, which allows the user to enter new ownership details as shown in Fig. 2. It is noted that any user, not only the owner, can scan the tag 102 on the object 101 and retrieve product and ownership information as shown in Fig. 3. However, only the rightful owner will have the password to change ownership. Again, there may be an independent account managing system that manages user names and passwords so that instead of entering the name and capture a photo of a new owner, only a user name is entered and the details are retrieved from the account managing system.

[0051] It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims (5)

1. CLAIMS:

   1. A system for recording ownership information of an object, the system comprising:

   a microchip tag attached to the object, the microchip tag being configured to:

   detect a requesting device, upon detecting the requesting device, generate a rolling code, create a web link based on the:

   rolling code; and an object identifier, and provide the web link to the requesting device;

   the requesting device being configured to:

   receive the weblink generated by the microchip tag; and direct a browser application to request a website indicated by the weblink;

   a webserver configured to receive the request for the website from the requesting device, extract from the weblink:

   the rolling code and the object identifier, verify the rolling code using the object identifier, receive user input from the requesting device indicative of ownership information entered by a user of the requesting device and to be recorded for the object; and upon verification of the rolling code, recording the ownership information on a blockchain by creating a blockchain record based on the:

   object identifier; and ownership information.
2. 2. The system of claim 1, wherein the microchip tag comprises a tamper detection device and the weblink is generated based on a reading from the tamper detection device.
3. 3. The system of claim 1 or 2, wherein the rolling code is a cryptographic rolling code based on a production key stored in the microchip tag and stored in the webserver.

   2019100668 19 Jun 2019
4. 4. The system of any one of the preceding claims, wherein the webserver is further configured to create user credentials for the user to allow later access to the recorded ownership information or changing the recorded ownership information upon verification of the rolling code.
5. 5. A method for providing ownership information of an object, the method comprising:

   receiving, at a webserver, a request for a website from a requesting device, the request comprising a request URL generated by a microchip tag, extracting, at the webserver, a rolling code and an object identifier from the URL, verifying, at the webserver, the rolling code using the object identifier, querying, at the webserver, a blockchain for the object identifier to retrieve ownership information for the object and to check the blockchain for authenticity of the ownership information, and upon verifying the rolling code and verifying the authenticity of the ownership information, creating a website, the website indicating successful verification of the rolling code, ownership indication and indication of a validity of the ownership information.

   2019100668 19 Jun 2019