dataesr/scientific-paragraphs-categorization huggingface dataset:
If the adversary receives a key generation invalid response, then the adversary will send another tuple with a different hash value. We repeat our experiment independently for each PUF response size, which leads to 5 iterations of performing HDM Attack per SRAM-PUF device. Finally, noting that per pair of SRAM dataset and PUF response size, our experiment is iterated 32 times w. r. t to our attempt to exhaustively enlarge our experimental space by iterating the experiment each time using one of the possible codewords during PUF registration and recovery. Noting the 32 times iteration is w. r. t the total number of possible values for a 5-bit binary value. Recalling that this binary value is the value which is encoded during the registration phase to produce a codeword x. Noting also that the assessment in our experimental results is based on a metric we define as the success-rate.
Here, the success-rate is defined as number of successful HDM Attack attempts over the total number of attempts. We also define the best-case success-rate as the least number of successful attempts out of total number of attempts. The worst case success-rate is the highest number of successful attacks out of total number of attempts. Finally, the average successrate is the average of the success-rate of all the cases of key generation w. r. t all possible different codewords for a given SRAM-PUF device dataset, and a given PUF response size.
VI. EXPERIMENTAL RESULTS In this section, the results of performing HDMA against our SRAM-PUF instances datasets will be discussed. FIGURE. 7 shows the best case, the worst case and the average successrate of HDMA, respectively. We clarify first that the difference in the attack success-rate between the best case and the worst case in plots (a) and (b) in FIGURE. 7 is due to the difference in the value of the codeword used per SRAM-PUF dataset per given PUF response. Recalling that the possible number of codewords are 32, due to using a 5-bit binary random number for encoding. We can see that HDM Attack against the employed Reed Muller code and the majority logic vote decoder has some significant chance of success if the PUF response is small. Although we can see that at 128-bits size, there still is a chance of success, even in the best case scenario.
At 256-bits obviously due to the doubled entropy of the guess field, no success was observed in the HDM Attack at 100 attempts per device. We now observe the success-rate of HDM Attack against FE-based key encryption with helper data masking with variable positioning. To define one source for key value and one for mask value generation, we define here 5 virtual devices wherein each device employs 2 SRAMs. Thus, each virtual device is defined to comprise 2 SRAM datasets according to Table  5. Accordingly, there is a primary SRAM dataset that is the source of key generation and the secondary SRAM dataset for mask vector generation. We note also that we employed the variable positioning step size of 16-bits which is equal to the size of a codeword in this work. This experiment is performed in three settings wherein each setting, different sizes of mask vector is considered.
FIGURE. 8 shows the results of this experiment in settings of using 1-block mask vector, 2-block mask vector, and 4block mask vector. The plots shown in the figure represent the decreasing success-rate of second order HDM Attack against 5 virtual devices as the size of PUF response for key generation increases. Noting that for the assessment using 1-block mask vector, the datasets of PUF responses for key generation are augmented from 100 responses per dataset to 10000 responses. This augmentation is performed by simply repeating each response 100 times. For the assessment using 2-block mask vector and 4-block mask vector also, the datasets are augmented to 100000 responses per dataset using the same augmentation method. Recalling also that the responses per dataset correspond to one address of the SRAM-PUF and the differentiation between them is due to the instability of the SRAM-PUF.
VII. RELATED WORKS AND COMPARISON Our proposed helper data masking is not the first work to provide a countermeasure against HDM attacks. Several countermeasures have already been proposed in  [19] -  [21]. Here we discuss some of the existing countermeasures and compare them qualitatively with our method. The work of Delvaux et al. in  [20]  explains four schemes that secure a Helper Data Algorithm (HDA)-based key generation process. The primary HDM attack detection method is originally proposed in  [32]. The method suggests to provide a hash value using collectively the helper data and the key value on the server side, and publicize it for devices to query during key generation. During key generation, the device queries the server for the hash value and compares it with a locally generated version of the hash.
If equal, the generated key is considered valid and the key can be used for encryption and decryption of the exchanged message. We have shown a similar key generation structure as shown in FIGURE. 1 which is similar to the RFE-like process discussed in  [18]. The problem with scheme is that an HDM attacker can impersonate the server and provide the hash value itself, which is on the helper data and the guessed key value. Therefore the countermeasure can be easily compromised. Considering our countermeasure however, we showed that the demasking process cannot be compromised by any modification since the position of the mask over the helper data vector is based on the true value of the mask. Similar to  [32] , another HDM detection scheme has been proposed  [33] , in which only the key value is used to generate the hash.
However, the same security issue as we explained above can be discussed here. The HDM detection can be biased just by the attacker impersonating the server and providing its own hash value for key validity check on the PUF-enabled device. Another solution has been discussed in  [20]  where it is suggested to program the public key and the helper data all into a one-time programmable NVM memory (EEPROM) during the enrollment phase of the PUF-enabled device  [34]. During the key regeneration then, the IC housing or working with a PUF component for key generation, queries the NVM memory to retrieve the helper data for key generation. This solution ultimately negates possibility of HDM attack as we discussed in this work, since there is out of device communication with a server system to query for helper data.
One can assume however that device can undergo some physical attacks using side channel analysis methods to read the information on the NVM device, and also using fault injection attacks to change some bits in order to impose helper data manipulation. These attacks however need precise tools to perform such modifications from outside of the device. This means that the attackers are enforced to employ some expensive methods. Nonetheless, the countermeasure itself is an expensive implementation, since it requires an external device to store the public key and the helper data. Moreover, using a memory component accompanying a PUF is fundamentally questioning the employment of PUF itself. Since the existence of PUF is set to replace conventional methods which save the secret values on device memories in order to provide protection against physical attacks.
A countermeasure against HDM attack is proposed by Hiller et al. in  [35] and discussed also in  [20]. The problem discussed in their work is the practice of HDM attacks that focus on single codeword modification by observing several key generation operation outputs. The authors then propose a scheme where a hash value of the helper data is XORed with the recovered PUF response to generate the key. This way, the authors ensure that at list 50% of the key values are changed and not a single one, which in turn disturbs the entire attack mechanism. The issue with this countermeasure is that it is targeted for attack methods which aim to recover the original key. While there exists other HDM attacks such as the one discussed by Becker in  [18] , for which this countermeasure is equally vulnerable to that of the RFE-like method we discussed in this work.
Therefore, this method, although providing security against HDM attacks, also imposes extensive sensitivity to PUF instability. Gao et al. in  [19]  proposes a PUF-based key generation technique and assures its security using BCH codes and syndrome decoding. Using BCH codes and syndrome decoding has good level of security against HDM Attacks as discussed in  [18]. However, it is also discussed that for [n,k,2t + 1] BCH codes with small k, it is not as efficient to use syndrome decoding compared to other simpler decoders such as maximum likelihood decoding. Merli et al. in  [21]  proposes a codeword masking scheme against helper data manipulation attacks based differential power analysis (DPA). The DPA HDM attack in their work aims to read the processed output of an inner decoder which decodes the noisy codeword that is the product of the XOR of the noisy PUF response and the received helper data.
This is similar to increasing the guessing entropy of the HDM attack as we discussed in this work. The increased entropy in turn requires more observations on the data transmitting channel to discover the correct guess for the location of the mask on the helper data. of the countermeasures discussed here were methodical and aimed at preventing the HDM attack using hardware or algorithmic solutions. Few, such as  [21]  suggested methods focus on the theoretical aspect of HDM attack and provide solutions that make the attacks more difficult to succeed. Our method also sits in this class of countermeasures. Since we also try in general to increase the guess entropy of the attacker using the proposed helper data masking method.
VIII. CONCLUSION AND FUTURE PERSPECTIVE In this work, we discussed a new masking mechanism to protect publicly available helper data in FE-based key generation protocols. Here we proposed masking helper data with variable positioning. We also proposed PUF as the source of mask value generation. Our theoretical analysis showed that helper data masking with variable positioning is a potential mechanism to drastically decrease the probability of success in attacks whose aim is to modify helper data for mutual key generation on a target device. We also performed experimental evaluations to prove the efficiency of our method over real data. Here we used real-time SRAM PUF data captured from PUF-enabled devices developed in-house. Our experimental results show that masking with variable positioning can practically decrease the probability of success of HDM Attack  VOLUME 4, 2016.
Rust is a systems programming language that offers both lowlevel memory operations and high-level safety guarantees, via a strong ownership type system that prohibits mutation of aliased state. In prior work, Matsushita et al. developed RustHorn, a promising technique for functional verification of Rust code: it leverages the strong invariants of Rust types to express the behavior of stateful Rust code with first-order logic (FOL) formulas, whose verification is amenable to offthe-shelf automated techniques. RustHorn's key idea is to use prophecies to describe the behavior of mutable borrows. However, the soundness of RustHorn was only established for a safe subset of Rust, and it has remained unclear how to extend it to support various safe APIs that encapsulate unsafe code (i. e. , code where Rust's aliasing discipline is relaxed).
Recently, several projects have developed tools for functional verification of Rust programs, with a focus on how the safety guarantees provided by the Rust type system can be exploited to simplify the verification problem. Prusti  [6]  uses information from the Rust compiler to automatically synthesize separation logic  [38]  proofs of memory safety for Rust programs in the Viper framework  [36] ; the user can then verify functional correctness on top by instrumenting the source code with additional annotations. RustHorn by Matsushita et al. [32, 33]  goes even further, eliminating separation logic from the picture entirely: they show that, using Rust's strong aliasing guarantees, the behavior of (well-typed) Rust programs can be described in firstorder logic (FOL) formulas, without any explicit representation of memory or separation logic analogues like points-to assertions.
This encoding is amenable to off-the-shelf logic solvers, as they demonstrated with fully automated verification using CHC (constrained Horn clause) solvers  [9]. However, both Prusti and RustHorn share a common limitation: they assume that the program being verified is written entirely in the safe fragment of Rust. In reality, however, many Rust programs depend on APIs that, while observably safe, are implemented internally with features that are unsafe (i. e. , not guarded by Rust's static ownership checking), such as raw pointer accesses and unchecked type casts. For example, the widely used Vec API (for growable arrays) manages its underlying buffer and performs memory access using raw pointers. The Cell API provides a restricted (e. g. , singlethreaded) form of shared mutable state, allowing the contents of a Cell to be mutated through a shared (immutable) reference to the Cell.
Prophecies are a classic technique in program verification  [1, 44, 24] , through which, when verifying a program, one can make proof decisions based on peeking into its future execution. RustHorn uses prophecies to express mutable borrows in functional style: as a pair of the current value of the object and the final (prophesied) value the object will have when the borrow ends. RustHorn's approach to simplifying the Rust verification problem has already been influential, giving rise to a semiautomated Rust verifier Creusot  [15] , which uses RustHornstyle prophecy-based translation. RustHorn also motivated recent work on CHC solving  [26]. RustBelt: Tackling Rust's type soundness semantically. Matsushita et al. [32, 33]  established the soundness of RustHorn via a syntactic proof, which supports a significant subset of the safe fragment of the Rust language.
However, this approach fundamentally bakes in the assumption that all code in the program adheres to the AXM discipline enforced by the Rust type system. As soon as any code in the program violates this discipline by using unsafe features of Rust, the syntactic approach breaks down. This limitation of syntactic proofs of soundness was previously articulated and tackled by Jung et al. [21]  in their work on RustBelt. That work developed a semantic model for a -calculus representing a substantial subset of Rust (called  Rust ) and used the model to prove an extensible type soundness theorem for Rust: not only does it verify that safe Rust code has well-defined behavior, it also stipulates what verification condition a Rust API that uses unsafe features must satisfy in order to be deemed an observably safe extension to the language.
The RustBelt soundness proof is formalized in the higherorder concurrent separation logic Iris  [25, 28, 23, 20] , which is mechanized in the Coq proof assistant  [12]  and provides an expressive logical language for modular reasoning about ownership and state. Using Iris, RustBelt verified type soundness of  Rust , along with several representative Rust APIs built from unsafe code, including Cell and Mutex. Contributions. In this paper, we present RustHornBelt, the first approach to formal verification of Rust programs that accounts soundly for the presence of (safely encapsulated) unsafe code. As the name suggests, RustHornBelt marries the benefits of RustHorn and RustBelt, providing a semantic, RustBelt-style foundation for the soundness of RustHorn-style verification. Specifically, RustHornBelt extends RustBelt's higher-order separation-logic model of Rust types to include a RustHorn-style FOL representation of types.
1) and also confirmed that our API specs are useful for (semi)-automated verification using Creusot (ğ4. 2). The key technical challenge we faced in RustHornBeltÐ which we explore in depth in ğ 3Ðwas determining how to integrate RustHorn's prophecy-based representation of Rust's mutable borrows into RustBelt. Although Jung et al. [24]  have developed an account of prophecy variables in Iris, it is not a good fit for RustHorn-style prophecies for several reasons: (a) it requires the program to be explicitly annotated with prophecy-related ghost instructions; and (b) it treats a prophecy variable name as distinct from the value it resolves to, thus making it seemingly impossible to partially resolve a prophecy to a value that mentions other prophesied values (a feature we need for modeling, e.
Limitations. Although RustHornBelt provides a machinechecked semantic foundation for RustHorn-style verification of Rust programs with unsafe code, it does not constitute an automated verification framework in itself. One must link it with a separate RustHorn-style verifier for safe Rust code (e. g. , Creusot), and the implementation of that verifier remains part of the trusted computing base (TCB). We used Creusot to confirm that our RustHorn-style specs for internally-unsafe Rust APIs are useful for automated verification of client programs; however, there remains a formal gap between RustHornBelt and Creusot. First, Creusot targets surface Rust, whereas RustHornBelt only models  Rust. Second, as it is built atop Why3  [18] , Creusot represents RustHorn-style specs as purely functional WhyML functions rather than (as in RustHornBelt) predicate transformers; that said, there is a close correspondence between the two, which we expect could be formalized in future work.
Rust APIs with Unsafe Code So far we discussed Rust's safe features. Now we present RustHorn-style specs for various Rust APIs with unsafe implementations, which we have verified in RustHornBelt. Vec API. One common use of unsafe code in Rust APIs is to provide a more efficient implementation than Rust's safe typing rules allow. A canonical example of this is the ubiquitous vector (or growable array) type Vec<T>. The Vec API manages a dynamically allocated memory block to store and provide access to an unbounded number of objects of the type T, which it achieves through effective use of raw pointers. Raw pointers are Rust pointers whose aliasing is untracked by the type system and which are therefore potentially unsafe to use. The Vec API supports a variety of operations; for RustHorn-style verification, we are particularly interested in those that perform destructive state mutation.
We give to index_mut the following RustHorn-style spec: 0 ≤ 𝑖 < |𝑣. 1| ∧ ∀𝑎 ′. 𝑣. 2 = 𝑣. 1{𝑖 ≔ 𝑎 ′ } → 𝛹 [(𝑣. 1[𝑖], 𝑎 ′ )] The precondition 0 ≤  < |. 1| is for the bounds check. In addition, we prophesy the final state  ′ of the new, subdivided borrow for the output. Now the old borrow's prophesied final state. 2 is partially determined with respect to  ′ (an example of partial prophecy resolution). It is set to. 1{ ≔  ′ }, which can be read as. 1 with the -th element's determination left to the prophesied value  ′. IterMut API. Rust's IterMut API for mutable iteratorsÐ though implemented with unsafe codeÐexemplifies how Rust's type system actually provides stronger guarantees than those of łsafež languages like Java, leveraging ownership to eliminate common pitfalls like iterator invalidation.
To meet such needs, Rust also provides a number of APIs with interior mutability, meaning 7 The actual notation used by the Rust library is SmallVec<[T;]>. that they allow mutation even through a shared reference, albeit in carefully controlled ways. Arguably the simplest such API is Cell, whose safety is guaranteed by various restrictions (e. g. , it can only be used within a single thread). It provides the following operations: fn new<T>(a: T) -> Cell<T> fn get<T: Copy>(c: &Cell<T>) -> T fn set<T>(c: &Cell<T>, a: T) You can convert a T to a cell Cell<T> by calling new. Then, using a shared reference to a cell &Cell<T> with copyable content, you can both read from the cell by get and write a new value to the cell by set. Such interior mutability is useful for writing code but makes functional verification (especially in the RustHorn style) more challenging.
For example, we can call inc_cell with the invariant. mod  = 1, where  represents another program variable k : int. For technical reasons, we restrict this dependency to non-prophesied values: we cannot choose an invariant that depends on the prophecy of a mutable borrow. This is not a strong limitation: as we explain in ğ4, one practical use case of Cell is memoization, which does not require to lift this restriction. Finally, we have also proven sound similar invariant-based specs for the Mutex API, a thread-safe variant of Cell which uses a lock to control mutable access to the shared cell.
Then, using ownership predicates, RustBelt gives a semantic model to judgments of Rust's type system. Finally, RustBelt semantically interprets Rust's syntactic typing rules and proves each of them as a separate lemma in Iris. This amounts to Rust's semantic type soundness (called the fundamental theorem of logical relations). The proof is extensible: when you add a new typing rule, all you need is to prove the new rule's semantic interpretation. Notably, this approach can flexibly support various safe Rust APIs implemented with unsafe code (like those discussed in ğ2. 3), by formulating each safe API as a set of new typing rules. The semantics is validated by the adequacy theorem, which says that a complete (i. e. , closed) and semantically well-typed Rust program will never encounter undefined behavior (formalized as a łstuck statež) under any execution trace.
Evaluation and Case Studies We evaluated our approach discussed in ğ3 by fully mechanizing the semantic soundness proof of the type-spec system in the Coq proof assistant, verifying various safe Rust APIs that encapsulate unsafe code (ğ4. 1). We also confirmed that RustHornBelt's specs for Rust APIs (such as IterMut and Cell) are in fact usable for automated verification of Rust programs, via a RustHorn-style verifier Creusot (ğ4. 2).
Mechanization in Coq We built RustHornBelt's Coq development by extending that of RustBelt  [21]. It has ~19kLOC of Coq code in total. We were able to reuse the key sub-components, the lifetime logic (~2kLOC) and the untyped core calculus ( Rust ) (~3kLOC), as well as the overarching proof structure for verifying the type system. The development took two implementors ~6 months to complete, adding ~7kLOC to the final proofs. We first modeled basic Rust types and verified type-spec rules for operations on them, extending RustBelt with functional specs. The verified basic types include: box pointer Box<T>, shared and mutable references & (mut) T, tuple (T 1 ,. ,T  ), sum T 1 + • • • + T   17  , array [T;], integer int, boolean bool, function fn(T) -> T', and recursive types  18. Then we also modeled advanced Rust types and verified type-spec rules for key API functions encapsulating unsafe code, including: • Vector Vec<T> Ð new, drop, len, push, pop, index(_mut), as_(mut_)slice/iter(_mut) Benchmarks.
Acknowledgments We thank  Ralf Jung ,  Naoki Kobayashi , and the anonymous reviewers for their helpful comments. This research was supported in part by a  European Research Council (ERC)   Consolidator Grant  for the project łRustBeltž, funded under the European Union's  Horizon 2020 Framework Programme  (grant agreement no. 683289 ), and in part by  JSPS KAKENHI  Grant Number  JP21J20459  łTheory and application for robust and high-performance systems programming languagesž.