Biblio

Random number generator is an important building block for many cryptographic primitives and protocols. Random numbers are used to initialize key bits, nonces and initialization vectors and seed pseudo-random number generators. Physical Unclonable Functions (PUFs) are a popular security primitive in cryptographic systems used for authentication, secure key storage and so on. PUFs have nature properties of unpredictability and uniqueness which is very suitable to be served as a source of randomness. In this paper we propose a new design of a true random number generator based on ring oscillator PUFs. It utilizes a self-feedback mechanism between the response and challenge of PUFs and some simple operations, mainly addition, rotation and xor, on the output of PUFs to generate truly random bits. Our design is very simple and easy to be implemented while achieving good randomness. Experiment results verified the good quality of bits generated by our design.

Recently, code reuse attacks (CRAs) have emerged as a new class of ingenious security threatens. Attackers can utilize CRAs to hijack the control flow of programs to perform malicious actions without injecting any codes. Existing defenses against CRAs often incur high memory and performance overheads or require extending the existing processors' instruction set architectures (ISAs). To tackle these issues, we propose a hardware-based control flow integrity (CFI) that employs physical unclonable functions (PUF)-based linear encryption architecture (LEA) to protect against CRAs with negligible hardware extending and run time overheads. The proposed method can protect ret and indirect jmp instructions from return oriented programming (ROP) and jump oriented programming (JOP) without any additional software manipulations and extending ISAs. The pre-process will be conducted on codes once the executable binary is loaded into memory, and the real-time control flow verification based on LEA can be done while ret and jmp instructions are executed. Performance evaluations on benchmarks show that the proposed method only introduces 0.61% run-time overhead and 0.63% memory overhead on average.