1 Introduction
-
Visibility [15]. The network of buyer–supplier relationships has become more intricate and participants have little to no visibility and control on upstream stages, which makes it harder to assess the integrity of procured ICs.
-
Traceability [21]. Tracking data is fragmented and spread among involved companies, which makes it very challenging to uniquely identify each procured IC and trace its history back to its origin and, in case of incidents, there is a shortage of data that can be used for forensics investigations.
-
Accountability [14]. In such a scenario afflicted by obscurity and lack of information, fraudulent conduct of companies is noticeably facilitated. There is a lack of means to keep organisations accountable for the portion of processing they handle within the supply chain.
-
the explicit modelling of the overall system, including IC supply chain, blockchain, smart contracts, PUFs and adversary behaviour, i.e. the threat model;
-
the detailed design of the proposed tracking system for detecting counterfeits in IC supply chains;
-
based on the designated threat model, the identification of the possible attacks to the tracking system aimed to bypass counterfeit detection;
-
the analysis of how the proposed tracking system reacts against each of the identified attacks;
-
a prototype implementation and preliminary experimental evaluation of the proposed tracking system, where PUF-based counterfeit detection accuracy is assessed;
-
a discussion on most relevant points concerning the integration of our solution in real scenarios.
Proposed solution | Tag type | Blockchain type | Counterfeit detection approach | Security analysis |
---|---|---|---|---|
Toyoda et al. [27] | RFID | Ethereum | Smart contracts pseudo-code provided | Yes |
Block-Supply Chain [2] | NFC | Consortium | No details are provided on how the smart contract is implemented | No |
Guardtime [10] | PUF | Consortium | No details on integration with blockchain, no info on how PUF data is stored in the blockchain, no details are provided on how the smart contract is implemented | No |
Islam et al. [18] | PUF | Consortium | No info on how PUF data is stored in the blockchain, no details are provided on how the smart contract is implemented | No |
Negka et al. [23] | PUF | Ethereum | No info on how PUF data is stored in the blockchain, no details are provided on how the smart contract is implemented | No |
Anti-BlUFf | PUF | Consortium | Smart contract pseudo-code provided, as well as details on how PUF data is stored in the blockchain | Yes |
2 Related work
3 Preliminaries
3.1 Physically unclonable function
3.2 Blockchain and smart contract
4 System model
4.1 Supply chain model
4.2 PUF-equipped item model
4.3 Blockchain model
4.4 Smart contract execution environment model
4.5 Threat model
5 Tracking system
5.1 Event 1: New item
5.2 Event 2: Item shipping
5.3 Event 3: Item delivery and verification
5.3.1 Item delivery
5.3.2 Challenge–response batch release
-
\(crdBatch_{i,w}.challenges\) is the concatenation of all the challenges in the batch, i.e. \(c_0, ..., c_{C-1}\)
-
\(crdBatch_{i,w}.hashedResponses[k]\) is the \(k^{th}\) hashed response of the batch, i.e. \(hash(r_k)\)
5.3.3 Item verification
6 Security analysis
6.1 Attacks definition
6.2 Attacks analysis
7 Experimental evaluation
7.1 PUF tuning
-
True Admission Rate (TAR): rate of successful validations when the tuning PUF is validated against its own CRD;
-
False Admission Rate (FAR): rate of successful validations when the tuning PUF is validated against the CRD of another PUF;
-
True Rejection Rate (TRR): rate of failed validations when the tuning PUF is validated against the CRD of another PUF;
-
False Rejection Rate (FRR): rate of failed validations when the tuning PUF is validated against its own CRD;