Pith. sign in

REVIEW 4 major objections 6 minor 40 references

ICtoken: An NFT for Hardware IP Protection

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The ICtoken framework gives every physical chip an NFT and logs its ownership on a blockchain, creating a tamper-evident provenance trail back to the IP owner.

desk verdict A plausible NFT-based IC supply-chain tracking design whose central traceability claim depends on an unstated trusted-enrollment assumption. read the letter →

arxiv 2412.06726 v1 pith:ZHCZHWFN submitted 2024-12-09 cs.CR

Shashank Balla , Yiming Zhao , Farinaz Koushanfar This is my paper · ORCID
classification cs.CR
keywords ICpiracyhardwareIPprotectionsupplychaintraceabilitynon-fungibletokenblockchainphysicalunclonablefunctionlogiclockingactivemetering
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that an NFT-based framework, ICtoken, can give every physical integrated circuit an immutable digital twin that travels with the chip from fabrication through assembly, sale, and recycling. The twin records authentication data, supply chain stage, ownership, and a securely transferred logic-locking key, and an accompanying consortium blockchain called ICtracker logs every ownership and production update. If the framework works, overbuilt or cloned chips cannot be sold under the original brand, swapped components in a device become detectable, and an end user can audit a product's provenance back to the original IP owner. The paper supports the claim with two open-source proof-of-concept implementations and a security analysis against counterfeit supply chain threats.

What carries the argument

The central mechanism is the ICtoken as a versioned, signed NFT object, paired with the ICtracker consortium blockchain that stores and validates it. The token's ICID is a SHA-256 hash of the physical IC's identifier, markHash is a hash of package markings, and the Merkle hashes PID and EDID bind a token to the PCB and device that contain it; each new version points back to the previous one, so the full history is recoverable. ICtracker maintains four mappings (ICdb, PCBdb, DEVdb, OWNdb) and accepts only state changes that pass signature verification, one-way stage progression, and stage-appropriate identifier updates. The load-bearing identity is the ICID-to-chip binding: the digital twin is only as genuine as the enrollment that first attaches it.

What would settle it

Run enrollIC on a token whose ICID is a fresh SHA-256 hash of a fabricated identifier, signed by any enrolled owner, with stage set to Fabrication and status set to Completed; Algorithm 1 will accept it because it checks only that ICdb[ICID] is empty and the signature verifies. If such a phantom chip token appears on the ledger as genuine, the overbuilding countermeasure fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that an ICtoken, a versioned NFT carrying a SHA-256 hash of the chip's unique identifier (ICID), a hash of package markings, production stage and status, and an encrypted active-metering key, can be validated and transferred on a consortium blockchain called ICtracker to form a trustworthy life-cycle record. A PCB identifier is built as a Merkle hash of its ICIDs and a device identifier as a Merkle hash of its PIDs, so tokens compose into product-level NFTs. ICtracker verifies the owner's digital signature on every token, allows stage or status changes only in one direction, binds device identifiers only at the correct production stages, and transfers ownership only to enrolled owners. The authors argue that this combination creates a privacy-preserving, tamper-resistant trail that ties every IC-embedded product back to its original IP owner and gives end users a way to confirm a product is genuine.

Load-bearing premise

Everything rests on the enrollment step: Algorithm 1 checks only that the ICID is new and the enrolling owner's signature is valid, so if a malicious foundry can mint and sign a token for a chip that does not exist or was never authorized, the ledger records it as genuine.

Editorial extensions

If this is right

  • With the framework in place, a chip that was never enrolled by the IP owner cannot appear as a genuine branded part, because overbuilt chips have no token under the owner's account.
  • An end user can trace a device's token history back through each owner to the original IP owner, making counterfeit parts far harder to pass off.
  • Swapping one IC in a PCB or one PCB in a device changes the Merkle-hashed device identifier, so component substitution becomes detectable at the product level.
  • The active-metering key can be handed from owner to owner as an encrypted ICkey, letting each new legitimate owner unlock the chip without the key ever being exposed on the public ledger.
  • The proof-of-concept smart contract minting ERC-721 compliant ICtokens indicates the framework can run on existing public blockchain infrastructure, not only on a custom consortium chain.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper leaves implicit that enrollment is the critical trust point: requiring a PUF response measured at enrollment and stored as a commitment would turn the hashed ICID from a label into a physically verified secret, a testable extension of the current Algorithm 1.
  • The same token structure could generalize to other regulated assemblies, such as batteries, medical instruments, or automotive modules, where a history of component identity, stage, and ownership is legally or commercially valuable.
  • Because ICtracker is a consortium blockchain, the practical trust question shifts from cryptography to governance: the nodes are businesses with competing interests, and the framework's guarantees depend on those nodes honestly running the consensus protocol.
  • Privacy comes from hashing, so anyone with pre-image knowledge of a chip identifier could still recognize a specific chip's token; confidentiality holds against outsiders, not against parties who already know the identifier.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes ICtoken, a framework that assigns an NFT (ICtoken) to each physical IC and registers transactions on a blockchain-based system called ICtracker. Each token stores an ICID (SHA-256 of an IC identifier), a hash of package markings, production stage/status, device identifiers (PID/EDID), ownership, an encrypted active-metering key, and a digital signature. The paper gives four protocol algorithms (enrollIC, updateStage, updatePIDorEDID, transferIC), reports an approximately 714-byte token size, compares with prior blockchain-based supply-chain works, and claims resistance to overbuilding, cloning, remarking, and recycling threats. Two proof-of-concept implementations are claimed: a Python notebook and a Solidity/ERC-721 smart contract.

Significance. The framework is a useful synthesis: it combines NFTs, PUFs/active metering, and supply-chain stage tracking, and it is the first in this comparison to support active metering information and product-level tokens. The protocol algorithms are specified in enough detail to be implemented, the claimed token size (0.7 KB) is a concrete improvement over prior proposals storing CRPs, and the authors state that both implementations are open source. If the enrollment-binding problem is resolved and the trust model is stated explicitly, the framework could provide a practical digital provenance trail. As it stands, however, the strongest security claims are not supported by the mechanisms described.

major comments (4)
  1. [§3.1, Algorithm 1; §4.3.1] The enrollment step does not bind an ICtoken to a physical IC. Algorithm 1 (enrollIC) only asserts that the ICID is not already enrolled, that the transaction is signed by an enrolled owner, and that the metadata values equal the defaults for a fabricated chip; it performs no check that the ICID corresponds to a real chip, no proof of possession, and no authorization check that the enrolling owner is the IP owner or an authorized foundry. Section 4.3.1 therefore overstates the guarantee when it says overbuilt chips 'will not be enrolled under the IP owner’s account': a malicious foundry or a compromised owner can enroll tokens for overbuilt chips, or for arbitrary identifiers, under its own account, and the token's provenance then starts with that adversary. The abstract's claim of a 'robust and reliable supply chain trail back to the original IP owner' is not supported unless the paper adds a trusted enrollment ceremony, a PUF-based proof of possession, or an explicit assumption that the enroller is trusted and states what happens when that assumption fails.
  2. [§4.2.3] The component-privacy argument relies on SHA-256 pre-image resistance without accounting for the entropy of the pre-images. In §3.1, ICID is defined as a SHA256 hash of 'the unique identifier for the IC,' and markHash is a hash of the package markings; neither is guaranteed to be high-entropy. If an identifier is a serial number, lot code, or other low-entropy value, an adversary with access to the public ledger can enumerate candidate identifiers and match hashes, so 'any entity even with full access to all information stored in ICtracker cannot learn anything about ICs that are not in its possession' is false for such inputs. The paper should specify the source and entropy of the identifiers, or use a PUF-derived or otherwise unpredictable value in the hash input.
  3. [Algorithm 4; §3.1 (ICkey)] The active-metering key transfer is not actually verified by the protocol. transferIC asserts only that the new token is identical to the previous token except for key and owner; it does not check that keyHash is preserved, that keyEncr decrypts to a key with that hash under the new owner's public key, or even that an ICkey is present. As written, a previous owner can transfer a token with an arbitrary or corrupted key, which would either break the active-metering functionality for the new owner or allow a malicious owner to hand over a token that decrypts to nothing useful. Since 'secure transfer of IC specific information' is a stated contribution, the protocol should include a verifiable re-encryption step or an explicit off-chain verification procedure.
  4. [§4.3] The security evaluation is qualitative and does not specify a threat model. Section 4.3 lists attacks and asserts resistance, but it never states what the adversary controls (e.g., whether the enroller is trusted, whether the foundry is malicious, whether package markings are known to the adversary) or gives formal security definitions for traceability, cloning resistance, or metering. Several claims, including the overbuilding claim discussed above, are argued from the protocol's own update invariants rather than from an external adversarial model. The paper should either add a concrete adversary model and prove the claimed properties under it, or substantially weaken the claims to refer to the trusted-enroller setting.
minor comments (6)
  1. [§3.1] Throughout the paper, the attribute is spelled both 'trnsaxnID' (Section 3.1, Algorithms 1-4) and 'transaxnID' (Section 3.1 service list); use one spelling consistently.
  2. [Table 1] The listed byte sizes do not obviously sum to 714 bytes when bits are included; state whether the total includes alignment or padding.
  3. [Table 2] Table 2 uses '......' placeholders for PID and EDID values, which makes the example hard to follow; use concrete dummy values or an explicit 'same as previous version' notation.
  4. [§4.3.2] Section 4.3.2 says the framework 'stores all information present on the package,' but §3.1 stores only markHash; clarify that the hash is stored and explain how a verifier obtains the expected mark to compare.
  5. [References] The reference list has incomplete entries (e.g., [9] contains only a URL, [28] lacks a title/venue, and [36] lacks publication details); complete these for the camera-ready version.
  6. [Reference [1]] The open-source implementation citation [1] is redacted; in a public version, provide a working URL or repository identifier so the proof-of-concept is actually verifiable.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation; only a redacted self-citation that is not load-bearing.

full rationale

We walked the paper's claimed derivation chain. The central security and traceability claims are built on external cryptographic primitives (digital signatures, SHA-256 pre-image resistance, Merkle hashes, blockchain immutability) and on protocol invariants that are enforced explicitly by the algorithms. For example, rollback protection in Algorithm 2 is a direct consequence of the assertion `metaData.stage >= prevData.stage`, and device integrity follows from Merkle-hash composition; these are invariants, not fitted parameters or predicted outcomes. The claimed resilience to overbuilding relies on the assumption that enrollment binds a token to a genuine physical IC, but Algorithm 1 only checks that an ICID is new and signed; the paper never derives physical authenticity from the protocol itself. This is a correctness/trust-model gap, not circularity, because the paper does not define 'genuine' as 'enrolled' in a way that makes the security claim tautological. The only self-citation is reference [1], a redacted link to the authors' own proof-of-concept implementations. That citation is used only to assert that an implementation exists and is open-source; it is not load-bearing for any security or correctness conclusion. No step reduces by construction to its own input, and no fitted parameter is renamed as a prediction. Accordingly, no circular step is qualified, and the score reflects only a minor, non-load-bearing self-citation.

Assumptions & free parameters 0 free parameters · 4 assumptions · 3 invented entities

The paper introduces no fitted numerical parameters. It relies on standard cryptographic assumptions, plus two domain assumptions that are load-bearing: the enrollment step is trusted, and the consortium nodes are honest. The invented entities are protocol artifacts, not unexplained physical postulations.

assumptions (4)
  • standard math Standard cryptographic assumptions: SHA256 pre-image resistance, existential unforgeability of digital signatures, and CPA security of public-key encryption.
    Invoked throughout Section 3.2 and 4.2 as the basis for authenticity, privacy, and tamper-resistance claims.
  • domain assumption The enrolling entity (IP owner or authorized foundry) is honest and enrolls only genuine physical ICs.
    Algorithm 1 (enrollIC) checks that an ICID is new and signed, but cannot verify the physical chip behind the hash. Section 4.3.1 relies on this to prevent overbuilding.
  • domain assumption The consortium blockchain nodes follow the protocol and a majority are honest.
    Section 3.3 assumes all nodes run the checks and reach consensus; no adversary model is given for the consortium.
  • domain assumption Each physical IC has a unique, immutable identifier that can be read and hashed at enrollment.
    Section 3.1 defines ICID as a SHA256 hash of the unique identifier; the paper does not discuss how uniqueness is established or enforced.
invented entities (3)
  • ICtoken
    purpose: NFT data structure representing a physical IC and its metadata
    The central artifact of the framework; no deployed instance or external validation is provided.
  • ICtracker
    purpose: Consortium blockchain ledger managing ICtoken registration and transfers
    Proposed ledger; implementation claimed but redacted.
  • PID and EDID
    purpose: Merkle-hash identifiers for PCBs and devices, enabling product-level tokens
    New identifier types introduced to compose component tokens into product tokens.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ICtoken: An NFT for Hardware IP Protection." pith.science (2026). https://pith.science/paper/ZHCZHWFN

@misc{pith2026241206726,
  author       = {Pith},
  title        = {Pith review of: ICtoken: An NFT for Hardware IP Protection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZHCZHWFN}},
  note         = {Machine review of arXiv:2412.06726}
}
read the original abstract

Protecting integrated circuits (ICs) from piracy and theft throughout their lifecycle is a persistent and complex challenge. In order to safeguard against illicit piracy attacks, this work proposes a novel framework utilizing Non-Fungible Tokens (NFTs) called ICtokens, uniquely linked to their corresponding physical ICs. Each ICtoken contains comprehensive information, including authentication data, supply chain stage and status, ownership details, and other IC metadata, while also making provision for the secure integration of a logic-locking key. Designed to be publicly logged, ICtokens securely obscure metering information without compromising functionality. In addition, the ICtracker, a distributed ledger technology powered by a swift and energy-efficient consortium blockchain, is used to register and manage ICtokens and their respective owners, tracking all associated interactions. This robust ledger guarantees the traceability and auditing of ICtokens while simultaneously developing a product-level NFT at every transaction point within the supply chain. Consequently, a scalable framework is established, creating unique, immutable digital twins for ICs and IC-embedded products in the form of ICtokens and their transactions. This provides a robust and reliable supply chain trail back to the original IP owner, while also offering unprecedented assurance to consumers of IC-embedded products. The rich information contained within ICtokens facilitates more detailed audits than previous proposals for IC supply chain monitoring. A proof-of-concept, implemented as an open-source solution, ensures the ease of adoption of the proposed framework.

Figures

Figures reproduced from arXiv: 2412.06726 by the authors.

Figure 1
Figure 1. Supply chain threats. [9] Many techniques have been proposed by the research commu￾nity to tackle the various threats of hardware piracy [28]. Rostami et al [29] and Guin et al [15] survey distinct attacks at each stage of the supply chain for various threat models. For each of these attacks, they discuss methods for detecting it as well as techniques to pre￾vent such an attack. The main limitation of these physical… view at source ↗
Figure 2
Figure 2. Components of the proposed framework. This paper suggests ICtoken, a novel framework ( [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. IC enrollment. Algorithm 4 Transferring IC ownership in ICtracker 1: procedure transferIC(ICtoken): 2: assert ICID of ICtoken is enrolled and not defective. 3: assert ICtoken.owner is enrolled ⊲ new owner 4: fetch prevToken for the ICID 5: assert prevToken’s status is Completed. 6: verifyTransaxn(prevToken.owner, ICtoken) 7: assert ICtoken == prevToken other than key, owner 8: ICtoken.version += 1 ⊲ increment versio… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 39 canonical work pages

  1. [1]

    Anonymous. 2022. ICtoken Implementations. This citation has been redacted to protect the anonymity of the source

    work page 2022

  2. [2]

    Quinn Barry. 2021. Inside Radical Semiconductor: The Stanford Startup Dis- rupting the Chip Industry. Identity Review. https://identityreview.com/inside- radical-semiconductor-the-stanford-startup-disrupting-the-chip-industry/

    work page 2021

  3. [3]

    Malozemoff, and Pierluigi Nuzzo

    Peter Beerel, Marios Georgiou, Ben Hamlin, Alex J. Malozemoff, and Pierluigi Nuzzo. 2022. Towards a Formal Treatment of Logic Locking. Cryptology ePrint Archive, Report 2022/503. https://ia.cr/2022/503

    work page 2022

  4. [4]

    Juan Benet. 2014. IPFS - Content Addressed, Versioned, P2P File System. IPFS Whitepaper. https://ipfs.io/ipfs/ QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf

    work page 2014

  5. [5]

    Vitalik Buterin. 2014. Ethereum: A Next-Generation Smart Contract and Decen- tralized Application Platform. Ethereum Whitepaper. https://ethereum.org/en/ ICtoken: An NFT for Hardware IP Protection whitepaper/

    work page 2014

  6. [6]

    Chandan Kumar Chaudhary, Urbi Chatterjee, and Debdeep Mukhopadhayay

    work page

  7. [7]

    Animesh Chhotaray and Thomas Shrimpton. 2021. Hardening Circuit-Design IP Against Reverse-Engineering Attacks. Cryptology ePrint Archive, Report 2021/456. https://ia.cr/2021/456

    work page 2021

  8. [8]

    Contreras, Md

    Gustavo K. Contreras, Md. Tauhidur Rahman, and Mohammad Tehranipoor. 2013. Secure Split-Test for preventing IC piracy by untrusted foundry and assembly. , 196-203 pages. https://doi.org/10.1109/DFT.2013.6653606

    work page arXiv 2013

Show all 40 references
  1. [9]

    National Counterintelligence and Security Center. 2022. Supply Chain Risks to Semiconductors. https://www.dni.gov/files/NCSC/documents/supplychain/ semiconductor-supply-chain-2022-39E2C6B0-.pdf

    2022

  2. [10]

    Pinchen Cui, Julie Dixon, Ujjwal Guin, and Daniel Dimase. 2019. A Blockchain- Based Framework for Supply Chain Provenance. , 157113-157125 pages. https: //doi.org/10.1109/ACCESS.2019.2949951

    2019

  3. [11]

    William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs. 2018. EIP- 721: Non-Fungible Token Standard. Ethereum Improvement Proposals. https: //eips.ethereum.org/EIPS/eip-721

    2018

  4. [12]

    Ethereum. 2018. ERC-721 NON-FUNGIBLE TOKEN STANDARD. https:// ethereum.org/en/developers/docs/standards/tokens/erc-721/

    2018

  5. [13]

    Ethereum. 2022. Solidity Documentation Release 0.8.15. https://buildmedia. readthedocs.org/media/pdf/solidity/develop/solidity.pdf

    2022

  6. [14]

    Fatemeh Ganji, Shahin Tajik, Jean-Pierre Seifert, and Domenic Forte. 2019. Blockchain-enabled Cryptographically-secure Hardware Obfuscation. Cryp- tology ePrint Archive, Report 2019/928. https://ia.cr/2019/928

    2019

  7. [15]

    Ujjwal Guin, Daniel DiMase, and Mohammad Tehranipoor. 2014. Counterfeit integrated circuits: Detection, avoidance, and the challenges ahead. , 9–23 pages. https://doi.org/10.1007/s10836-013-5430-8

    2014 doi

  8. [16]

    Charles Herder, Meng-Day Yu, Farinaz Koushanfar, and Srinivas Devadas. 2014. Physical Unclonable Functions and Applications: A Tutorial. , 1126-1141 pages. https://doi.org/10.1109/JPROC.2014.2320516

    2014

  9. [17]

    INTRINSIC ID. 2017. SRAM PUF : The Secure Silicon Fingerprint. https://www.intrinsic-id.com/resources/white-papers/white-paper-sram- puf-secure-silicon-fingerprint/

    2017

  10. [18]

    Md Nazmul Islam and Sandip Kundu. 2019. Enabling IC Traceability via Blockchain Pegged to Embedded PUF. , 23 pages. https://doi.org/10.1145/3315669

    2019 doi

  11. [19]

    Hadi Mardani Kamali, Kimia Zamiri Azar, Farimah Farahmandi, and Mark Tehra- nipoor. 2022. Advances in Logic Locking: Past, Present, and Prospects. Cryptology ePrint Archive, Report 2022/260. https://ia.cr/2022/260

    2022

  12. [20]

    Farinaz Koushanfar. 2010. Hardware Metering: A Survey. https://doi.org/10. 1007/978-1-4419-8080-9_5

    2010

  13. [21]

    Serge Leef. 2018. Supply Chain Hardware Integrity for Electronics De- fense. https://csrc.nist.gov/CSRC/media/Projects/cyber-supply-chain-risk- management/documents/SSCA/Winter_2018/TuePM2.1-SHIELD.pdf

    2018

  14. [22]

    Monax. 2019. https://monax.io/help/advanced/nft-integration/

    2019

  15. [23]

    Satoshi Nakamoto. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System. Bitcoin Whitepaper. https://bitcoin.org/en/bitcoin-paper

    2008

  16. [24]

    Mahipal Nehra. 2021. Blockchain in Supply Chain: A Transparent Prospect for Products. ReadWrite. https://readwrite.com/blockchain-in-supply-chain-a- transparent-prospect-for-products/

    2021

  17. [25]

    Emily Newton. 2022. Is the chip shortage leading to more counterfeit com- ponents? Embedded.com. https://www.embedded.com/is-the-chip-shortage- leading-to-more-counterfeit-components/

    2022

  18. [26]

    Department of Commerce: Bureau of Industry and Security Office of Tech- nology Evaluation

    U.S. Department of Commerce: Bureau of Industry and Security Office of Tech- nology Evaluation. 2010. Defense Industrial Base Assessment: Counterfeit Elec- tronics. https://agmaglobal.org/uploads/BIS%20Survey%20(January%202010% 20final).pdf

    2010

  19. [27]

    United States Government Accountability Office. 2016. Counterfeit Parts: DOD Needs to Improve Reporting and Oversight to Reduce Supply Chain Risk. https: //www.gao.gov/assets/gao-16-236.pdf

    2016

  20. [28]

    Jeyavijayan J V Rajendran. 2017. An overview of hardware intellectual property protection. , 4 pages. https://doi.org/10.1109/ISCAS.2017.8050883

    2017

  21. [29]

    Masoud Rostami, Farinaz Koushanfar, and Ramesh Karri. 2014. A Primer on Hardware Security: Models, Methods, and Metrics. , 1283-1295 pages. https: //doi.org/10.1109/JPROC.2014.2335155

    2014

  22. [30]

    Roy, Farinaz Koushanfar, and Igor L

    Jarrod A. Roy, Farinaz Koushanfar, and Igor L. Markov. 2008. EPIC: Ending Piracy of Integrated Circuits. , 1069-1074 pages. https://doi.org/10.1109/DATE.2008. 4484823

    2008 doi

  23. [31]

    skuchainweb. 2016. Skuchain: Here’s how blockchain will save global trade a trillion dollars. https://www.skuchain.com/skuchain-heres-how-blockchain- will-save-global-trade-a-trillion-dollars/

    2016

  24. [32]

    Precision Software. 2019. Could Blockchain Revolutionize Parcel Shipping? https://www.fedex.com/content/dam/fedex/us-united-states/Compatible- Solutions/images/2019/Q2/Could_Blockchain_Revolutionize_Parcel_Shipping_ V2_50457811.pdf

    2019

  25. [33]

    Archana Sristy. 2021. National Counterintelligence and Security Cen- ter. https://one.walmart.com/content/globaltechindia/en_in/Tech-insights/ blog/Blockchain-in-the-food-supply-chain.html

    2021

  26. [34]

    OpenSea the largest NFT marketplace. 2017. https://opensea.io/

    2017

  27. [35]

    Hossain, Fahim Rahman, Jeffery Allen, Mon- ica Allen, Farimah Farahmandi, and Mark Tehranipoor

    Jason Vosatka, Andrew Stern, M.M. Hossain, Fahim Rahman, Jeffery Allen, Mon- ica Allen, Farimah Farahmandi, and Mark Tehranipoor. 2020. Tracking Cloned Electronic Components using a Consortium-based Blockchain Infrastructure. , 6 pages. https://doi.org/10.1109/PAINE49178.2020.9337735

    2020

  28. [36]

    Qin Wang, Rujia Li, Qi Wang, and Shiping Chen. 2021. Non-Fungible Token (NFT): Overview, Evaluation, Opportunities and Challenges

    2021

  29. [37]

    Xiaolin Xu, Fahim Rahman, Bicky Shakya, Apostol Vassilev, Domenic Forte, and Mark Tehranipoor. 2019. Electronics Supply Chain Integrity Enabled by Blockchain. , 25 pages. https://doi.org/10.1145/3315571

    2019 doi

  30. [38]

    Muhammad Yasin and Ozgur Sinanoglu. 2017. Evolution of Logic Locking. https://doi.org/10.1109/VLSI-SoC.2017.8203496

    2017

  31. [39]

    Ernst & Young. 2022. EY OpsChain Contract Manager. ey.com. https://www.ey. com/en_gl/blockchain-platforms/contract-manager

    2022

  32. [2021]

    , 4 pages

    Auto-PUFChain: An Automated Interaction Tool for PUFs and Blockchain in Electronic Supply Chain. , 4 pages. https://doi.org/10.1109/AsianHOST53231. 2021.9699720

    2021

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.