Control Flow Protection by Cryptographic Instruction Chaining

Shahzad Ahmad

1 a

, Stefan Rass

1,2 b

, Maksim Goman

1 c

, Manfred Schl

agl

3 d

and Daniel Große

3 e

LIT Secure and Correct Systems Lab, Johannes Kepler University Linz,

Altenbergerstrasse 69, 4040 Linz, Austria

Institute for Artiﬁcial Intelligence and Cybersecurity, Alpen-Adria-University Klagenfurt, Universit

atsstrasse 65-67, 9020

Klagenfurt, Austria

Institute for Complex Systems, Johannes Kepler University Linz, Altenbergerstrasse 69, 4040 Linz, Austria

Keywords:

Secure Execution Environment, Instruction Conﬁdentiality, Control Flow Integrity, Key Derivation Chains,

Authenticated Encryption, Execution Order Veriﬁcation, Chosen-Instruction Attacks.

Abstract:

We present a novel secure execution environment that provides comprehensive protection for program ex-

ecution through a uniﬁed cryptographic approach. Our construction employs authenticated encryption, en-

suring instruction conﬁdentiality, integrity, and correct execution ordering. The system’s key innovation

lies in its cryptographic binding of consecutive instructions through a novel key chaining mechanism that

prevents instruction reordering and replay attacks while maintaining an enforced order of instructions us-

ing cryptographic chaining via keys. We introduce specialized handling for control ﬂow operations, in-

cluding branches, jumps, and function calls, that preserves security guarantees across complex execution

paths. The framework includes a protection mechanism for registers and memory, creating a fully se-

cured execution environment. Our performance analysis quantiﬁes the computational overhead and pro-

vides a Python proof-of-concept implementation that validates the practical viability of our approach https:

//github.com/shahzadssg/Control-Flow-Protection-by-Cryptographic-Instruction-Chaining.git.

1 INTRODUCTION

The security of program execution remains a criti-

cal challenge in modern computing systems as threats

grow increasingly sophisticated. Traditional protec-

tion mechanisms, such as memory isolation and ac-

cess control, are inadequate against advanced attacks

exploiting speculative execution, instruction reorder-

ing, and memory tampering (Abadi et al., 2009;

Kocher et al., 2018). This paper presents a novel se-

cure execution environment that addresses these vul-

nerabilities through a uniﬁed cryptographic approach,

ensuring instruction conﬁdentiality, integrity, and cor-

rect execution ordering.

Secure program execution requires addressing

three interrelated challenges: maintaining instruction

conﬁdentiality to prevent leakage of sensitive behav-

ior, ensuring execution integrity to protect against

https://orcid.org/0000-0002-9654-869X

https://orcid.org/0000-0003-2821-2489

https://orcid.org/0000-0002-7735-7409

https://orcid.org/0009-0007-3275-4797

https://orcid.org/0000-0002-1490-6175

tampering, and enforcing strict control over instruc-

tion order to thwart reordering attacks. These is-

sues are critical in systems processing sensitive algo-

rithms, where vulnerabilities like return-oriented pro-

gramming (ROP) (Shacham, 2007) and speculative

execution attacks (e.g., Spectre (Kocher et al., 2020))

exploit execution patterns and microarchitectural side

channels to compromise security.

Previous approaches, such as memory en-

cryption (Gueron, 2016), control-ﬂow integrity

(CFI) (Wang et al., 2012), and hardware-based so-

lutions like Intel SGX (Costan and Devadas, 2016)

and Morpheus (Gallagher et al., 2019), offer partial

protections but lack a uniﬁed framework. Memory

encryption secures data but not execution order, CFI

validates paths without ensuring conﬁdentiality, and

hardware solutions rely on speciﬁc features without

inherent ordering guarantees. These gaps leave sys-

tems vulnerable to multi-vector attacks, necessitating

a comprehensive solution that integrates all required

security properties with practical performance.

Our contribution is a secure execution environ-

ment that combines instruction conﬁdentiality, in-

tegrity protection, and execution order veriﬁcation

Ahmad, S., Rass, S., Goman, M., Schlägl, M. and Große, D.

Control Flow Protection by Cryptographic Instruction Chaining.

DOI: 10.5220/0013577700003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 233-246

ISBN: 978-989-758-760-3; ISSN: 2184-7711

233

through a cryptographic framework. This is achieved

via a novel key chaining mechanism that binds con-

secutive instructions, preventing reordering and re-

play attacks, and specialized handling of control ﬂow

operations (e.g., branches, jumps, function calls) to

maintain security across complex paths. A Python

proof-of-concept validates its feasibility, supported by

performance and security analyses.

1.1 Threat Model and Assumptions

Our threat model assumes adversaries can observe

and manipulate encrypted instructions and memory,

execute chosen-instruction attacks, and run arbitrary

code outside the secure environment, but cannot ex-

ploit microarchitectural side channels due to serial-

ized processing. We assume a secure processor with a

protected master key, symmetric encryption, HMAC,

and secure key generation capabilities, enabling guar-

antees against conﬁdentiality breaches, integrity vio-

lations, and control-ﬂow hijacking.

2 RELATED WORK

Secure execution has become critical in protecting

modern computing systems against increasingly com-

plex attack vectors. Existing approaches include

memory encryption, control-ﬂow integrity, processor

architecture enhancements, a cryptographic compu-

tation framework, and hardware-based security solu-

tions. This section reviews key developments in these

areas, highlighting the limitations that our work aims

to address through a cryptographically uniﬁed secure

execution environment.

2.1 Memory Encryption and Smart

Card Security

Memory encryption has been widely studied to pro-

tect data conﬁdentiality and integrity, particularly for

environments vulnerable to physical access or side-

channel attacks. Henson and Taylor (Henson and Tay-

lor, 2014) provided an extensive survey on memory

encryption techniques, describing strategies such as

block ciphers and integrity veriﬁcation. Specialized

implementations, such as the low-latency memory en-

cryption for smart cards presented by Ege et al. (Ege

et al., 2011), showcase memory encryption tailored

for constrained devices, balancing security with efﬁ-

ciency.

2.2 Control-Flow Integrity (CFI) and

Instruction Set Randomization

(ISR)

Control-ﬂow integrity (CFI) and Instruction Set Ran-

domization (ISR) have proven effective in defending

against code-reuse attacks and code injection attacks.

The foundational work of Abadi et al. (Abadi et al.,

2009) on CFI introduced a robust approach for secur-

ing program control ﬂow against hijacking attempts.

Tice et al. (Tice et al., 2014) expanded CFI implemen-

tation to widely used compilers like GCC and LLVM,

creating practical tools for protecting against forward-

edge attacks. ISR techniques, such as those pro-

posed by Kc et al. (Kc et al., 2003), further mitigate

code injection by randomizing instruction encoding

at runtime, preventing predictable exploit payloads.

Meanwhile, Christou et al. (Christou et al., 2020) ex-

plored architectural enhancements to support ISR, en-

suring that randomized instruction sets are resilient

to static analysis and reverse engineering. Werner

et al. (Werner et al., 2018) propose sponge-based

control-ﬂow integrity for IoT, leveraging lightweight

cryptography. Savry et al. (Chamelot et al., 2022) in-

tegrate instruction and data authenticated encryption

(Conﬁdaent) for holistic protection.

2.3 Data-Oblivious and Encrypted

Computation

Data-oblivious computation frameworks have

emerged to facilitate secure computations on un-

trusted platforms by concealing data access patterns.

PHANTOM, proposed by Maas et al. (Maas et al.,

2013), utilizes oblivious RAM to secure memory

accesses, ensuring that patterns reveal minimal

information to potential adversaries. Similarly,

Liu et al. (Liu et al., 2015) developed ObliVM, a

programming framework for oblivious computation,

offering support for cryptographic protocols and

secure multiparty computation. Rass et al. (Rass

et al., 2015) introduced Oblivious Lookup-Tables

(OLUTs), enabling arbitrary function evaluation on

encrypted data using group homomorphic encryp-

tion through clever use of Vandermonde matrices,

offering an efﬁcient middle ground between basic

homomorphic schemes and fully homomorphic

encryption (FHE). HEROIC, introduced by Tsoutsos

and Maniatakos (Tsoutsos and Maniatakos, 2014),

implemented homomorphic encryption within a

minimalistic one-instruction architecture, proving

useful for encrypted cloud computing and privacy-

preserving processing. However, these frameworks

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

234

often need more formulation which come at a higher

computational cost.

2.4 Side-Channel and Cache Attack

Mitigation

As side channel attacks become more sophisticated,

research has turned to mitigating vulnerabilities in

cache and timing. Gruss et al. (Gruss et al., 2015)

presented cache template attacks, demonstrating how

adversaries can exploit last-level cache inclusivity for

information leakage. Speculative execution vulnera-

bilities, as exposed by Kocher et al. (Kocher et al.,

2020) with the Spectre attacks, further underscored

the need for more rigorous protections at the hard-

ware level. In response, Rass and Schartner (Rass and

Schartner, 2016) examined countermeasures against

chosen instruction attacks within cryptographic en-

vironments, proposing instruction veriﬁcation to pre-

vent unauthorized instruction modiﬁcation.

2.5 Cryptographic Techniques for

Execution Order and Integrity

Recent research has focused on cryptographic meth-

ods to enforce correct instruction sequencing and pro-

gram integrity. Zahur et al. (Zahur et al., 2015) in-

troduced a half-gate approach to reduce data trans-

fer in garbled circuits, improving efﬁciency in cryp-

tographic computation. Zahur and Evans (Zahur and

Evans, 2015) developed Obliv-C, a language for ex-

tensible data-oblivious computation, enabling ﬂexi-

ble applications in privacy-preserving environments.

The formal veriﬁcation of control-ﬂow graph ﬂatten-

ing by Blazy and Trieu (Blazy and Trieu, 2016) high-

lights ongoing efforts to ensure control-ﬂow integrity

within cryptographic environments, preventing adver-

sarial manipulation of execution order. De Clercq et

al. (de Clercq et al., 2017) (SOFIA) combine soft-

ware and control-ﬂow integrity for embedded sys-

tems. Stecklina et al. (Stecklina et al., 2015) intro-

duced Intrinsic Code Attestation, which uses cryp-

tographic instruction chaining for embedded devices

to prevent unauthorized code execution and instruc-

tion reordering attacks. Their work demonstrated the

feasibility of creating cryptographic dependencies be-

tween consecutive instructions using block ciphers,

providing early validation of instruction chaining con-

cepts in resource-constrained environments.

Our approach leverages key aspects from prior

works, introducing a cryptographically uniﬁed secure

execution environment that combines data conﬁden-

tiality, integrity, and execution order veriﬁcation. This

work extends current models by addressing forward

and backward secrecy in instruction sequences, offer-

ing tamper detection and replay protection against so-

phisticated attacks. The unique key mechanism in our

approach not only enhances security but also simpli-

ﬁes the execution process. Like Morpheus II (Harris

et al., 2021), we employ strong cryptography to pro-

tect code and control data. However, we advance be-

yond simple encryption by creating a cryptographic

binding between consecutive instructions through our

key chaining mechanism.

3 CONSTRUCTION

We present a novel secure execution environment that

provides conﬁdentiality and integrity protection for

instructions and data while ensuring correct execution

order even in the presence of adversarial tampering

attempts. The system employs a combination of sym-

metric encryption, HMAC, and a unique key chain-

ing mechanism to create a provably secure execution

model.

3.1 System Model and Notation

We consider a processor architecture with the follow-

ing essential components. The system uses a set of

registers R = {r

, r

, . . . , r

} alongside an instruction

memory I and data memory M, both storing encrypted

content with authentication tags. Program execution

is tracked via an instruction pointer ip ∈ N, while an

encrypted call stack manages function calls and re-

turns. The architecture’s security relies on crypto-

graphic primitives including symmetric encryption E,

decryption D, an HMAC function H, and a secure ran-

dom key generator KeyGen. We use the following no-

tation:

• K

: The Master key is known only to the secure

processor. The complete life cycle of this key (in-

cluding creation, distribution, usage, rotation and

destruction processes) is outside the scope of this

paper. We assume secure processes are in place to

manage this key.

• K

: Key used to decrypt registers before exe-

cuting an instruction

• K

: Key used to encrypt registers after execut-

ing an instruction

• K

ret

: Randomly generated key to be put onto the

stack

• E

(m): Symmetric encryption of message m un-

der a key K

Control Flow Protection by Cryptographic Instruction Chaining

235

• D

(c): Symmetric decryption of ciphertext c un-

der a key K

• H

(m): HMAC of message m under key K

• KeyGen(t) : {0, 1}

, a cryptographically secure

random key generator that produces a key of

length t, where t is the security parameter

3.2 Cryptographic Chaining and

Instruction Execution

Our system employs a key chaining mechanism to en-

sure the correct order of instruction execution and to

prevent various attacks, including instruction reorder-

ing and replay attacks. This mechanism creates a

cryptographic binding between consecutive instruc-

tions, effectively forming a chain of keys that must

be followed for correct execution. The key derivation

chain operates as follows:

3.2.1 Initialization

For the ﬁrst instruction I

• K

← K

(the Master key)

• K

← KeyGen(t) (a randomly generated key, in-

dependently generated afresh for each instruction)

3.2.2 Sequential Instructions

These basic arithmetic, logic, and data movement in-

structions within the register ﬁle (e.g. MOV) execute

in sequence without altering the control ﬂow. These

instructions maintain the strict sequential execution

order through the cryptographic chaining mechanism,

where the previous key of each instruction must cor-

respond to its predecessor’s next key. For each se-

quential instruction I

(where i > 0):

The key mechanism operates as follows:

• K

← K

of instruction I

i−1

(the previous in-

struction’s next key)

• K

← KeyGen(t) (a freshly generated random

key)

The key derivation chain works in conjunction with

the instruction encoding scheme. Each instruction is

encoded as a tuple:

= (op

, args

, K

prev,i

, K

next,i

)

Each instruction i comprises four essential ele-

ments: the opcode (op

is encoded as 8 bits) that de-

ﬁnes the operation, instruction arguments( args

) as

32-bit values (though other bit lengths are supported),

prev,i

(128 bits) for decrypting registers before exe-

cution, and K

next,i

(128 bits) for encrypting registers

after execution. This structure ensures secure instruc-

tion handling throughout the execution cycle. The in-

struction is then processed and stored as:

= H

)

= E

||T

)

where T

is the authentication tag for instruction I

and || denotes concatenation.

Execution Process

The execution of a sequence of instructions proceeds

as follows:

i) Fetch encrypted instruction C

at address ip

ii) Decrypt and verify integrity:

• (I

′

||T

′

) = D

)

• T

∗

= H

′

)

• If T

∗

̸= T

′

, halt execution

iii) Parse I

′

= (op

, args

, K

)

iv) Decrypt registers: For each register j ∈ {1, . . . , n},

= D

(R[ j]). In this register system, j serves

as the register index within the total set of n reg-

isters in the bank. The system maintains two rep-

resentations for each register: R[ j] represents its

encrypted state, while r

holds the corresponding

decrypted value used during computation. This

dual representation enables both secure storage

and practical usage of register contents.

v) Execute instruction (op

, args

) on decrypted reg-

isters

vi) Update state: registers and memory

vii) Encrypt updated registers: For each register j in

{1, . . . , n}: R[ j] = E

)

viii) Update ip (instruction pointer) based on instruc-

tion type.

In our model, cryptographic chaining enforces

a strict sequential order across all pipeline stages:

fetch, decode, execute, and commit. Each instruc-

tion’s decryption and validation depends on the cryp-

tographic key from its predecessor, serializing the

entire pipeline. Unlike traditional out-of-order ar-

chitectures where only commit/retirement stages en-

force program order, our scheme restricts parallelism

at every stage. Functional units cannot process in-

structions out-of-order, as the cryptographic binding

requires the prior instruction’s key to unlock subse-

quent operations. This ensures that even if dependen-

cies theoretically allow reordering, the cryptographic

chain mandates sequential progression.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

236

3.2.3 Conditional Branches

Our secure execution environment handles condi-

tional branches through a deterministic key deriva-

tion mechanism that maintains cryptographic conti-

nuity across both potential execution paths.

For a conditional branch instruction I

• K

← K

of the previous instruction

• K

next f alse

← KeyGen(t) if the branch is “non-

taken” (sequential)

• However, if the branch is “taken” then for the

branch instruction’s K

next true

, the function must

have properties:

i) the output must be suitable for use as an en-

cryption key, typically a ﬁxed-length bit string

matching the security parameter t

ii) the computation must be deterministic but

depend on both the target label and the

master key K

to prevent adversaries from

computing it themselves. This can be ex-

pressed as: K

next true

← f unc(target label) =

(target label)

A target label represents a secure destination identi-

ﬁer within the execution environment that serves mul-

tiple critical purposes in the control ﬂow mechanism.

It is an integral component encoded within various

control transfer instructions (conditional branches,

unconditional jumps, and function calls) that speci-

ﬁes where program execution should continue. The

target label is both encrypted and integrity-protected

through HMAC veriﬁcation, and plays a crucial role

in the cryptographic key derivation process through

the function f unc(target label). This design ensures

that only authorized code possessing the master key

can compute valid keys for execution at target loca-

tions. The target label maintains the cryptographic

binding between source and destination instructions

while enabling secure control transfers, as it serves as

the basis for deriving the next encryption key (K

)

that will be used to verify proper execution sequenc-

ing at the destination. This mechanism prevents unau-

thorized jumps or execution reordering while allow-

ing legitimate program control ﬂow to proceed se-

curely within the encrypted execution environment.

The above key derivation for K

next true

provides

critical security properties. First and foremost, only

entities possessing the master key K

can compute

next true

, ensuring that key derivation remains re-

stricted to authorized parties within the secure exe-

cution environment. The construction’s determinis-

tic nature means that identical labels consistently pro-

duce the same keys, which is essential for maintaining

execution consistency across multiple runs of the pro-

gram. Additionally, the output maintains the crypto-

graphic operations. The use of HMAC ensures that

different labels produce cryptographically indepen-

dent keys, preventing any potential key-relation at-

tacks. This independence property is crucial for main-

taining security isolation between different branches

in the program’s execution ﬂow.

The conditional branch instruction is encoded

as:The conditional branch instruction

= (BR

cond

,target label, K

, K

next true

, K

next f alse

)

The conditional branch instruction consists of sev-

eral key components that work together to ensure

secure execution ﬂow. The instruction uses BR

cond

to represent a generic conditional branch operation

that can handle any type of branching logic. The

target label speciﬁes the destination address in the

program’s code where execution should proceed af-

ter the control ﬂow transfer, whether it’s from a jump,

branch, or function call. To maintain security dur-

ing branching, the system employs two distinct keys:

next true

for when the branch is taken and execution

moves to the target address, and K

next f alse

for when

the branch is not taken and execution continues se-

quentially. This dual-key structure ensures crypto-

graphic separation between the two possible execu-

tion paths.

Execution Process

The execution of a conditional branch instruction

proceeds as follows:

←

(

next true

: if branch taken = True

next f alse

: if branch not taken = False

ip =

(

target label : if branch taken = True

ip + 1 : if branch not taken = False

When execution continues at a target label loca-

tion, the key chaining mechanism ensures proper se-

quential execution 3.2.2 resumes from that point.

The instruction format for sequential instructions

op, args, K prev, K next = 8 + 32 + 128 + 128 =

296 bits and for conditional branch it includes a

target label (32 bits) and

next true

, K

next f alse

(2 × 128 bits). In order to mit-

igate the memory overhead, the deterministic keys

(e.g., H

(target label)) reduces storage for branch

targets and in future we will explore in compressing

authentication tags or using shorter keys (e.g., 64-bits

truncated HMACs).

Control Flow Protection by Cryptographic Instruction Chaining

237

3.2.4 Unconditional Jumps (JMP)

Unlike conditional branches, unconditional jumps al-

ways transfer control to their target location. The key

management must be such that the key for the next

instruction is computable from any point in the pro-

gram, i.e., we let this key depend on the jump target

and the secret master key to avoid an attacker com-

puting it from the source code already.

For an unconditional jump instruction I

jmp

• K

← K

of the previous instruction

• K

← f unc(target label) = H

(target label)

The jump instruction is encoded as:

jmp

= (JMP,target label, K

, K

)

The unconditional jump instruction consists of three

core components that enable secure control ﬂow

transfer. The JMP opcode designates an uncondi-

tional jump operation that transfers execution to a

new location, while the target label speciﬁes the ex-

act destination address where execution will continue.

The third component, K

, is a cryptographic key de-

rived deterministically from the target label to main-

tain security throughout the jump operation.

The keychain operation for jumps follows a

carefully designed sequence to ensure security.

First, K

is computed deterministically using the

f unc(target label) function. This deterministic

derivation ensures that any jump targeting the same

label will generate identical key values, providing

consistency in the security mechanism. Finally, this

approach creates a robust cryptographic binding be-

tween jump instructions and their target locations,

preventing unauthorized modiﬁcations to the control

ﬂow. This three-part mechanism works together to

maintain both the integrity and security of program

execution during unconditional jumps.

Execution Process

The execution of an unconditional jump instruction

proceeds as follows:

i) Encrypt registers with K

←

f unc(target label)

ii) Transfer control to target label location

iii) Target instruction must use jump’s K

at its

3.2.5 Function Calls

Our secure execution environment implements func-

tion calls using a deterministic key derivation mecha-

nism for function entry points, ensuring consistent ac-

cess across multiple calls. Furthermore, each CALL

instruction is assumed to have a corresponding RET

(return) instruction.

For a function call instruction (CALL):

• K

← K

of the previous instruction

• K

← f unc(target label) is deterministically

derived from the target label

• K

ret

← KeyGen(t)

The CALL instruction is encoded as a tuple:

call

= (CALL, target label, K

, K

)

Execution Process

i) Registers are decrypted using the K

of the

CALL instruction

ii) The return address (ip

ret

) is set to the address of

the next instruction after the call function is per-

formed

iii) The K

of the RET instruction is denoted by

ret

, and it is put on the stack (together with ip

ret

)

and will be used as K

for the instruction where

execution returns.

iv) The return information is encrypted and pushed

onto the call stack:

push

= E

(ip

ret

∥ K

ret

∥ H

(ip

ret

∥ K

ret

))

v) Registers are encrypted using the K

of the

CALL instruction, and this next key will become

the previous key for the called function

vi) The instruction pointer is set to the target address

of the called function.

This approach ensures that the return address and

key are securely stored and cannot be tampered with

during the function execution.

3.2.6 Function Returns

The return mechanism (RET instruction) is designed

to securely restore the execution context and maintain

the integrity of the key chain.

For a return instruction:

• K

← K

of the previous instruction

• K

is obtained from the call stack

The RET instruction is encoded as:

ret

= (RET, K

, ∗)

where ∗ indicates K

will be determined at run-

time from the call stack.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

238

Execution Process

i) Call Stack Retrieval: The encrypted return infor-

mation is popped from the call stack:

pop

= top element of the call stack

ii) The return information is decrypted and veriﬁed:

(ip

ret

, K

ret

, T ) = D

pop

)

∗

= H

(ip

ret

∥ K

ret

)

If T

∗

̸= T , execution is halted due to potential

tampering.

iii) The instruction pointer is set to ip

ret

iv) K

is set to K

ret

v) Registers are encrypted using K

ret

(which be-

comes the K

for the next instruction).

This mechanism ensures that:

a) The return address cannot be manipulated during

function execution.

b) The key chain integrity is maintained across func-

tion calls and returns.

c) Any tampering with the call stack or attempt to re-

turn to an unauthorized location will be detected.

By implementing function calls and returns this

way, our secure execution environment maintains a

continuous chain of keys throughout the program’s

execution, including across function boundaries. This

approach provides strong protection against vari-

ous attacks, including return-oriented programming

(ROP) and other control-ﬂow hijacking attempts. The

key derivation chain mechanism makes sure that the

correct execution order is maintained even in the pres-

ence of complex control ﬂow structures. The use of

distinct keys for different execution paths (K

next true

and K

next f alse

for branches, K

ret

for function returns)

provides strong cryptographic binding between in-

structions and their intended execution sequence. The

key derivation chain provides several security proper-

ties:

1. Instruction Ordering: The chain assures that in-

structions can only be executed in the intended

order, even across branches and function calls.

2. Replay Protection: Each instruction uses unique

keys, preventing replay attacks.

3. Forward Secrecy: Compromising one instruc-

tion’s keys does not reveal information about sub-

sequent instructions.

4. Backward Secrecy: Similarly, compromising one

instruction’s keys does not allow the derivation of

keys for previous instructions.

CALL subtract ,

subtract: ,

SUB AX, BX ,

RET ,

MOV CX, AX ,

MOV DX, AX ,

CMP DX, 1

MOV DX, 0

equal_one: ,

MOV DX, 100 ,

JMP end ,

end: ,

MOV AX, 10 (Master) , (random)

MOV BX, 3 ,

CALL subtract ,

false

Push

Legends

MOV/SUB/JMP:

CALL:

CMP:

Labels:

RET:

Stack Op:

Normal Flow:

Push

true

BEQ equal_one

Pop

Figure 1: Execution ﬂow example.

Figure 1 presents an illustration of the execution ﬂow

in the secure execution environment, demonstrating

how the key chaining mechanism works across vari-

ous instruction types and control ﬂow operations. The

execution ﬂow begins with basic instructions, starting

with MOV AX, 10 that uses the master key (K

) as

and generates a random K

as K

, followed

by MOV BX, 3 which continues the key chain. The

diagram then shows how function calls are handled,

with a CALL subtract instruction that derives its K

using a special function of the target label. The func-

tion call mechanism is illustrated with stack opera-

tions, showing how return keys (K

ret

) are pushed onto

the stack, and how the subtract function executes its

operations (including SUB AX, BX) before returning

via a RET instruction.

Control Flow Protection by Cryptographic Instruction Chaining

239

The ﬁgure also demonstrates the handling of com-

plex control ﬂow operations, including conditional

branching through a CMP DX, 1 instruction followed

by a BEQ equal one branch. This shows how the

system manages different execution paths, with sep-

arate key chains maintained for both the taken and

not-taken paths of the branch. The diagram includes

an unconditional jump (JMP end) as well, illustrating

how control ﬂow is maintained across different types

of transfers. Throughout the execution ﬂow, the dia-

gram uses a clear visual notation system with distinct

shapes for different instruction types, directional ar-

rows showing execution ﬂow, and dotted lines indicat-

ing the stack operation. The key transitions between

instructions are explicitly labeled, showing how K

and K

values are maintained and derived through-

out the program’s execution. This visualization effec-

tively demonstrates how the system maintains cryp-

tographic continuity while handling complex control

ﬂow structures, ensuring secure execution across all

program paths.

3.2.7 Asynchronous Events: Interrupts and

Exceptions

Asynchronous events, such as interrupt requests

(IRQs) and processor exceptions, pose a unique chal-

lenge to the strict sequential and deterministically

chained execution ﬂow described so far. These events

occur at unpredictable times, forcing a transfer of con-

trol to a speciﬁc handler routine outside the program’s

planned control ﬂow graph. To maintain the secu-

rity guarantees of cryptographic instruction chain-

ing across asynchronous context switches, the sys-

tem must securely handle the saving of the interrupted

task’s state and key context, the execution of the han-

dler, and the secure restoration of the original task’s

state upon return. When an asynchronous event oc-

curs:

1. Interrupt Recognition and State Save: The secure

processor recognizes the interrupt or exception.

Before executing the ﬁrst instruction of the han-

dler, it must securely save the full execution state

of the interrupted task. This includes:

• The Instruction Pointer ip of the instruction that

would have executed next.

• The current register state R = {r

, r

, . . . , r

} in

their encrypted form.

• Crucially, the current cryptographic key con-

text, speciﬁcally the K

and K

keys asso-

ciated with the instruction at the saved ip.

This entire saved state context must be encrypted

and authenticated using the master key K

and

pushed onto a dedicated, secure system stack or

save area. Similar to the function call stack (Sec-

tion 3.2.5), this secure save area prevents tamper-

ing with the interrupted task’s context.

Saved Context = E



ip∥R ∥ K

prev saved

∥K

next saved

∥

(ip∥R ∥ K

prev saved

∥K

next saved

)



2. Handler Entry Key Derivation: The system must

determine the entry point address of the speciﬁc

interrupt or exception handler. This lookup pro-

cess (e.g., via a vector table) is assumed to be

secure and protected. The handler’s entry point

needs a K

key to begin execution within the

secure environment. This key must be determin-

istically derived in a way that is secure and tied to

the speciﬁc handler.

Similar to function calls (Section 3.2.5), we use a

deterministic derivation based on the handler’s se-

cure identiﬁer or address and the master key K

handler entry

= f unc(handler ID) = H

(handler ID)

This K

handler entry

becomes the K

for the ﬁrst

instruction of the handler.

3. Handler Execution: The processor transfers con-

trol to the handler’s entry point using K

handler entry

as the initial K

. The handler executes using the

standard sequential chaining mechanism (Section

3.2.2). If the handler involves branches, jumps, or

function calls, those are handled as described in

Sections 3.2.5–3.2.6, maintaining chain continu-

ity within the handler’s execution path.

4. Return from Handler: A special instruction, anal-

ogous to RET , is required to return from an inter-

rupt or exception handler (e.g., RET ). The K

for this RET instruction is the K

generated by

the last instruction of the handler.

The execution of RET involves:

• Retrieving and decrypting the Saved Context

from the secure save area using K

• Authenticating the restored context using the

included HMAC tag. If veriﬁcation fails, ex-

ecution halts.

• Restoring the saved ip, register state (now de-

crypted using K

prev saved

), and the saved key

context K

prev saved

and K

next saved

• The restored K

next saved

becomes the K

for

the instruction at the restored ip.

3.3 Register and Memory Protection

Our secure execution environment implements a pro-

tection mechanism for both register content and mem-

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

240

ory locations, ensuring conﬁdentiality and integrity

throughout program execution.

3.3.1 Register Protection

Each register’s contents are encrypted and authenti-

cated after the execution of every instruction. For a set

of registers R = {r

, r

, . . . , r

}, the protection scheme

operates as follows:

a) Before instruction execution:

• Registers are decrypted using K

from the

current instruction

• r

= D

(R[ j]) for each register j ∈ {1, . . . , n}

b) After instruction execution:

• Registers are encrypted using K

from the

current instruction

• For each register j:

R[ j] = E

||H

))

3.3.2 Memory Protection

Data memory locations are encrypted (with integrity

protection) using the master key:

M[addr] = E

(data||H

(data))

This allows data sharing between different code

sections while maintaining conﬁdentiality and in-

tegrity.

3.4 System Architecture Overview

The secure execution environment’s components, in-

cluding the secure processor, encrypted instruction/-

data memory, encrypted register ﬁle, and crypto-

graphic modules (encryption, HMAC, key genera-

tor) with Master Key inside the tamper proof region.

The architecture enforces a strict in-order execution

pipeline where each stage (fetch, decrypt, execute,

encrypt) depends on the previous instruction’s cryp-

tographic key.

Impact on High-Performance Features

• Pipelining: Pipeline stages integrate decryption

and key derivation. For example, the “Decrypt”

stage veriﬁes HMAC tags and decrypts registers

using K

, while the “Encrypt” stage updates

registers with K

. This introduces latency but

preserves pipelining for sequential code.

• Out-of-Order Execution: Disabled by design, as

the key chain enforces sequential dependencies.

Performance loss is mitigated through hardware-

accelerated cryptography (e.g., AES-NI).

• Branch Prediction: Predictions are allowed, but

mispredictions force a pipeline ﬂush. Target la-

bels and derived keys (K

next true

) are deterministic,

enabling precomputation for predicted paths.

4 SECURITY ANALYSIS

Our security analysis follows a systematic catalog-

based methodology that examines the system’s de-

fenses across multiple attack surfaces and security

properties. The framework evaluates four primary

interconnected categories: execution order security,

control ﬂow security, state protection, and key man-

agement. Execution order security encompasses pro-

tections against out-of-order execution, instruction re-

ordering resistance, sequential execution guarantees,

and edge case handling. Control ﬂow security ad-

dresses branch instruction protection, jump target val-

idation, function call/return integrity, and key chain

continuity. State protection covers register state con-

ﬁdentiality, memory access security, stack integrity,

and context switching security. Key management ex-

amines key derivation security, forward/backward se-

crecy, key chain integrity, and cryptographic binding

strength 5.2. This structured methodology enables

us to evaluate the system’s security properties and

demonstrate resistance against both known attack pat-

terns and potential new threat vectors.

4.1 Security Against Out-of-Order

Execution

Our implementation practically prevents known at-

tacks like the “Chosen Instruction Attack” from (Rass

and Schartner, 2016). Our design incorporates several

features to counter chosen instruction attacks and pro-

vide security against Out-of-Order execution:

4.1.1 Key Chaining Protection

a) Initial State Security: The ﬁrst instruction I

es-

tablishes security through the master key K

as its

, where this master key remains exclusively

known to the secure processor. For initialization,

is generated randomly for each instruction

(except for labels).

b) Sequential Execution Protection: Each subse-

quent instruction I

maintains execution order by

requiring its K

to match the K

of the previ-

ous instruction. The register decryption process

succeeds only when this key matching is valid.

The system generates a fresh K

using a cryp-

Control Flow Protection by Cryptographic Instruction Chaining

241

tographic RNG, ensuring uniqueness and unpre-

dictability.

c) Chain Integrity: The instruction integrity re-

mains protected through HMAC validation un-

der the master key. The system establishes cryp-

tographic bindings between consecutive instruc-

tions through key transitions. Throughout execu-

tion, all register states maintain their encrypted

form between instructions, preventing unautho-

rized access or modiﬁcation.

4.1.2 Attack Resistance

The system resists attacks by generating unique, un-

predictable K

values via a cryptographic RNG,

rendering key prediction negligible; HMAC protec-

tion ensures instruction integrity, preventing forgery

without the master key; and cryptographic chaining

validates each step, making reordering infeasible un-

der standard assumptions.

4.1.3 Sequential Execution Guarantees

The system ensures sequential execution through

cryptographic chaining, requiring key validation at

each step to maintain secrecy and halt violations; it

veriﬁes predecessors via the key chain, protecting

preventing skipping, replays, and insertions through

cryptographic bindings.

4.1.4 Analysis of Key Chain Edge Cases

a) Branch Point Instructions: When a conditional

branch instruction has been executed, both paths

must have valid keys, i.e. K

next true

derived from

target label and K

next f alse

randomly generated.

An attacker might try to force execution down the

unintended path. However, this fails since branch

condition evaluation depends on register values

that remain encrypted and MAC-protected, pre-

venting condition tampering.

b) Function Entry Points: Multiple CALL instruc-

tions targeting the same function could provide an

opportunity since they all generate the same K

through f unc(target label). An attacker might

try to redirect execution to a different valid call

site. However, the call stack’s encryption and in-

tegrity protection and the protected register state

prevent unauthorized control ﬂow changes.

c) Convergence Points: Program points where mul-

tiple execution paths converge, such as after con-

ditional blocks or at function returns, necessarily

share the same next instruction with the associ-

ated key. An attacker might attempt to jump to

these points prematurely. This fails because:

• The register state remains encrypted under the

previous path’s keys

• The stack state containing return information is

encrypted and integrity-protected

• Key derivation depends on the master key K

which remains inaccessible

• The MAC mechanism protects all state transi-

tions

Therefore, even in cases where multiple paths lead

to instructions sharing the same next key, the cryp-

tographic protections on the program state prevent an

attacker from successfully exploiting these situations

to execute instructions out-of-order.

The system maintains its security guarantees

through the combination of encrypted states, pro-

tected control ﬂow information, and key derivation

chain, even in the presence of multiple valid execu-

tion paths sharing key information.

4.2 Security Analysis of Control Flow

Mechanism

The control ﬂow mechanism’s security is built upon

several interconnected layers of protection. At its

foundation, conditional branching security ensures

secure execution through multiple key properties. The

system evaluates branch conditions using register val-

ues decrypted with the previous key (K

), keeping

these decrypted values conﬁned within a secure en-

vironment. This evaluation process produces a bi-

nary outcome that deﬁnitively determines the execu-

tion path.

Each branch instruction maintains two distinct

next keys: K

next true

for the branch path taken and

next f alse

for the branch path not taken. The true path

key is deterministically derived from the target label

using the function f unc(target label). This dual-key

approach prevents unauthorized path execution while

maintaining the integrity of the key chain. The sys-

tem further protects branch targets through encryption

within the instruction itself, with integrity checks pre-

venting any tampering with target addresses. The key

derivation mechanism creates a cryptographic binding

between each target and its execution path.

4.2.1 Unconditional Jump Security

For unconditional jumps, the system maintains secu-

rity through several mechanisms. Jump targets are

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

242

encrypted within the instruction, and integrity veri-

ﬁcation prevents any target manipulation. The de-

terministic key derivation ensures consistent and se-

cure target resolution. The key chain remains unbro-

ken across jumps through careful key management,

where the next key is derived deterministically from

the jump target. This ensures that only authorized

code at the target labels can execute.

4.2.2 Function Call and Return Security

The function call mechanism ensures security by en-

crypting return addresses and pairing them with a ran-

dom key (K

ret

) on the stack, maintaining key chain

continuity across boundaries. Context and register

states are encrypted during switches, preventing tam-

pering. Returns verify stack data and K

ret

, restoring

the context securely to reconnect the key chain, allow-

ing execution only to veriﬁed addresses. This robust

system prevents return-oriented programming (ROP),

jump-oriented programming (JOP), control-ﬂow hi-

jacking, and stack-smashing attacks through crypto-

graphic bindings and integrity checks, leveraging in-

struction conﬁdentiality and integrity for comprehen-

sive protection.

4.3 Security Against Asynchronous

Events

The handling of asynchronous events like interrupts

and exceptions is secured through a dedicated mech-

anism built upon the principles of cryptographic state

protection and deterministic key derivation, comple-

menting the control ﬂow security discussed in Sec-

tion 3.2.7.

• Saved Context Conﬁdentiality and Integrity:

The entire state of the interrupted task, includ-

ing the instruction pointer, register contents (in

their encrypted form), and the crucial key context

prev saved

, K

next saved

), is encrypted and authenti-

cated using the master key K

before being stored

in a secure save area. This prevents an adversary

from observing or tampering with the task’s state

or key material while the handler is executing.

• Secure Handler Entry: The K

key used for

the ﬁrst instruction of the interrupt/exception han-

dler (K

handler

entry

) is derived deterministically us-

ing the master key K

and a secure identiﬁer

for the speciﬁc handler (H

(handler ID)). This

prevents an attacker from forcing execution into

an unauthorized handler or entering a legitimate

handler with a predictable key, as computing the

correct entry key requires the master key.

• Tamper-Evident Return: The IRET instruction

veriﬁes the integrity of the restored context (in-

cluding the saved keys) using the HMAC tag gen-

erated under K

. Any modiﬁcation to the saved

state between interruption and return will be de-

tected, causing execution to halt.

• Key Chain Continuity: The mechanism ensures

seamless key chain continuity for the interrupted

task upon return. By saving the original K

and K

and making the saved K

the K

for

the resumed instruction, the system effectively re-

establishes the correct cryptographic link, allow-

ing the task to continue within its original, ver-

iﬁed instruction sequence. This prevents attack-

ers from injecting instructions or replaying saved

contexts at arbitrary points.

• Isolation: The handler executes within its own se-

cure context, starting with a key independent of

the interrupted task’s chain (derived from the han-

dler ID, not the interrupted task’s keys). This pro-

vides isolation between the handler and the inter-

rupted task’s execution state and key material.

4.4 Forward and Backward Secrecy

Informal proof that learning any single instruction-

key K

does not compromise earlier or later keys.

Forward Secrecy: Even if an adversary learns K

, they

cannot compute K

i+1

, K

i+2

, . . . because each future

key is either K

j+1

← KeyGen(t) (a fresh, independent

RNG output). Neither case allows inversion from K

to K

i+1

Backward Secrecy: Even if an adversary learns

, they cannot recover K

i−1

, K

i−2

, . . . because both

RNG-drawn keys and PRF-derived keys are pre-

image–resistant: K

= KeyGen(t) admit no efﬁcient

mapping back to earlier values.

5 PERFORMANCE ANALYSIS

This section describes an analysis of the computa-

tional overheads introduced by our secure execution

environment.

5.1 Performance Analysis

The performance analysis considers a program with

n total instructions, including n

conditional branch

(BEQ) instructions, n

function calls (CALL), n

function returns (RET), n

unconditional jumps

(JMP), and n

memory operations (LOAD/STORE).

Control Flow Protection by Cryptographic Instruction Chaining

243

The core cryptographic operations each have com-

plexity O(k) for input size k: encryption (E ), decryp-

tion (D), HMAC computation (H ), and key deriva-

tion (K ).

For basic instruction execution, each instruction

requires encryption/decryption of both the instruc-

tion itself and the register state (E + D) each, plus

two HMAC operations (2H ), yielding a complex-

ity of O(n(2E + 2D + 2H )), which simpliﬁes to

O(nk). Control ﬂow operations add additional over-

head: conditional branches require O(n

(2K + E +

D)), function calls need O(n

(2E + H + K )), re-

turns take O(n

(D + H )), and unconditional jumps

use O(n

(K + E)). Memory operations contribute

O(n

(E + D + H )).

The total computational complexity sums these

components:

total

= O(n(2E + 2D + 2H )) + O(n

(2K + E + D))+

O(n

(2E + H + K )) + O(n

(D + H ))+

O(n

(K + E)) + O(n

(E + D + H ))

= O(k(n + n

+ n

))

Since n

, n

are all subsets of total in-

structions n, their sum cannot exceed n. Therefore,

the ﬁnal complexity simpliﬁes to C

total

= O(nk).

While our scheme provides strong security guar-

antees, its strict serialization introduces performance

trade-offs compared to modern out-of-order architec-

tures. In out-of-order designs, instruction reordering

and speculative execution hide latency and maximize

functional unit utilization. By contrast, our crypto-

graphic chaining creates hard dependencies that seri-

alize pipeline stages, leading to:

1. Pipeline stalls: Instructions cannot proceed until

predecessors are decrypted and veriﬁed.

2. Branch penalties: Conditional branches exacer-

bate delays, as both paths require cryptographic

validation before resolution.

3. Limited parallelism: Functional units remain idle

if subsequent instructions are cryptographically

blocked.

4. Asynchronous Event Latency: Handling asyn-

chronous events (interrupts, exceptions) incurs

signiﬁcant overhead. This includes:

• The time and computational cost of encrypt-

ing and authenticating the entire execution state

(registers, IP, and key context) upon interrup-

tion.

• The overhead of pushing this context onto a se-

cure stack/save area.

• The latency of deriving the handler entry key.

• The cost of retrieving, decrypting, and authen-

ticating the saved context upon returning from

the handler.

• A necessary pipeline ﬂush and stall when inter-

rupting and resuming execution.

This overhead is incurred each time an interrupt or

exception is processed, adding latency that scales

with the amount of state that needs to be saved

and restored, impacting the responsiveness of the

system to frequent asynchronous events.

These constraints align our model closer to in-order

processors, trading performance for security. While

our analysis shows linear overhead (O(nk)), practi-

cal implementations should target security-sensitive

workloads where performance degradation is accept-

able relative to the threat model.

5.2 Fault Injection Simulations

The paper acknowledges the need for empirical val-

idation of fault detection capabilities. While the

Python proof-of-concept demonstrates functional cor-

rectness, additional simulations will be conducted to

evaluate fault resistance. For instance:

i) Fault Injection Simulation: We will model fault

injection attacks (e.g., glitches, instruction tam-

pering) to validate detection via HMAC veriﬁca-

tion and key chain integrity checks.

ii) Hardware Faults: Using RISC-V

VP+++ (Schl

agl et al., 2024a), we will sim-

ulate hardware-level faults (e.g., register/memory

corruption) to assess the system’s ability to detect

and halt execution under tampering. Results will

quantify detection rates for various fault models.

6 CONCLUSION

This paper has presented a novel secure execution en-

vironment that provides comprehensive protection for

program execution through a uniﬁed cryptographic

approach. The system employs authenticated encryp-

tion and a key chaining mechanism to ensure instruc-

tion conﬁdentiality, integrity, and correct execution

ordering across both linear code sequences and com-

plex control ﬂow structures like branches, jumps, and

function calls.

At the core of our design is a cryptographic bind-

ing between consecutive instructions that prevents re-

ordering and replay attacks while maintaining precise

control over execution order. The key chaining mech-

anism creates cryptographic dependencies between

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

244

instructions that enforce their intended sequence. For

control ﬂow operations, we introduced deterministic

key derivation methods that maintain security prop-

erties across branches and function boundaries while

supporting legitimate program behavior.

The system employs authenticated encryption and

a key chaining mechanism to ensure instruction con-

ﬁdentiality, integrity, and correct execution ordering

across both linear code sequences and complex con-

trol ﬂow structures like branches, jumps, function

calls, and asynchronous events like interrupts and ex-

ceptions.

At the core of our design is a cryptographic bind-

ing between consecutive instructions that prevents re-

ordering and replay attacks while maintaining precise

control over execution order. The key chaining mech-

anism creates cryptographic dependencies between

instructions that enforce their intended sequence. For

control ﬂow operations, we introduced deterministic

key derivation methods that maintain security prop-

erties across branches and function boundaries while

supporting legitimate program behavior, extending

this to securely manage state and keys across asyn-

chronous interruptions.

Our security analysis demonstrated the system’s

resistance to various attack vectors including instruc-

tion reordering, tampering, and control ﬂow hijack-

ing attempts. The performance analysis revealed that

while the system introduces computational overhead

from cryptographic operations, it scales linearly with

program size (O(nk) where n is the number of in-

structions and k is the security parameter), making

it practical for real-world applications. The success-

ful implementation of a proof-of-concept in Python

validated both the theoretical framework and its prac-

tical viability. In terms of future work, a natural

next step is to apply and evaluate the concepts pre-

sented in this paper on real-world architectures. A

suitable candidate is the relatively young RISC-V In-

struction Set Architecture (ISA) (Waterman et al.,

2011; Waterman et al., 2016), as it is an open stan-

dard. Efﬁcient design space exploration and eval-

uation can be achieved using simulation techniques

such as SystemC/TLM (IEEE 1666 (noa, 2023))

based virtual prototyping (De Schutter, 2014; Leu-

pers et al., 2012). The very capable open source

RISC-V VP++ (Schl

agl et al., 2024a; Schl

agl et al.,

2024b; Schl

agl and Große, 2025) is, being consid-

ered for this. A promising direction for future work

is exploring hybrid architectures where cryptographic

constraints apply selectively to security-critical code

regions (e.g., cryptographic routines or authentication

logic), while non-critical code executes on traditional

out-of-order pipelines. Such an approach could bal-

ance performance and security, leveraging hardware/-

software co-design to isolate sensitive computations

within cryptographically enforced boundaries.

ACKNOWLEDGMENTS

This work has partially been supported by the LIT Se-

cure and Correct Systems Lab funded by the State of

Upper Austria.We thank Dr. Zahra Seyedi for draw-

ing the ﬂowchart picture for this paper.

REFERENCES

(2023). IEEE Standard for Standard SystemC® Language

Reference Manual. IEEE Std 1666-2023 (Revision

of IEEE Std 1666-2011), pages 1–618. Conference

Name: IEEE Std 1666-2023 (Revision of IEEE Std

1666-2011).

Abadi, M., Budiu, M., Erlingsson, U., and Ligatti, J.

(2009). Control-ﬂow integrity principles, implemen-

tations, and applications. ACM Trans. Inf. Syst. Secur.,

13(1).

Blazy, S. and Trieu, A. (2016). Formal veriﬁcation of

control-ﬂow graph ﬂattening. In Proceedings of the

5th ACM SIGPLAN Conference on Certiﬁed Pro-

grams and Proofs, CPP 2016, pages 176–187, New

York, NY, USA. Association for Computing Machin-

ery.

Chamelot, T., Courouss

e, D., and Heydemann, K. (2022).

Sci-ﬁ: control signal, code, and control ﬂow integrity

against fault injection attacks. In Proceedings of the

2022 Conference & Exhibition on Design, Automation

& Test in Europe, DATE ’22, page 556–559, Leuven,

BEL. European Design and Automation Association.

Christou, G., Vasiliadis, G., Papaefstathiou, V., Papado-

giannakis, A., and Ioannidis, S. (2020). On Architec-

tural Support for Instruction Set Randomization. ACM

Trans. Archit. Code Optim., 17(4):36:1–36:26.

Costan, V. and Devadas, S. (2016). Intel SGX explained.

IACR Cryptol. ePrint Arch., page 86.

de Clercq, R., G

otzfried, J.,

Ubler, D., Maene, P., and Ver-

bauwhede, I. (2017). SOFIA: Software and control

ﬂow integrity architecture. Computers & Security,

68:16–35.

De Schutter, T. (2014). Better Software. Faster!: Best Prac-

tices in Virtual Prototyping. Synopsys Press.

Ege, B., Kavun, E. B., and Yalc¸ın, T. (2011). Memory En-

cryption for Smart Cards. In Smart Card Research

and Advanced Applications, pages 199–216, Berlin,

Heidelberg. Springer.

Gallagher, M., Biernacki, L., Chen, S., Aweke, Z. B., Yit-

barek, S. F., Aga, M. T., Harris, A., Xu, Z., Kasikci,

B., Bertacco, V., Malik, S., Tiwari, M., and Austin,

T. (2019). Morpheus: A Vulnerability-Tolerant Se-

cure Architecture Based on Ensembles of Moving

Target Defenses with Churn. In Proceedings of the

Control Flow Protection by Cryptographic Instruction Chaining

245

Twenty-Fourth International Conference on Architec-

tural Support for Programming Languages and Op-

erating Systems, ASPLOS ’19, pages 469–484, New

York, NY, USA. Association for Computing Machin-

ery.

Gruss, D., Spreitzer, R., and Mangard, S. (2015). Cache

template attacks: automating attacks on inclusive last-

level caches. In Proceedings of the 24th USENIX

Conference on Security Symposium, SEC’15, page

897–912, USA. USENIX Association.

Gueron, S. (2016). A memory encryption engine suitable

for general purpose processors. Cryptology ePrint

Archive, Paper 2016/204.

Harris, A., Verma, T., Wei, S., Biernacki, L., Kisil, A.,

Aga, M. T., Bertacco, V., Kasikci, B., Tiwari, M.,

and Austin, T. (2021). Morpheus II: A RISC-V Secu-

rity Extension for Protecting Vulnerable Software and

Hardware. In 2021 IEEE International Symposium on

Hardware Oriented Security and Trust (HOST), pages

226–238.

Henson, M. and Taylor, S. (2014). Memory encryption: A

survey of existing techniques. ACM Comput. Surv.,

46(4):53:1–53:26.

Kc, G. S., Keromytis, A. D., and Prevelakis, V. (2003).

Countering code-injection attacks with instruction-set

randomization. In Proceedings of the 10th ACM con-

ference on Computer and communications security,

CCS ’03, pages 272–280, New York, NY, USA. As-

sociation for Computing Machinery.

Kocher, P., Genkin, D., Gruss, D., Haas, W., Hamburg, M.,

Lipp, M., Mangard, S., Prescher, T., Schwarz, M., and

Yarom, Y. (2018). Spectre Attacks: Exploiting Spec-

ulative Execution. arXiv:1801.01203.

Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D., Haas,

W., Hamburg, M., Lipp, M., Mangard, S., Prescher,

T., Schwarz, M., and Yarom, Y. (2020). Spectre at-

tacks: exploiting speculative execution. Commun.

ACM, 63(7):93–101.

Leupers, R., Martin, G., Plyaskin, R., Herkersdorf, A.,

Schirrmeister, F., Kogel, T., and Vaupel, M. (2012).

Virtual platforms: Breaking new grounds. In Design,

Automation and Test in Europe, pages 685–690.

Liu, C., Wang, X. S., Nayak, K., Huang, Y., and Shi, E.

(2015). ObliVM: A Programming Framework for Se-

cure Computation. In 2015 IEEE Symposium on Secu-

rity and Privacy, pages 359–376. ISSN: 2375-1207.

Maas, M., Love, E., Stefanov, E., Tiwari, M., Shi, E.,

Asanovic, K., Kubiatowicz, J., and Song, D. (2013).

PHANTOM: Practical Oblivious Computation in a

Secure Processor. CCS ’13, pages 311–324. ACM.

Rass, S. and Schartner, P. (2016). On the Security of a Uni-

versal Cryptocomputer: the Chosen Instruction At-

tack. IEEE Access, 4:7874–7882. Conference Name:

IEEE Access.

Rass, S., Schartner, P., and Wamser, M. (2015). Oblivious

Lookup Tables. Tatra Mountains Mathematical Pub-

lications, 67.

Schl

agl, M. and Große, D. (2025). Fast interpreter-based

instruction set simulation for virtual prototypes. In

Design, Automation and Test in Europe Conference

(DATE).

Schl

agl, M., Hazott, C., and Große, D. (2024a). RISC-V

VP++: Next generation open-source virtual prototype.

In Workshop on Open-Source Design Automation.

Schl

agl, M., Stockinger, M., and Große, D. (2024b). A

RISC-V “V” VP: Unlocking Vector Processing for

Evaluation at the System Level. In Design, Automa-

tion and Test in Europe Conference (DATE), pages 1–

Shacham, H. (2007). The geometry of innocent ﬂesh on

the bone: return-into-libc without function calls (on

the x86). In Proceedings of the 14th ACM conference

on Computer and communications security, CCS ’07,

pages 552–561, New York, NY, USA. Association for

Computing Machinery.

Stecklina, O., Langend

orfer, P., Vater, F., Kranz, T., and

Leander, G. (2015). Intrinsic Code Attestation by In-

struction Chaining for Embedded Devices. In Security

and Privacy in Communication Networks, pages 97–

115, Cham. Springer International Publishing.

Tice, C., Roeder, T., Collingbourne, P., Checkoway, S., Er-

lingsson,

U., Lozano, L., and Pike, G. (2014). En-

forcing Forward-Edge Control-Flow integrity in GCC

& LLVM. In 23rd USENIX Security Symposium

(USENIX Security 14), pages 941–955, San Diego,

CA. USENIX Association.

Tsoutsos, N. G. and Maniatakos, M. (2014). HEROIC:

Homomorphically EncRypted One Instruction Com-

puter. In 2014 Design, Automation & Test in Europe

Conference & Exhibition (DATE), pages 1–6. ISSN:

1558-1101.

Wang, X., Chen, H., Jia, Z., Zeldovich, N., and Kaashoek,

M. F. (2012). Improving integer security for systems

with KINT. In 10th USENIX Symposium on Operat-

ing Systems Design and Implementation (OSDI 12),

pages 163–177, Hollywood, CA. USENIX Associa-

tion.

Waterman, A., Lee, Y., Avizienis, R., Patterson, D. A., and

Asanovic, K. (2016). The risc-v instruction set manual

volume ii: Privileged architecture version 1.7. EECS

Department, University of California, Berkeley, Tech.

Rep. UCB/EECS-2016-129.

Waterman, A., Lee, Y., Patterson, D. A., and Asanovic, K.

(2011). The risc-v instruction set manual, volume i:

Base user-level isa. eecs department. University of

California.

Werner, M., Unterluggauer, T., Schaffenrath, D., and Man-

gard, S. (2018). Sponge-Based Control-Flow Protec-

tion for IoT Devices: 2018 IEEE European Sympo-

sium on Security and Privacy. 2018 IEEE European

Symposium on Security and Privacy. Publisher: IEEE.

Zahur, S. and Evans, D. (2015). Obliv-c: A language for

extensible data-oblivious computation. Cryptology

ePrint Archive, Paper 2015/1153.

Zahur, S., Rosulek, M., and Evans, D. (2015). Two Halves

Make a Whole. In Advances in Cryptology - EU-

ROCRYPT 2015, pages 220–250, Berlin, Heidelberg.

Springer.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

246