ProductID 2.0

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.

ProductID’s Basics

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.

Ensure non-reusability

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:

• the operator activates the smartcard installed on a sign identifying the place of the operation;
• the operator collects a certain quantity of products and deposits them in a container (lot) equipped with a smartcard. They activate the smartcard and record the operation;
• when the lot is complete another operator takes it over. They too activate the smartcard and record the operation;
• the lot is moved and processed through various stages by various operators, who register their activity by activating the smartcard. They also recorded their presence on site by activating the specific smartcard installed in the facility;
• the lot can be split into sublots. The operator who carries out the operation will activate the smartcards of each container;
• at the end of the production process, finished product packages are produced with the production lot code embedded (in QRcode format).

Reading the QRcode, it is possible to obtain the entire sequence of events that lead back to the collection of the raw material to a certain place.

Smart actuators

One of the most critical safety issues in the industrial world is the verification of the authorization of operators to use critical systems. Normally, an authorized operator has a simple key (mechanical or electronic) to enable the system. However, a key is a weak tool: it can be copied and used illegally or even temporarily transferred to another operator.

ProductID makes it possible to reduce these risk factors with the following approach:

• a smartcard provides the digital identity to the actuator;
• the operator who wants to activate the system reads the smartcard and identifies themself;
• identification must be carried out by a reliable system that discourages the operator from passing it on to a third party;
• if the smartcard produces a valid OTP code, and the operator is actually authorized to operate on the device, the system sends an unlock command.

The command can be made through the IOTA distributed ledger on a MAM channel dedicated to the device, or through third party communication systems.

Smart devices’ ID

The smartcard can be produced in various form factors. These include the classic SIM format.

In this case the ProductID smartcard can function as a security element providing various security functions.

For example, the smartcard can sign a challenge token sent by a system that requires the device to prove its identity.

The device uses the smartcard to close the token and returns it.

The central system is able obtain the device’s ID and the signed token, and can easily validate the signature and identify the device with certainty.

The public keys stored on the IOTA distributed ledger make the process easy and secure. It is also very easy to create a black list of devices that are no longer authorized.

Identity of low-critical smart devices.

In all cases where the device cannot interact with a smart card to obtain an OTP, it is still possible to use the ProductID backend system to validate the device’s identity with an acceptable level of security.

The device activation process is similar to the smartcard initialization: the central system creates a MAM channel for the device, and the device sends a public key to the central ProductID system that publishes it on to the IOTA distributed ledger.

The device registers its own public key along with company recorded data and messages. Anyone can validate a message using the unique device identity code provided by the system and the public key obtainable using the identity code.

In this scenario, the certainty of the identity of the device is entrusted to the ability of the device to keep its credentials confidential.

Secure asset management and data quality validation

Managing large fleets of IoT devices can be extremely complex. The IOTA DLT provides a very reliable layer to allow devices to publish data in an “unconnected” way with a central system.

This scenario distributes on thousands of nodes of the IOTA network, even private, the problem of the scalability of the platform. In fact, the recipients of this data do not need to turn to a central intermediary platform to obtain the data, but simply have to request it from their node, which will be sized according to their needs.

This very efficient approach also solves the problem of data reliability of devices that are doubtfully compliant with quality and safety policies.

The validation is simple:

• each device publishes data on an IOTA MAM channel whose starting address is the device’s unique ID provided by ProductID backend;
• whenever a data consumer wants to validate the quality of data published by a device, they will use the identification code to obtain information on its operational status and revision level;
• whenever a device is updated to a higher release, its profile can be updated by the ProductID server, or it can be assigned a new ID.

System API

In designing the evolution of ProductID, we decided to extend the possibility of third parties to use the system more easily. A customer who wants to benefit from ProductID can request to have smartcards that activate their own URL. ProductID no longer mediates the interaction between user and web app.

However, the web app is not able to validate the data produced by the card itself. We have therefore set up a series of REST APIs that provide the web app with the necessary tools.

These are the first APIs available:

1) GET_CARD_INFO_FROM_MAM - by providing the card ID (parameter that the card inserts in the URL), ProductID accesses the restricted MAM channel and obtains the configuration parameters of the card; accesses the public MAM channel to obtain the data of the last reading and the possible association of the card and the associated device. Returns:

• the URL with which the card is associated, where for example it is possible to display product-specific information with which the card is associated;
• the ID of an associated device if present;
• the request to identify the user through a login before displaying data;
• the last reading counter, information that allows you to understand if the reading that has been passed has already been used previously;
• the public RSA key that allows you to validate the signature contained in the URL generated by the card.

2) TAP_ACTION - by providing the entire URL generated by the card and a parameter that indicates the required action, the system performs two possible actions:

• if the parameter is “validate only” ProductID back end uses the URL provided and validates it - the card usage counter must be higher than the last one stored on the MAM and the digital signature must be validated with the public key retrived in the last published public MAM message. If the card is valid it returns a success message;
• if the parameter is “update”, the back end validates the card-generated URL and records the data on the card’s public MAM channel, making the URL unusable a second time.
  The user can also ask to include a PAYLOAD in the message. This field can be used to store application’s data together with the tap event data. If the card is valid and the writing operation has been successful, it returns the MAM channel ID where the data has been stored.

We plan to publish other APIs making the ProductID system more transparent and easier to integrate with smartcards into critical applications.

Conclusion

The combination between the power of the IOTA network and the simplicity and security of ProductID cryptographic smartcards addresses many issues in a revolutionary and innovative way.

In comparison, current technologies are extremely expensive and insecure.