Software Unclonable Functions (SUFs) Overview

• Software Unclonable Functions (SUFs) are digital unclonability mechanisms that use hidden computation and runtime execution fingerprints to ensure device-specific uniqueness.
• Approaches include hardware performance counter-derived signatures, Secret Unknown Ciphers, and machine-learning models like SoftPUF to generate and secure unique digital keys.
• The research emphasizes practical device binding and clone resistance while highlighting challenges in standardization, rigorous security proofs, and diverse implementation models.

Software Unclonable Functions (SUFs) denote a family of unclonability mechanisms in which the discriminating object is not limited to an analog physical artifact, but is instead realized through software execution behavior, a software-instantiated surrogate of a PUF, or a digitally generated secret function embedded in a device. The available literature does not present a single standardized SUF definition. Rather, it spans at least four closely related lines: hardware performance counter (HPC)-derived execution signatures for IoT devices, Secret Unknown Ciphers (SUCs) as internally generated digital clone-resistant functions, software-based PUF emulation such as SoftPUF, and software copy-protection schemes whose correct execution is bound to a target device through a PUF (Alshehhi, 25 Aug 2025, Mars et al., 2019, Hossain et al., 4 Aug 2025, Dorfmeister et al., 11 Mar 2026). Taken together, these works suggest that SUFs are best understood as a broader unclonability paradigm in which uniqueness is induced by hidden computation, device-specific execution footprints, or hardware-bound software behavior rather than solely by fixed manufacturing disorder.

1. Conceptual scope and terminological boundaries

A recurrent source of confusion is terminological: several closely related papers do not use the term “Software Unclonable Function” at all. In the IoT-oriented HPC work, a SUF is introduced as a software-derived signature produced from the interaction between a program and the hardware on which it runs; the signature is extracted from HPC traces and is intended to behave like a fingerprint (Alshehhi, 25 Aug 2025). In the SoftPUF work, the proposed primitive is described as a software-based approach mimicking the functionality of a PUF, with a machine-learning model trained on PUF data to generate unique software-based keys for each device (Hossain et al., 4 Aug 2025). In the SUC literature, the primitive is instead a randomly and internally self-generated unknown and unpredictable cipher inside a chip, where users, manufacturers, or operators have no access or influence on its creation process (Mars et al., 2021). A related software-protection line binds program behavior to hardware-specific PUF responses without explicitly calling the result a SUF (Dorfmeister et al., 11 Mar 2026).

These formulations share a common goal—clone resistance—but they operationalize it differently. In classical PUF language, uniqueness is associated with manufacturing variation and challenge-response behavior. In the HPC-derived SUF formulation, uniqueness arises from the hardware-level behavior of a software function as observed through counters such as instructions, CPU cycles, branches, cache references, cache misses, TLB activity, and stalled cycles. In SUCs, uniqueness comes from an internally selected cipher instance from a very large design class, unknown even to the producer. In SoftPUF, uniqueness is claimed for keys produced by a software model trained over PUF challenge-response data. In PUF-bound copy protection, the relevant property is that a program executes correctly only on its target machine and behaves differently on other machines.

This diversity implies that “unclonability” is not uniform across the literature. In some works it refers to irreproducibility of a hidden digital mapping; in others it refers to the practical difficulty of recreating a runtime execution footprint; in still others it refers to software semantics that remain correct only under the correct hardware fingerprint. A plausible implication is that SUFs are currently better described as a research umbrella than as a settled cryptographic primitive.

2. Secret Unknown Ciphers as a digital SUF lineage

A major digital lineage of SUF-style design is the Secret Unknown Cipher, or SUC: a random cipher selected internally from a large family and retained as a device-specific, clone-resistant identity (Mars et al., 2019, Mars et al., 2019, Mars et al., 2021). This lineage is explicitly positioned against the analog nature of conventional PUFs and their associated inconsistency, helper data, and fuzzy-extractor overhead.

Lineage	Construction basis	Reported properties
Stream-cipher SUC	16 maximum-period NLFSRs and a nonlinear combining function	Family size $2^{100}$, state size 223 bits, linear complexity exceeding $2^{81}$, period exceeding $2^{161}$
Mutated NV-FPGA SUC	Pre-compiled cipher-layout templates, TRNG-driven bitstream mutation	Two cipher classes larger than $2^{1000}$, cloning-resistance entropy $CRE=\log_2 S$
SRAM-SUC	Internally generated involutive cipher stored in FPGA SRAM	$2.88/0.72 \mu s$ response at 50/200 MHz, $|SRAM\text{-}SUC| = 2^{1176}$ for $r=13$

In the 2019 stream-cipher construction, a SUC is created randomly by selecting one cipher from a class of $2^{100}$ possible stream ciphers. The sample keystream generator uses 16 maximum-period NLFSRs and a nonlinear Boolean combining function, with total state size 223 bits. The reported security analysis states linear complexity exceeding $2^{81}$, period exceeding $2^{81}$0, brute-force complexity approximately $2^{81}$1, correlation-attack complexity at least $2^{81}$2, and algebraic-attack complexity $2^{81}$3. The paper also presents a lightweight identification protocol for open networks in which a Trusted Authority stores sequential responses $2^{81}$4, authenticates a device by encrypting a random value $2^{81}$5 under the appropriate stored response, and uses state retention $2^{81}$6 to avoid desynchronization.

The 2019 NV-FPGA work turns the SUC idea into a one-time mutation process inside non-volatile FPGA fabric. A “GENIE” manipulates pre-compiled bitstream templates using TRNG output so that each device permanently instantiates a different cipher. The paper formalizes clone resistance through the metric $2^{81}$7, where $2^{81}$8 is the number of possible instantiated mappings, and reports two cipher families with class sizes $2^{81}$9 and $2^{161}$0. It further states that the required TRNG output is 170 bytes for NI-SUC and 156 bytes for I-SUC.

The 2021 SRAM-SUC work refines this direction by constructing a practical involutive SUC for modern volatile and non-volatile SoC FPGAs. Personalization proceeds through a SUC Design Template, a one-time “GENIE” process using TRNG and AES, and boot-time reconstruction from eNVM into SRAM. The cipher is a 64-bit involutive block cipher using eight involutive 8-bit S-Boxes stored in a 2048×8 LSRAM, 15 rounds, and an involutive permutation layer. The reported latency is 144 cycles, corresponding to $2^{161}$1 at 50 MHz and $2^{161}$2 at 200 MHz. The same paper argues that conventional analog PUFs are noisy and often require fuzzy extractors or helper data algorithms, whereas the digital SUC remains stable over the device lifetime.

Within SUF discussions, SUCs are significant because they shift unclonability away from analog variability and toward unpredictably instantiated computation. The literature’s central claim is not merely that the key is secret, but that the function instance itself is selected internally and remains unknown.

3. HPC-derived SUFs for IoT identification and behavioral security

The most explicit use of the term SUF appears in the 2025 IoT work, which introduces Software Unclonable Functions as hardware performance counter-derived signatures for device identification and security (Alshehhi, 25 Aug 2025). In this formulation, the SUF is not a hidden cipher or software surrogate of a PUF dataset; it is the characteristic hardware-level behavior of a software function, observed through HPCs and treated as a distinctive signature.

The construction pipeline is concrete. Functions are compiled for the target architecture, executed on the device, sampled at regular intervals using Linux perf, parsed into structured tabular data, normalized, converted into sequences, and classified with a GRU-based model. The counters include instructions, CPU cycles, branches, branch misses, branch loads, cache references, cache misses, L1 dcache loads, stores, and misses, L1 icache loads and misses, LLC loads and misses, dTLB loads and misses, iTLB loads and misses, stalled cycles frontend and backend, and bus cycles. Sampling is performed every 200 ms. The main model uses an embedding layer, a GRU layer, and a fully connected linear classification layer; later experiments add a second GRU layer. Training uses CrossEntropyLoss, Adam, learning rate 0.001, and early stopping based on validation loss.

The evaluation targets malicious functions associated with IoT malware behavior, including DoS flooding, TCP SYN flooding, port scanning, Telnet flooding, and ICMP flooding. The main experiments focus on Device A, a Pi 5 / Raspberry Pi-like device based on Broadcom BCM2712, and Device B, a Turris Omnia router based on Marvell Armada 385. A camera device based on Tegra SoC was excluded from deeper analysis because perf installation and capture were problematic and the resulting measurements were unreliable.

Reported accuracy ranges from 83.77% to 96.47%. The summary table gives Device A multiclass overall accuracy 0.9476 and binary accuracy 0.9647, and Device B multiclass overall accuracy 0.8454 and binary accuracy 0.8377. On Device A, PortScan and TCPSYN are reported as perfectly classified in multiclass settings, while DoS and Telnet are weaker classes that improve after adding a second GRU layer. On Device B, ICMP, PortScan, and TCPSYN remain strong, whereas Normal, DoS, and Telnet are less separable. The paper attributes the performance gap largely to device-specific HPC availability: Device A exposes a richer set of events, whereas Device B lacks some L1 and LLC metrics.

This SUF interpretation is behavioral rather than structural. The signature is not a static key stored on the device; it is a runtime execution footprint. The paper’s explicit motivation is to distinguish legitimate and compromised devices in heterogeneous, resource-constrained IoT environments. Its threat model includes flooding traffic, scanning ports, brute-force style connection attempts, persistence behavior, and firmware or function tampering. The formal layer is correspondingly modest: the paper gives the affine form of the GRU classification layer as $2^{161}$3 and standard definitions of accuracy, precision, recall, and F1, but it does not present a cryptographic unclonability proof.

4. SoftPUF and machine-learned software PUF surrogates

SoftPUF represents a different software-oriented direction: rather than using runtime execution traces as the unclonable object, it proposes a machine-learning model trained on PUF challenge-response data to generate unique software-based keys for each device within a blockchain framework (Hossain et al., 4 Aug 2025). The paper does not formally define SoftPUF as a SUF, but it explicitly presents it as a software-based approach mimicking PUF behavior and eliminating the need for dedicated hardware PUFs.

The system architecture begins with acquisition of PUF datasets (1Mx8) from a 64-bit arbiter PUF on Xilinx Artix-7 FPGA hardware. The datasets are sent to a remotely accessible ML model edge server hosted in Google Colab Pro with 12.7 GB high-RAM runtime. The stated workflow includes data preprocessing, model generation, key generation, and evaluation. The generated key is denoted $2^{161}$4, stored as $2^{161}$5, and used to create a trusted identity $2^{161}$6 for device enrollment. During transactions, the device forms an object containing MAC address $2^{161}$7, data $2^{161}$8, and PUF key length $2^{161}$9, wraps them into a SHA512-encrypted object hash $2^{1000}$0, and participates in blockchain authentication through trusted nodes.

The machine-learning specification is internally inconsistent. The text states that a custom Linear Regression model is proposed to mimic PUF characteristics, but the experiments also compare GradientBoostingRegressor, AdaBoostRegressor, KNeighborsRegressor, LinearRegression, DecisionTreeRegressor, RandomForestRegressor, Ridge, and a proposed ML model. A hyperparameter table further lists a deep neural network configuration with optimizer adam, units 512-512-128-128-64-32-8, activations relu, tanh, kernel initializer he_uniform, loss hinge, and metric accuracy. This ambiguity is itself part of the technical characterization of the paper.

The evaluation is reported in terms of accuracy, $2^{1000}$1, MSE, MAE, RMAPE, and MAPE $2^{1000}$2. GradientBoostingRegressor, Ridge, and RandomForestRegressor obtain better MSE or MAE values than the proposed model, while the proposed model is argued to provide computational efficiency, interpretability, and adaptability. System timings include total processing time 50.77 ms, with Phase 1 at 40.72 ms, Phase 2 at 9.83 ms, Phase 3 at 0.22 ms, and key generation itself at 2.77 ms. The Phase 2 message is 119 bits before encryption and 512 bits afterward.

The paper also embeds SoftPUF into a broader blockchain defense framework against 51%, phishing, routing, and Sybil attacks. However, the SUF-relevant limitation is substantial: the paper does not provide a formal definition of uniqueness, unpredictability, unclonability, entropy, challenge-response correctness, or resistance bounds. It also does not report false accept or false reject rates, model extraction experiments, or attack success rates against SoftPUF specifically. For that reason, SoftPUF is best treated as an implementation-oriented software PUF surrogate rather than a formally specified unclonable function.

5. Hardware-bound software protection and safe-by-design execution

Another SUF-adjacent direction treats unclonability as a property of software semantics under hardware binding. The 2026 software-protection work introduces a copy-protection method for industrial control software in which a program executes correctly only on its target hardware and behaves differently on other machines, while symbolic execution is used to preserve safety properties even under wrong PUF responses (Dorfmeister et al., 11 Mar 2026).

The target program class is control-state Abstract State Machines. Each control-state transition is bound to a PUF query, so the correct next control state is available only on the intended machine. In the traffic-light example, the phase is used as the challenge: $CRE=\log_2 S$6 The general construction defines the set of encodable control-state transitions as

$2^{1000}$3

requires a PUF large enough to encode all these transitions through an injection $2^{1000}$4 and a bijection $2^{1000}$5, and computes safe fallback control states by symbolic execution:

$2^{1000}$6

The distinctive claim is not merely hardware binding, but safe-by-design degradation. Earlier PUF-bound approaches could divert execution to unsafe or random states when the response was wrong; this method allows only moves to next states that preserve formally specified safety constraints. The example derives symbolic path conditions and an unsafe condition corresponding to both traffic lights being green simultaneously, then computes the set of safe phases that avoid violation. The paper explicitly addresses faulty PUF responses on the target machine as well as execution on non-target hardware.

From a SUF perspective, this line is significant because the unclonable object is the protected software behavior itself. Static analysis is argued not to reveal the correct PUF-dependent control flow, dynamic analysis on cloned hardware yields nondeterministic behavior because the PUF cannot be cloned, and tracing the correct behavior on the true target machine is described as extremely difficult and expensive. The approach remains limited by practical assumptions: manual identification of control states, formal specification of safety constraints, symbolic-execution overhead, and a PUF with enough challenge-response capacity.

6. Security assumptions, reconfigurability, and neighboring unclonable paradigms

Two neighboring physical lines are especially relevant for interpreting SUFs: dynamic key renewal and multi-level reconfigurability. The KLJN/NBL hardware-key work proposes weak, strong, and “ultra”-strong PUFs, where the “ultra”-strong version is not only unclonable but also renewed to an independent key with fresh randomness during each use via Kirchhoff-law-Johnson-noise secure key exchange (Kish et al., 2013). The Hyper PUF work proposes a reconfigurable photonic PUF in which multiple physical unclonable functions coexist simultaneously within one device through reversible all-optical transformation (Nocentini et al., 2022).

The KLJN/NBL scheme distinguishes a weak PUF as cloneable by its maker but not by others, a strong PUF as not cloneable even by its maker, and an “ultra”-strong PUF as both unclonable and dynamically renewed on each use. Its verification layer uses noise-based logic with random telegraph waves and the hyperspace-vector relation

$2^{1000}$7

together with the accidental-match probability

$2^{1000}$8

The paper also states that a brute-force counterfeiter’s success probability with an $2^{1000}$9-bit random key is $CRE=\log_2 S$0, and that minimum $CRE=\log_2 S$1 key bits must be exchanged when authenticated public bits are used for current-voltage comparison. Although this is not a software construction, it contributes a strong notion of post-use obsolescence: any accidental clone becomes useless after the next legitimate key-renewal session.

The Hyper PUF work extends a different dimension: reversible multiplicity. It models the response as

$CRE=\log_2 S$2

so the challenge includes both a probe and a transformer pattern. In the reported experiments, the single-level system yields $CRE=\log_2 S$3 independent bits, the two-level HPUF $CRE=\log_2 S$4, and the ten-level HPUF $CRE=\log_2 S$5. Entropy per symbol rises from about 0.14 bit/bit for single levels to about 0.24 bit/bit when multiple levels are jointly considered, with saturation around 8–10 levels. Here again the construction is physical rather than software, but it formalizes a useful principle: one deployed artifact can host multiple distinct challenge-response regimes without losing unclonability.

These physical results do not define SUFs directly. They do, however, clarify two design motifs that recur across the software-oriented literature. The first is renewal: a hidden state or key can evolve so that stale clones lose value. The second is multiplicity: one platform can support several independent response regimes. A plausible implication is that future SUFs may be differentiated less by whether they are “software” in a narrow sense than by how they realize hidden-state evolution, challenge-response diversity, and reproducible yet unrecoverable behavior across deployments.

7. Evaluation criteria, misconceptions, and unresolved problems

Across the literature, SUF evaluation is fragmented because the objects under study are heterogeneous. The HPC-derived IoT work uses multiclass and binary classification metrics—accuracy, precision, recall, F1, and confusion matrices—over time-series counter traces. SUC papers emphasize class size, state size, linear complexity, period, attack complexities, resource usage, and latency. SoftPUF reports regression metrics and blockchain timing rather than classical PUF reliability or entropy measures. The software-protection work focuses on symbolic safety guarantees and reverse-engineering difficulty rather than on challenge-response statistics.

A first misconception is that every SUF is a software-only object. The surveyed literature includes software-derived behavioral fingerprints, but also explicitly hardware-resident digital clone-resistant ciphers in FPGA fabric. A second misconception is that every SUF inherits the same security semantics as a classical PUF. This is not supported by the surveyed papers. HPC-derived SUFs depend heavily on which counters a device exposes and on controlled experimental conditions. SoftPUF does not provide a formal unclonability model and does not address model extraction in depth. SUCs depend on trusted one-time personalization, TRNG quality, protected storage, and restrictions on post-personalization reconfiguration. PUF-bound software protection requires a reliable runtime PUF and formally specified safety predicates.

Several unresolved problems follow directly from the papers. The HPC-derived approach notes hardware dependence, lack of standardized benchmark datasets, limited architecture scope, and incomplete treatment of compiler variability, concurrent workloads, and strong adversaries who can manipulate counters (Alshehhi, 25 Aug 2025). The SoftPUF work leaves open the exact model specification, provides no formal SUF definition, and does not study inversion, model theft, or adversarial ML attacks (Hossain et al., 4 Aug 2025). The SUC line relies on specific FPGA infrastructures, internal TRNGs, protected memory paths, and mutation or reinitialization workflows that must themselves remain trustworthy (Mars et al., 2019, Mars et al., 2021). The software-protection line is presently limited to control-state ASMs and requires manual control-state identification and explicit safety specifications (Dorfmeister et al., 11 Mar 2026).

The literature therefore suggests that SUFs should not yet be treated as a mature, uniform primitive analogous to a standardized PUF model. Instead, they comprise a technically rich but still unsettled research area at the intersection of device identification, digital clone resistance, PUF emulation, software protection, and runtime behavioral authentication. The common research ambition is consistent: to obtain device- or deployment-specific behavior that is reproducible for the legitimate platform yet difficult to copy, predict, or redeploy elsewhere. The divergence lies in where that specificity resides—hidden cipher structure, runtime microarchitectural footprint, learned software key generation, or PUF-gated control flow—and in what kind of evidence is accepted as demonstrating unclonability.