WO2019048901A1

WO2019048901A1 - Document authentication using distributed ledger

Info

Publication number: WO2019048901A1
Application number: PCT/IB2017/001668
Authority: WO
Inventors: Akkarakwad THITISUD; Mitchell DEYOUNG; Phongsak KAOCHOM; Somchard PHANNAM
Original assignee: Linxens Holding
Priority date: 2017-09-05
Filing date: 2017-09-05
Publication date: 2019-03-14
Also published as: EP3678872B1; EP3678872A1

Abstract

A method for authenticating a certificate includes placing a sticker having a chip integrated therein onto the certificate. The chip includes a memory having information identifying the sticker and particular information that is on the certificate. An association is created between the information identifying the sticker and the certificate. This information is stored on a block chain.

Description

DOCUMENT AUTHENTICATION USING DISTRIBUTED LEDGER

FIELD OF INVENTION

The invention relates to document security, and in particular, to authentication of documents. BACKGROUND

Passports and similar documents, such as national identity cards, have long been targets of counterfeiters. As a result, such identity documents have evolved to include elaborate measures to foil counterfeiters. Such measures often include embedding a chip having encoded thereon biometric information that links the holder of the identity document with the identification document. These documents are considered the most secure travel and identity documents ever .

In order to obtain a passport, one submits, to the passport-issuing agency, other identification documents. An example of such a document is a birth certificate. Such documents, often called "breeder documents" because they are used to breed other documents, generally do not have such advanced anti-counterfeiting measures .

Faced with an impenetrable security wall around a passport, the wily counterfeiter will simply look for the weak link in the chain of identity that leads to the passport. Instead of attempting to counterfeit a passport, the wily counterfeiter will simply counterfeit something like a birth certificate and apply for a passport in the usual way. Once an identity is established on the basis of an unsecure breeder document the fraud is difficult to detect . In fact, a birth certificate is not the only type of document that is easy to counterfeit. Other examples of vulnerable documents include land titles, or university degrees. These documents share certain properties. Among them is a lack of uniformity in format or content, as well as a lack of uniformity in security features.

Such documents are not without some basic defenses against counterfeiting. These include watermarks or fibers in the security paper, guilloche background printing, micro- text, UV-visible printing, or combinations thereof. However, a skilled counterfeiter will often be able to duplicate these features well enough to avoid detection.

SUMMARY

The invention provides a simple and secure way to protect a wide variety of documents against counterfeiting. These include university diplomas, teacher certificates, company registration certificates, land titles, social security documents, birth certificates, and other documents that display vital data that can be misused for fraud and/or criminal purposes, and that are often verified by people who are not trained to detect lapses in document security.

A suitable verification method begins with enhancing the document with a sticker that includes a chip having memory on which is encoded data that is also possibly displayed on the document to be protected. This data is included in a blockchain. As such, it is easily

authenticated using widely-available tools or applications available on machines such as smart phones . The sticker itself is simple to apply to a document. This results in an easy-to-use system for the reliable verification of the authenticity and integrity of any kind of valuable

certificate .

In one aspect, the invention features a method

comprising authenticating a certificate. Such an

authentication method includes obtaining, from a backend server, authorization to issue an adhesive sticker to be placed on the certificate, the adhesive sticker having memory and a transponder integrated therein, reading a form- control number that has been printed onto the certificate, storing particular information that is printed on the certificate in the memory, obtaining, from the chip, information identifying the chip, calculating a first hash (i.e. a message digest) based on the information identifying the chip, information on the certificate, and the form- control number, storing the first hash in a block chain, and placing the sticker on the certificate.

Other practices further include receiving a request to authenticate the certificate, reading information from the memory, the information comprising the information

identifying the chip, information on the certificate, and the form-control number, calculating a second hash based on the information that has been read from the memory,

determining that the second hash matches the first hash stored on the block chain, and providing data indicating that the certificate is authentic. In some of the foregoing practices, no online connection is available and wherein calculating the second hash comprises calculating the second hash locally at an authenticated slave. In others,

calculating the second hash comprises calculating the second hash remotely at a back-end server. In other practices, storing particular information comprises using a near-field communication protocol to store the information.

Yet other practices include pre-personalizing the chip, by hashing the information identifying the chip, thereby generating a hash value, and storing the hash value in a read-only memory block of the chip. Among these are

practices that transmitting information to a secure database for storage therein, the information comprising the hash value and information related to the chip.

Practices of the method include those in which the chip implements the IS014443-4 standard and those in which the chip includes an RFID chip.

Other practices also include storing context

information in the chip. In some practices, the context comprises image data and biometric data. In others, the context information includes information that can only be read by an authorized reader and information that can be read by any reader.

In another aspect, the invention features an article of manufacture comprising a chip having a memory and a sticker having an obverse and a reverse, one of which has a location (e.g. a recess) in which the chip and the transponder are placed. The memory has, stored therein a first hash

representative of a unique identifier of the chip,

particular information associated with a certificate to which the sticker adheres, and an inventory control number identifying the sticker. This first hash matches a second hash stored in a block chain. In some embodiments, the memory is a read-only memory block.

In other embodiments, the memory comprises context information stored therein. Among these are embodiments in which the context information comprising one of image data and biometric data and embodiments in which the context information comprising information that can only be read by an authorized reader and information that can be read by any reader . In still other embodiments, the chip implements the

IS014443-4 standard.

Embodiments further include those in which the side that has a chip (e.g. in a recess) is the obverse and those in which the side that has a chip (e.g. in a recess) is the reverse .

A significant advantage is that the sticker can be applied to any existing certificate or document. There is generally no need to change the document's design. The existing security features on the document will continue to function in the usual way. This permits seamless integration into existing systems.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a distributed-ledger authentication system; FIG. 2 shows a certificate to be protected by the distributed-ledger authentication system of FIG. 1;

FIG. 3 shows a roll of stickers used in connection with authentication of the certificate shown in FIG. 2; FIG. 4 shows a sticker to be placed in the blank area shown in the certificate of FIG. 2 ;

FIG. 5 shows the memory in the chip shown in FIG. 2 ;

FIG. 6 shows a pre-personalization process; FIG. 7 shows an authorization process;

FIG. 8 shows an activation procedure for activating a reader as shown in FIG. 1; and

FIG 9 shows an issuing process for issuing one of the stickers shown in FIG. 3. DETAILED DESCRIPTION

FIG. 1 shows a distributed-ledger authentication system

10 for permitting a user 12 to authenticate a certificate 14 that is to be protected. The distributed-ledger

authentication system 10 features a host 16 that is

connected to a reader 18. Readers 18 are registered to keep control of the issuance process. As such, both the host 16 and reader 18 will require authentication to ensure that neither is in a list of revoked devices.

The host 16 is typically a general-purpose digital computer that may lack certain security features. It is therefore useful to also include, within the reader 18, a slave 20 that carries out secure communication with a backend server 22. A secure database 23 connected to the backend server 22 provides storage for certain sensitive data to be described below. The host 16, reader 18, and its slave 20 define one of many nodes 24 that are connected to the backend server 22. In the particular embodiment shown in FIG. 1, the slave 20 is implemented as a smart card that is configured for securely-storing sensitive data, including keys, both asymmetric and symmetric. Such a card, often called a

"secure-application module," includes countermeasures that prevent inadvertent leakage of data via electromagnetic radiation, through observation of timing, and other side channels. All security-related operations, for example ISO 14443-4 protocol handling and the cryptographic handling, are delegated to the slave 20. Such an implementation is particularly useful if connection to the cloud is expected to be intermittent. Alternatively, in those embodiments in which connection to the cloud is expected to be persistent, the slave 20 can be implemented on the cloud rather than as a smart card.

The backend server 22 is a central entity that is responsible for managing operation of the slaves 20. In some cases, the backend server 22 causes data that is processed by the slaves 20 to be backed up on a blockchain 25, or distributed ledger. The use of such slaves 20 in cooperation with the backend server 22 promotes security even in cases in which the hosts of the distributed-ledger authentication system 10 are managed by different parties and/or

manufactured by different vendors. To further increase security, a slave 20 is configured to activate only when the backend server 22 provides the slave 20 with an activation key 26 in response to a request from that slave 20. To hinder unauthorized duplication of the activation key 26, the backend server 22 maintains a master key 28 that it uses in the process of generating an activation key 26 for a particular slave 20. This results in a significant impediment to a counterfeiter who wishes to use an unauthorized reader 18 to counterfeit a certificate 14. Referring now to FIG. 2, the certificate 14 has a preprinted form-control number 30, which is typically printed in a machine-readable form. Known machine-readable forms include a bar code and a QR code. This form-control number 30 is used to maintain inventory control over certificates 14, including both blank and authenticated certificates 14.

The certificate 14 also includes a blank area 32 that is large enough to accommodate a sticker 34. Preferably, the blank area 14 is circular and has a diameter of about four centimeters . Referring to FIG. 3, the sticker 34 is one of a set of stickers provided on a backing paper 36 with a silicon liner on a roll 38. They can easily be detached from the roll 38 and placed on the certificate 14.

Referring now to FIG. 4, each sticker 34 has an obverse 40 and a reverse 42.

The obverse 40 is available for placement of a custom design together with optional security features such as guilloches, UV-visible print, micro-text, and a latent image Also placed on the obverse 40 is a unique inventory-control number 44, either in plaintext or in the form of a bar code or QR code .

The reverse 42 includes integrated security hardware 46 and an adhesive that firmly sticks to the certificate 14. As a result of this adhesive, attempts to remove the sticker 34 from the certificate 14 will likely destroy the sticker 34, the certificate 14, or both.

In a preferred embodiment, the security hardware 46 includes an antenna 48, a radio-frequency identification transponder 50, and a chip 52 that is placed using the SMARTRAC BULLSEYE ™ wet inlay. The antenna 48 enables contact- free communication between the chip 52 and the reader 18 via the radio-frequency identification transponder 50. A suitable reader 18 is a radio-frequency identification reader that communicates using the ISO 14443-4 protocol. This permits reuse of existing infrastructure for electronic identification cards and passports. Additionally, this configuration also permits the chip 52 to be read by a mobile device that has a suitable near-field communication interface .

The chip 52 includes a memory 54 that stores certain data. Referring now to FIG. 5, this data includes the inventory-control number 44 and particular information 56 that is printed on the certificate 14. Particular

information 56 is the personal information that changes from one certificate 14 to the next.

Depending on the available memory 54, additional data can be included. A relatively small memory 54 has been found to be suitable for most purposes. For example, in some embodiments, between one and four kilobytes of memory 54 are adequate. Other embodiments have as much as 64 kilobytes of memory 54. The details of the chip 52 can be varied to suit a customer during a pre-personalization phase that occurs at the production site for producing the stickers 34. The chip 52 will be supplied in Security Level 3 with all Advanced Encryption Standard ("AES") access keys pre-personalized . This makes it essentially impossible to personalize the chip 52 without having knowledge of the AES access keys.

Pre-personalization also includes hashing certain data to form a hash value 58. The data to be hashed includes the inventory-control number 44 and the chip's universal

identifier, which is provided by the chip's manufacturer. A preferred embodiment features hashing using the SHA256 message authentication code (sometimes referred to as CMAC1) .

The memory 54 includes a read-only memory block 60 that cannot later be manipulated or changed. It is in this readonly memory block 60 that the hash value is stored.

The hash value 58 is also transmitted to the secure database 23 and stored as part of the profile data there, together with the inventory-control number 44 and other information related to the chip, such as manufacturing metadata and quality-assurance data associated with the radio-frequency identification transponder 50.

In some embodiments, the chip 52 is one that implements the IS014443-4 standard. Among these are embodiments in which the chip 52 is implemented using the NXP MIFARE Plus S platform with lkB, 2kB or 4kB of EEPROM that is rated for up to 20,0000 single write operations, that uses Advanced

Encryption Standard 128 for authentication, data integrity and encryption, that has freely-configurable access conditions, that uses common criteria (CC) EAL 4+ certified (BSI-DSZ-CC-0620-2010-MA-01) , that features an anti-tearing mechanism for writing AES keys, that supports ISO/IEC 14443- 3 universal identifiers, including in particular a seven- byte universal identifier, that communicates up to 848 kilobits per second, that supports all commands of the ISO/IEC 14443-3 Protocol (all commands) in Security Level 3, and that is rated to retain data for at least a decade. Also among these are embodiments in which the chip is implemented using the NXP MIFARE EVl platform and those in which it is implemented using the NTAG platform.

The use of a chip 52 offers numerous advantages. For example, when enough memory 54 is available, such a chip 52 can collect context information, such as image, or biometric data. Such context information can be partitioned between private data, which can be read only by an authorized reader 18, and public data, which can be read by any reader 18, including a suitably-equipped smartphone .

In addition, even when there is not so much memory 54, the chip 52 is able to exchange relevant information with other computer systems in correct and ready to use format and to permit automated document tracking, thus improving document-handling, and increasing document security. In addition, the use of the chip 52 permits the distributed- ledger authentication system 10 to leverage off existing infrastructure for reading electronic identification cards and passports .

Yet another advantage arises from the ability to function even without a network connection using on-board data to provide a basic level of security. FIG. 6 shows an example of the pre-personalization process 62. The process begins with reading the inventory- control number 44 off the label (i.e. the sticker) (step 64), for example using a bar-code scanner, and reading the universal identifier off the chip 52 (step 66) . The

combination of the universal identifier and the inventory- control number 44 is then digitally signed (step 67),

formatted into a near-field communications message (step 68) and encoded into the chip 52 (step 70) for later use during an authorization procedure 72 shown in FIG. 7.

Referring now to FIG. 7, the procedure for authorizing 72 includes reading the inventory-control number 44 off the label (step 74), for example using a bar-code scanner, and reading the universal identifier off the chip 52 (step 76) . The combination of the universal identifier and the

inventory-control number 44 is then digitally signed (step 78) . Authorization 48 then proceeds with the decoding of the near-field communications message (step 80) that was stored in the encoding step (step 70) . The near-field

communications message is then extracted (step 84) and compared (step 86) with the outcome of the signing step

(step 78) .

FIG. 8 shows an activation procedure 88 through which a user 12 who is using a host 16 activates a slave-controlled reader 18 that stands between the host 16 and the backend server 22 so that the reader 18 can validate a certificate 14.

The activation procedure 88 begins with the user 12 logging into the host 16 (step 90) and the host 16 sending a message to the backend server 22 requesting authorization to validate a certificate 14 (step 92) . To obtain access, it is preferable to have the user 12 complete a two-factor authentication procedure by presenting both a user password and either a one-time password token or an actual

fingerprint from the user's finger. It is also preferable to log the user's interaction with the backend server 22.

The host then communicates with the reader to obtain relevant unique identifiers (step 94) . These would include an identifier for the reader 18 and for the slave 20 that controls the reader 18.

The host 16 then receives the relevant identifiers together with a random number that will be valid for only the transaction that is being initiated (step 96) . Upon doing so, the host 16 transmits the pertinent information to the backend server 22 to permit the backend server 22 to activate the slave 20 and validate the reader 18 (step 96) . This information includes, for example, the reader's identifier .

Having received the pertinent data from the host 16, the backend server 22 proceeds to determine whether or not the slave 20 is an unexpired valid slave 20 that is in possession of an updated key (step 98) . It also verifies that the relationship between the user and the reader 18 is valid (step 100) . Upon determining that the foregoing preliminary requirements are met, the backend server 22 proceeds to calculate an activation key 26 (step 102) . In doing so, it uses its own master key 28, which is provided by its own hardware security module. This activation key 26 is then sent to the host 16 (step 104) . The host 16 then sends, to the reader 18, the activation key 26 (step 106) . Finally, the reader 18 will perform the necessary read and write operations and deliver the result of this operation to the host 16 (step 108) .

To promote security, it is preferable that the slave 20 provide a unique activation key 26 for each chip 52. This ensures that if an attacker somehow obtains a key for one chip 52, only that chip 52 will be compromised so long as the master key 28 remains safe. The slave 20 uses three inputs to generate such a diversified key: the chip's unique identifier, a master key stored in the slave 20, and diversification input data.

The distributed-ledger authentication system 10

includes interfaces to existing databases and is thus configured for operating with existing systems. This minimizes interference with existing systems. The only additional components needed are a radio-frequency

identification transponder 50 and a bar code scanner or some other device for reading a printed code. In one preferred embodiment, the host 16 interacts with the distributed- ledger authentication system 10 using a web application on a standard browser. Preferably, communication between the host 16 and the backend server 22 is via a secure socket layer with all operations being recorded. This permits audits to be carried out.

The distributed-ledger authentication system 10

provides an integrated monitoring system to provide a complete chain of custody for the stickers 34. During pre- production, when the inventory-control number 44 is written to the chip 52, the stickers 34 will be registered in the secure database 23. As a result, only registered stickers 34 can be issued.

Registration includes the use of an encrypted file that has been logged on the blockchain 25. This encrypted file can be decoded and validated through the activation key 26. This allows the use of only those stickers 34 that have been provided by the distributed-ledger authentication system 10.

The physical distribution of the stickers 34 is

likewise traced and logged. When a site that is to issue stickers 34 receives such stickers 34, the receipt of those stickers 34 is recorded. This permits the distributed-ledger authentication system 10 to cancel stickers 34 that have encountered problems while being issued as well as stickers 34 that have been physically damaged.

It is possible to browse an inventory of stickers 34. This permits assessing the sticker inventory available at different nodes 24. The distributed-ledger authentication system 10 also allows assigning a certain set of stickers 34 to a specific node 24.

Thus, only chips 52 associated with stickers 34 that have been assigned to a particular node 24 can be issued by that node 24. An uncontrolled exchange of unpersonalized stickers 34 between nodes 24 is therefore not possible. Once its reader 18 has been suitably activated, a registered host can then personalize and issue a sticker 34.

Referring to FIG. 9, an issuing process 110 begins with scanning the form-control number 30 on the blank certificate 14 (step 112) and having the backend server 22 verify its authenticity (step 114) . Only registered and unused blank certificates 14 are accepted. If no valid blank certificate 14 is presented, it is not possible to personalize either a sticker 34 or the blank certificate 14.

Once the blank certificate 14 has been validated, a transaction number is assigned (step 116) . The user then places a sticker 34 on the reader 18 to establish

communication with that sticker' s chip 52 via its radio- frequency identification transponder (step 118) . The inventory-control number is then read from the chip' s memory and sent to the backend server 22 (step 120), which proceeds to verify it (step 121) . If backend server 22 deems the chip 52 to be valid, it writes the particular information 56 into the chip's memory via the radio-frequency identification transponder (step 122) . In addition, the backend server 22 authenticates the slave 20 in the background (step 124) .

Next, the certificate 14 and the sticker 34 are attached so that both are carrying the same information (step 126) . Finally, an association is formed between the form-control number 30, the inventory-control number 44, and the transaction number (step 128) .

In addition to issuing a sticker 34, a node 24 can also verify or authenticate a sticker 34, and hence a certificate to which it is attached. This includes showing that the sticker 34 was issued by a valid node 24 and that the chip 52 in the sticker 34 is not a fake chip.

One approach to authentication is carried out online by connecting to the secure database 23. Data read from the chip 52 at the node 24 can then be compared with corresponding data stored in the secure database 23.

Another approach relies on digitally signing the chip's unique identifier and the inventory-control number 44 during the prepersonalization phase. This signature is stored on the chip 52 and can thus be read by an authenticating node 24. It can also be recalculated at the backend server 22 for comparison with the signature that is read by the node 24. A mismatch will indicate a counterfeiting attempt. If no online connection is available, a node 24 can still authenticate a certificate 14 provided that there is an authenticated slave 20 connected to the host 16. In that case, the procedure is described above but with the slave 20 recalculating the signature instead of the backend server 22. The node 24 can also verify the integrity of the

particular information 56. This can be carried out by

digitally signing the particular information 56 and then using either the backend server 22 or the slave 20 to

recalculate the digital signature for comparison with

whatever has been read from the chip 52.

Having described the invention, and a preferred

embodiment thereof, what is claimed as new and secured by letters patent is :

Claims

1. A method comprising authenticating a certificate,

wherein authenticating said certificate comprises obtaining, from a backend server, authorization to issue an adhesive sticker to be placed on said certificate, said adhesive sticker having memory and a transponder integrated therein, reading a form-control number that has been printed onto said certificate, storing particular information that is printed on said certificate in said memory, obtaining, from said chip, information identifying said chip, calculating a first hash based on said information identifying said chip, information on said certificate, and said form-control number, storing said first hash in a block chain, and placing said sticker on said certificate.

2. The method of claim 1, further comprising receiving a request to authenticate said certificate, reading information from said memory, said information comprising said information identifying said chip, information on said certificate, and said form-control number, calculating a second hash based on said information that has been read from said memory, determining that said second hash matches said first hash stored on said block chain, and providing data indicating that said certificate is authentic.

3. The method of claim 2, wherein no online connection is available and wherein calculating said second hash comprises calculating said second hash locally at an authenticated slave.

4. The method of claim 2, wherein calculating said second hash comprises calculating said second hash remotely at a back-end server.

5. The method of claim 1, wherein storing particular

information comprises using a near-field communication protocol to store said information.

6. The method of claim 1, further comprising pre- personalizing said chip, wherein pre-personalizing comprises hashing said information identifying said chip, thereby generating a hash value, and storing said hash value in a read-only memory block of said chip.

7. The method of claim 6, further comprising transmitting information to a secure database for storage therein, said information comprising said hash value and information related to said chip.

8. The method of claim 1, wherein said chip implements the IS014443-4 standard.

9. The method of claim 1, further comprising storing

context information in said chip, said context

information selected from the group consisting of image data and biometric data.

10. The method of claim 1, further comprising storing

context information in said chip, said context

information comprising information that can only be read by an authorized reader and information that can be read by any reader.

11. A manufacture comprising a sticker, a chip, and a transponder, said chip having a memory, said sticker having an obverse and a reverse, wherein a side selected from the group consisting of said obverse said reverse comprises a recess in which said chip and said transponder are placed, said memory having stored therein a first hash representative of a unique identifier of said chip, particular information associated with a certificate to which said sticker adheres, and an inventory control number identifying said sticker, wherein said first hash matches a second hash stored in a block chain.

12. The manufacture of claim 11, wherein said memory is a read-only memory block.

13. The manufacture of claim 11, wherein said memory

comprises context information stored therein, said context information comprising one of image data and biometric data.

14. The manufacture of claim 11, wherein said memory

comprises context information stored therein, said context information comprising information that can only be read by an authorized reader and information that can be read by any reader.

15. The method of claim 11, wherein said chip implements the IS014443-4 standard.

16. The manufacture of claim 11, wherein said side is said reverse . The manufacture of claim 11, wherein said side is said obverse .