{"id":"7ef79d02-38bd-4a63-be95-7e6230eb3a8c","arxiv_id":"2412.06726","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"An NFT-based digital twin framework, ICtoken, tracks chips through the supply chain with a consortium blockchain and supports secure transfer of active metering keys.","lead":"This paper proposes ICtoken, a framework that assigns a non-fungible token (NFT) to every integrated circuit and logs its supply chain from fabrication to recycling on a blockchain. It aims to deter chip piracy and counterfeiting by making each chip's history, ownership, and authentication data publicly traceable.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Enrollment does not bind ICtoken to a physical IC: Algorithm 1 accepts any new signed ICID, so the anti-overbuilding and traceability claims depend on an unstated trusted enroller.","rationale":"The reader's weakest_assumption identifies exactly the enrollment-binding gap that I consider most load-bearing. The paper is a coherent protocol design with useful features (stage tracking, device-level identifiers, encrypted active metering keys), and the two open-source implementations are a positive step, but neither implementation nor the protocol text addresses how the ICID is tied to a physical IC during enrollment. Without that binding, the central claim of a robust, reliable trail to the original IP owner is unsupported for the malicious-foundry threat that the paper itself considers in Section 4.3.1. My recommended verdict remains CONDITIONAL, matching the reader's, because the gap is fixable in principle by adding a trusted enrollment protocol or PUF-based authentication; the paper should not be rejected outright, but it should not be accepted without addressing this missing link. I do not see a more fundamental internal inconsistency that would change the verdict.","tokens_in":10590,"tokens_out":4936,"duration_ms":50540,"concrete_test":"Construct a concrete attack instantiation: have a malicious but enrolled owner call enrollIC with an arbitrary 256-bit ICID (for example, SHA256 of a random number), stage=Fabrication, status=Completed, PID=None, EDID=None, prevIdx=None, version=0, all fields signed by that owner. Show that every assertion in Algorithm 1 passes and the token is committed to the blockchain. If it passes, the framework cannot distinguish a genuine chip from an arbitrary identifier, confirming that the anti-overbuilding and traceability claims require an enrollment-authentication step (e.g., PUF challenge-response or an IP-owner certificate) that is absent from the protocol.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that ICtokens are 'unique, immutable digital twins for ICs' requires that minting a token be bound to a genuine physical instance. Algorithm 1 (enrollIC) only asserts that the ICID is new, that the transaction is signed by an enrolled owner, and that metadata fields are the default for a fabricated chip (stage=Fabrication, status=Completed, PID/EDID/prevIdx null, version 0). 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 a certified foundry. Section 4.3.1 claims overbuilt chips 'will not be enrolled under the IP owner’s account,' but a malicious foundry that enrolls in ICtracker can mint valid tokens for overbuilt chips, or for arbitrary identifiers, under its own account. The active metering argument only says such chips are non-functional; it does not restore the promised trail back to the original IP owner, because the token's provenance starts with the malicious enroller. Section 3.1 defines ICID as a SHA256 hash of 'the unique identifier for the IC' but never specifies what that identifier is or how the enroller proves it belongs to a physical chip. If the identifier is a printed serial number or other low-entropy value, the pre-image resistance claim in Section 4.2.3 does not prevent an adversary from choosing or guessing identifiers and hashing them. Thus the anti-counterfeiting guarantee collapses unless a trusted enrollment ceremony or PUF-based authentication is specified and analyzed.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":10905,"tokens_out":5643,"duration_ms":56665,"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":[{"comment":"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.","section":"§3.1, Algorithm 1; §4.3.1"},{"comment":"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.","section":"§4.2.3"},{"comment":"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.","section":"Algorithm 4; §3.1 (ICkey)"},{"comment":"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.","section":"§4.3"}],"minor_comments":[{"comment":"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.","section":"§3.1"},{"comment":"The listed byte sizes do not obviously sum to 714 bytes when bits are included; state whether the total includes alignment or padding.","section":"Table 1"},{"comment":"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.","section":"Table 2"},{"comment":"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.","section":"§4.3.2"},{"comment":"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.","section":"References"},{"comment":"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.","section":"Reference [1]"}],"recommendation":"major_revision","confidential_remarks":"Given the enrollment gap, I recommend major revision rather than rejection: the framework's core idea is coherent and the implementations are a useful artifact, but the security claims as written are stronger than the protocol supports. The paper would also benefit from an explicit statement that this is a systems/design proposal, not a cryptographic proof, and from positioning the enrollment assumption as a first-class design decision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: this paper is a reasonably clean extension of the blockchain-based IC supply-chain tracking line, and the product-level NFT aggregation is a genuine addition. But the central promise — a reliable trail back to the original IP owner — rests on an enrollment step that does not actually bind a token to a physical chip. That gap needs to be named and fixed before the security claims can stand.\n\nWhat is new: the per-IC NFT with stage/status tracking, the Merkle-derived PCB and device identifiers, and the secure transfer of active-metering keys inside the token. The protocol algorithms are concrete and the size analysis (714 bytes per token) is useful. The comparison table with prior work is honest about what ICtoken adds. The paper also spends real effort on a proof-of-concept, though the code reference is redacted as anonymous, so I cannot verify it.\n\nThe stress-test critique is on target. Algorithm 1 checks that an ICID is new, that the transaction is signed by an enrolled owner, and that the metadata looks like a freshly fabricated chip. It never checks that the ICID refers to a genuine physical instance, and it never checks that the enroller is the IP owner or an authorized foundry. Section 4.3.1 claims overbuilt chips 'will not be enrolled under the IP owner’s account' — true but irrelevant if a malicious foundry enrolls them under its own account. Active metering may keep such chips non-functional, but it does not restore the trail to the IP owner; the token's provenance starts with the adversary. The ICID is also underspecified: calling it a SHA256 hash of 'the unique identifier for the IC' leaves open low-entropy identifiers (e.g., printed serials), in which case the Section 4.2.3 privacy argument overreaches. This is not a fatal flaw if the framework explicitly assumes a trusted enrollment ceremony or PUF-based authentication at minting, but the paper neither states nor analyzes that assumption.\n\nWhere the paper is solid: the transaction rules are mostly consistent, the stage/status monotonicity is a nice rollback defense, and the active-metering key handoff is a useful practical feature. The informal security analysis is typical for this venue but should be tightened, especially the privacy claim.\n\nWho is this for: hardware-security researchers working on supply-chain provenance, and blockchain practitioners looking for a concrete NFT use case. It deserves a serious referee, but with a request for major revision: specify the enrollment trust model, define what the ICID hashes, and either weaken the traceability claims or add a binding mechanism.\n\nMy vote: conditional accept after revision.","headline":"A plausible NFT-based IC supply-chain tracking design whose central traceability claim depends on an unstated trusted-enrollment assumption.","tokens_in":11421,"tokens_out":1622,"would_cite":false,"duration_ms":19510,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["IC piracy","hardware IP protection","supply chain traceability","non-fungible token","blockchain","physical unclonable function","logic locking","active metering"],"falsifier":"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.","tokens_in":10417,"feed_emoji":"🔐","tokens_out":6910,"duration_ms":70201,"temperature":0.7,"pith_summary":"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.","feed_headline":"A digital twin NFT for every chip","feed_subtitle":"ICtoken logs each chip's journey from foundry to recycler, blocking counterfeit and overbuilt parts.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the two open-source proof-of-concept implementations, the interactive notebook and the Solidity smart contract, that the feasibility analysis reports on.","marker":"[1]"},{"why":"Baseline blockchain-based IC traceability using PUF challenge-response pairs, which the ICtoken framework extends to full life-cycle tracking.","marker":"[18]"},{"why":"Mitigates on-chain CRP storage by moving it to IPFS, providing the scalability baseline that ICtoken's compact 714-byte token improves on.","marker":"[6]"},{"why":"Proposes a blockchain-based supply-chain provenance framework, serving as the prior work that ICtracker's ownership-transfer and stage-tracking services build beyond.","marker":"[10]"},{"why":"Starts tracking right after fabrication and assumes active metering, the approach ICtoken integrates with on-chain key provisioning.","marker":"[37]"},{"why":"Uses a consortium blockchain to track cloned components, representing the nontransparent consortium approach ICtoken contrasts with.","marker":"[35]"},{"why":"Defines the ERC-721 non-fungible token standard that the ICtoken smart contract follows in the proof-of-concept deployment.","marker":"[12]"},{"why":"Introduces Ethereum smart contracts, the deployment platform used to demonstrate ICtracker on existing general-purpose blockchain infrastructure.","marker":"[5]"},{"why":"Introduces Secure Split-Tests that combine logic locking with post-fabrication testing, which motivates the framework's handling of a securely transferred unlocking key.","marker":"[8]"},{"why":"Surveys hardware metering, establishing the active-metering concept that the ICtoken's encrypted ICkey attribute is designed to carry.","marker":"[20]"}],"fun_headline_variants":["Chip NFTs fight piracy with blockchain","ICtoken: NFT digital twin for chips","Anti-counterfeit NFTs for hardware supply chains","Immutable chip NFTs track hardware provenance"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Chip NFTs fight piracy with blockchain","ICtoken: NFT digital twin for chips","Anti-counterfeit NFTs for hardware supply chains","Immutable chip NFTs track hardware provenance"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000188,"raw_usage":{"total_tokens":1352,"prompt_tokens":986,"completion_tokens":366,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":602,"completion_tokens_details":{"reasoning_tokens":313}},"tokens_in":602,"tokens_out":366,"duration_ms":4714,"temperature":1.0,"reasoning_tokens":313,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T19:19:21.421119+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the two open-source proof-of-concept implementations, the interactive notebook and the Solidity smart contract, that the feasibility analysis reports on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Baseline blockchain-based IC traceability using PUF challenge-response pairs, which the ICtoken framework extends to full life-cycle tracking."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Mitigates on-chain CRP storage by moving it to IPFS, providing the scalability baseline that ICtoken's compact 714-byte token improves on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Proposes a blockchain-based supply-chain provenance framework, serving as the prior work that ICtracker's ownership-transfer and stage-tracking services build beyond."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Starts tracking right after fabrication and assumes active metering, the approach ICtoken integrates with on-chain key provisioning."},{"cited_title":"Hossain, Fahim Rahman, Jeffery Allen, Mon- ica Allen, Farimah Farahmandi, and Mark Tehranipoor","cited_arxiv_id":null,"evidence_quote":"Uses a consortium blockchain to track cloned components, representing the nontransparent consortium approach ICtoken contrasts with."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the ERC-721 non-fungible token standard that the ICtoken smart contract follows in the proof-of-concept deployment."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces Ethereum smart contracts, the deployment platform used to demonstrate ICtracker on existing general-purpose blockchain infrastructure."},{"cited_title":"Contreras, Md","cited_arxiv_id":null,"evidence_quote":"Introduces Secure Split-Tests that combine logic locking with post-fabrication testing, which motivates the framework's handling of a securely transferred unlocking key."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Surveys hardware metering, establishing the active-metering concept that the ICtoken's encrypted ICkey attribute is designed to carry."}],"review_version":1}