The full article was originally published by Stefano Della Valle on Medium. Read the full article here.
Development goes forward
Six months after the initial launch of ProductID, we have obtained many confirmations of the importance and usefulness of such a tool in many industrial contexts.
We have therefore decided to invest and expand the functions of the system.
The main feature of ProductID is to provide an identification property of a generic object.
To grant a strong security level, the ID property provided by the system is dynamically generated each time the ID verification is needed, and it’s valid only for that specific verification request.
This procedure is very similar to an OTP (one time passcode or password), used as second authentication factor to log in to critical web pages.
Smart objects can be programmed to generate an OPT with various technologies, but how is it possible to provide an OTP tool to a passive object, to a location, or even to an event?
The solution we have adopted is to provide a generic object with a cryptographic smartcard, specially programmed for this purpose.
The ProductID smart card
An OTP code is produced using a factor that changes each time it is used. For example, the current time and date at the moment of the request. By applying a digital signature function to this factor, we get an always different signature, which is verifiable by anyone who knows the encryption key used.
That’s exactly what our smartcard does.
To allow the OTP code verification, the smartcard simulates the behavior of a NFC TAG by generating an URL. The URL is updated every time a NFC reader (for example a smartphone) activates the smartcard.
The URL provides an identification code assigned to the smartcard, an usage counter and a signature generated with an asymmetric key.
The website activated by the URL is able to validate the signature and certify the identity of the smartcard and what it represents.
The weak point of all identification systems is the possibility of cloning the security element. In our case, the security element is the private key securely generated and stored within the smartcard. It cannot be extracted to create a cloned smartcard.
However, it is possible to copy the entire URL which contains a valid signature.
To exclude that a valid signature can be used more than once, ProductID adopts a simple yet very robust solution: for each validation, the data contained in the URL is published onto the IOTA distributed ledger, using a MAM channel.
The website that is activated to validate the signature, check the signature consistency and subsequently verifying that the signature has not been used previously.
Avoid individual weak points
The previously described architecture lacks most of the weaknesses of a typical authentication platform. In particular, the public key of each smartcard is published on the IOTA distributed ledger, and replicated on thousands of nodes. This prevents any attack that tries to change the key in ProductID central server to invalidate the smartcards.
In addition, the IOTA DLT consists of a network of public nodes, but no one can publish a valid transaction without knowing the seed of the smartcard-specific MAM channel. This ensures that cloned or tampered with cards can not be validated.
Basic uses cases
Anti-counterfeiting of valuables
This is the first and most basic use-case for ProductID: a smartcard is associated with an object, typically a valuable item.
By reading the smartcard, the validation website is activated. If the smartcard has produced a valid OTP code, the system redirects the browser to a web page that describes the product associated with the smartcard.
The destination page verifies that the access is made through a redirection managed by the validation site, and then displays the information related to the specific object. Otherwise it will display a generic page.
Since cloning the smartcard is not possible, this tool makes it possible to certify the uniqueness of the product associated with the smartcard.
The smartcard can be integrated into the object by providing a certificate of origin, or associated as a quality certificate. In both cases, a counterfeit product will lack this security add-on.
Production process tracking
Applying a smartcard to an object, even before it is produced, results in a precise tracking during the production process.
The functional logic is the same as the one of the anti-counterfeiting system, with an additional step: after validation of the OTP code produced by the card, the validation site requires the insertion (manual or automatic) of additional data related to the production phase.
It then publishes a validation message that also contains the production phase data obtained by the operator.
When the production process has been completed, a command is provided to the system, which will then be stored in the validation message. From that moment on, at each activation through the use of the smartcard, the validation site will no longer ask for additional information, but will allow the user to view the history of the production of the object associated with the smartcard.
Advanced use cases
Proof of presence
When a smartcard is installed on a wall or an indicator pole, ProductID can be used to certify the presence of a person in a specific place and time.
By activating the smartcard with a common smartphone, the user is prompted to identify themself.
By recording the successful validation of the OTP code produced by the card on the IOTA distributed ledger, the ProductID system also records the identity provided by the user. This information is not modifiable and can be obtained at any time using the unique code of the smartcard.
Supply chain tracking
This model provides the logical connection of events generated by different smartcards. In addition to the basic validation process, the system requires user identification (e.g. with a social network account login).
The process is simplified by using a specific web app. After the first login, the user does not need to log in again.
Each event (smarcard reading action) recorded on the IOTA DLT includes a link to the previous event. This makes it possible to record the sequence of activities carried out by an operator on a given batch that is being processed, and link to subsequent steps carried out by other operators.
Example of application in food production: