<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ISCAS&#8217;89 &#8211; Science</title>
	<atom:link href="https://scienmag.com/tag/iscas89/feed/" rel="self" type="application/rss+xml" />
	<link>https://scienmag.com</link>
	<description></description>
	<lastBuildDate>Fri, 09 Oct 2026 09:29:50 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>

<image>
	<url>https://scienmag.com/wp-content/uploads/2024/07/cropped-scienmag_ico-32x32.jpg</url>
	<title>ISCAS&#8217;89 &#8211; Science</title>
	<link>https://scienmag.com</link>
	<width>32</width>
	<height>32</height>
</image> 
<site xmlns="com-wordpress:feed-additions:1">73899611</site>	<item>
		<title>New Benchmark Engine Puts Hidden Chip Trojans to the Test Before They Are Ever Built</title>
		<link>https://scienmag.com/new-benchmark-engine-puts-hidden-chip-trojans-to-the-test-before-they-are-ever-built/</link>
		
		<dc:creator><![CDATA[Denise Maddox]]></dc:creator>
		<pubDate>Fri, 09 Oct 2026 09:29:50 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[benchmark generation]]></category>
		<category><![CDATA[chip manufacturing security]]></category>
		<category><![CDATA[chip supply chain]]></category>
		<category><![CDATA[circuit verification]]></category>
		<category><![CDATA[counterfeit and tampered chip detection]]></category>
		<category><![CDATA[electronic design automation security]]></category>
		<category><![CDATA[Graph Neural Networks]]></category>
		<category><![CDATA[hardware security]]></category>
		<category><![CDATA[hardware security threat detection]]></category>
		<category><![CDATA[hardware Trojan]]></category>
		<category><![CDATA[hardware Trojan detection benchmarks]]></category>
		<category><![CDATA[hardware Trojan detection methods]]></category>
		<category><![CDATA[hardware Trojan testing benchmarks]]></category>
		<category><![CDATA[integrated circuit security]]></category>
		<category><![CDATA[ISCAS'89]]></category>
		<category><![CDATA[malicious circuit modifications]]></category>
		<category><![CDATA[satisfiability solving]]></category>
		<category><![CDATA[sequential circuits]]></category>
		<category><![CDATA[silicon chip integrity]]></category>
		<category><![CDATA[state-cube graph]]></category>
		<category><![CDATA[third-party chip supply chain vulnerabilities]]></category>
		<category><![CDATA[Trojan detection]]></category>
		<category><![CDATA[Trust-HUB]]></category>
		<category><![CDATA[trusted hardware verification]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=253009</guid>

					<description><![CDATA[Researchers have developed SeqCube-HT, a framework that uses trace-backed state-cube graphs to generate verifiably executable sequential hardware Trojan benchmarks far more efficiently than existing methods.]]></description>
										<content:encoded><![CDATA[<p>Modern integrated circuits are rarely designed and manufactured by a single organization. A chip that ends up in a car, a data center server, or a defense system typically passes through third-party intellectual property vendors, electronic design automation tools, foundries, packaging houses, and test facilities before it reaches a customer. Each handoff improves productivity, but each also opens a window in which a malicious actor could quietly alter the circuitry. The result is the hardware Trojan: a tiny modification buried in the silicon that waits for a rare logical or temporal condition to occur and then perturbs the design in a way the owner never intended. Because the change is embedded in hardware rather than software, it can slip past conventional defenses and is effectively impossible to remove once the chip has been fabricated.</p>
<p>Defending against this threat depends on detectors, and detectors can only be judged fairly if they are tested against credible examples of what attackers actually do. That is where benchmarks come in. Collections such as Trust-HUB have long given researchers a common set of infected circuits on which to compare detection methods, but static collections grow slowly and cover only a fraction of the enormous space of possible malicious designs. Worse, a benchmark that looks valid on the surface may be functionally broken: analyses of public benchmark repositories have reported triggers that can never be satisfied, functional errors, and simulation mismatches. A detector evaluated against such flawed instances can appear far more capable than it really is, giving the community a false sense of security.</p>
<p>The problem becomes dramatically harder when the Trojan is sequential rather than combinational. A combinational trigger depends only on the values present in a single clock cycle, so its feasibility can be checked within one frame of logic. A sequential trigger, by contrast, must follow a precise trajectory through the circuit&#8217;s internal state across multiple clock cycles, starting from a defined reset state. The rare events that arm the Trojan must occur in the required order, and the payload&#8217;s effect must remain sensitized until it reaches an output or state boundary where it can actually be observed. Many automated insertion methods construct trigger and payload candidates first and only afterwards invoke simulation, automatic test pattern generation, satisfiability solving, or bounded model checking to see whether the candidate is even executable. Those checks can reject bad candidates, but they cannot stop the generator from repeatedly proposing them, and each late rejection wastes time and budget.</p>
<p>A team of researchers at the Information Engineering University in Zhengzhou, China, has now introduced a framework designed to attack this bottleneck directly. Their method, called SeqCube-HT, weaves temporal execution evidence into the benchmark construction process itself rather than treating validity as an afterthought. The work, published in the journal Cybersecurity, demonstrates that grounding candidate generation in observed, reset-consistent circuit behavior can dramatically raise the fraction of attempts that produce genuinely usable, verifiable Trojan benchmarks, especially for the sequential circuits where the difficulty is greatest.</p>
<p>The core idea is the state cube. SeqCube-HT begins by simulating the target circuit from its declared reset state and recording the internal transitions that occur. At each simulated cycle it watches for low-probability events on internal nets, ranked by a rarity score derived from the negative logarithm of the event&#8217;s empirical frequency in the trace set. Structural filters then discard events that sit too close to clock, reset, scan, or test-control logic, preventing the generator from exploiting nonfunctional control points. Each retained rare event is compressed into a pair of partial Boolean assignments: a pre-state cube describing the current register state and inputs that enabled the event, and a post-state cube describing the resulting next state. A deterministic minimization procedure deletes literals one at a time, using ternary propagation to confirm that the rare event remains stable, so that each cube is compact yet replayable. Crucially, every event carries the identifier of the trace and cycle in which it was observed, anchoring it to a concrete execution rather than an arbitrary symbolic state.</p>
<p>These events then become nodes in a directed compatibility graph. Two cubes are considered compatible when they agree on all shared variables, and an edge connects a produced state to the enabling state of a later event, preserving temporal order and reset-consistent provenance. A beam search over this graph selects candidate trigger paths, ranked by a score that aggregates event rarity, rewards temporal progress and structural diversity, and penalizes the cost of the trigger-monitor logic that would have to be inserted. The selected path is then completed into a concrete input sequence before any modification is made to the netlist. In parallel, the framework searches for a sensitized propagation path from the candidate payload site to an observation boundary, either a primary output or a state signal, and merges the trigger and payload constraints only when their assignments are compatible. Only after this coupling does the generator realize the Trojan as an additive gate-level modification, using low-overhead templates such as guarded bit flips, multiplexer-based overrides, and state-boundary changes.</p>
<p>What truly distinguishes the method is its validation protocol. Every candidate must pass active and inactive replay: the activating input sequence is applied from reset to both the clean and infected netlists and must reproduce trigger activation and an observable difference at the recorded boundary, while a paired inactive sequence, which changes one trigger-critical condition, must produce no difference at all. A bounded symbolic audit then follows, unrolling both circuits for a fixed number of cycles and asking a satisfiability solver to confirm that the active execution is feasible with the observed output difference while the inactive difference query is unsatisfiable. A timeout, an unknown result, or the opposite status rejects the instance outright. Only instances satisfying all of these conditions are labeled witness-validated, and each one ships with a complete evidence package: paired netlists, replay vectors, labels, simulator logs, audit encodings, and configuration records that allow an independent checker to reproduce the entire validation.</p>
<p>The experimental results are striking. Across four ISCAS&#8217;89 sequential benchmark circuits and five larger Extended IP designs, including an RS232 controller, a PIC16F84 microcontroller, a network-on-chip interconnect, an AES core, and a 10-gigabit Ethernet MAC, SeqCube-HT produced 3,240 witness-validated instances from 4,500 attempts, an overall yield of 72.0 percent. Under a carefully matched four-flow comparison in which every method received the same event inventory, insertion backend, simulator, and validation gate, the best-performing comparator, an adaptation of a published compatibility-graph approach, achieved only a 50.6 percent yield and required 39.5 seconds per validated instance, against 72.0 percent and 20.9 seconds for SeqCube-HT. The framework also needed roughly half the amortized time of its closest rival while staying within the memory envelope of all four flows. Sensitivity studies confirmed that the default parameters sit on stable operating plateaus rather than at fragile optima, and ablation experiments showed that each component, from state-cube stitching to payload-witness constraints, removes a distinct class of late failure.</p>
<p>The team went further, using the generated corpus to probe how well modern graph-based detectors actually perform. Three representative graph neural network backbones, styled after graph convolutional, graph attention, and GraphSAGE architectures, were trained to classify infected netlists and localize the inserted Trojan cells. When trained on instances from random insertion, TRIT, and compatibility-graph sources, the probes achieved F1 scores above 90 percent, but dropped to 69.2 percent on SeqCube-HT instances, with localization recall falling to 55.7 percent. To rule out the possibility that this gap merely reflected measurable differences such as trigger length or insertion depth, the researchers constructed a covariate-balanced corpus in which those characteristics were matched across sources. The gap narrowed but persisted: SeqCube-HT instances still trailed the closest reference source by 9.0 F1 points and 12.3 localization-recall points, differences that remained statistically significant after correction. The finding suggests that trace-backed temporal Trojans carry structural signatures that current detectors handle less well, though the authors are careful to note that this does not by itself establish physical stealth.</p>
<p>The implications reach well beyond one laboratory toolchain. As machine learning plays an ever larger role in hardware security, the evidential quality of training and evaluation corpora becomes as important as the detectors themselves; adversarial studies have already shown that logically equivalent or structurally modified Trojans can mislead learned models. Benchmarks that come with replayable proof that their triggers execute and their payloads are observable make detector failures interpretable rather than mysterious, and they give defenders a more honest picture of where their coverage ends. SeqCube-HT&#8217;s authors acknowledge clear limits: the framework targets single-clock, gate-level netlists under functional simulation semantics, does not address timing closure, placement, power, or multi-clock designs, and its guarantees apply only to the recorded inputs and settings, not to unbounded reachability. A self-contained reference artifact built around an author-designed controller is publicly available so that the schema and verification path can be independently inspected, even though the full corpus remains restricted by licensing. Future work, the team says, will extend the approach to multi-clock and physical-design-aware settings, bringing benchmark generation closer to the conditions under which real silicon is attacked and defended.</p>
<p><strong>Subject of Research:</strong> Automated generation of witness-validated sequential hardware Trojan benchmarks using state-cube graphs</p>
<p><strong>Article Title:</strong> SeqCube-HT: state-cube-guided generation of sequential hardware Trojan benchmarks</p>
<p><strong>Article References:</strong> Xu, Y., Guo, W., Zhang, W., Hou, S., Zhang, W., &amp; Xu, Z. (2026). SeqCube-HT: state-cube-guided generation of sequential hardware Trojan benchmarks. <em>Cybersecurity, 9</em>(1), Article 230. <a href="https://doi.org/10.1186/s42400-026-00676-2" rel="noopener noreferrer">https://doi.org/10.1186/s42400-026-00676-2</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1186/s42400-026-00676-2" rel="noopener noreferrer">10.1186/s42400-026-00676-2</a></p>
<p><strong>Keywords:</strong> hardware Trojan, benchmark generation, sequential circuits, state-cube graph, hardware security, circuit verification, graph neural networks, Trojan detection, satisfiability solving, Trust-HUB, ISCAS&#x27;89, chip supply chain</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">253009</post-id>	</item>
	</channel>
</rss>
