iVaul : A chi ec u al Code Concealing Techniques
o P o ec C yp og aphic Keys
Geo ge Ch is ou1, Gio gos Vasiliadis2,3, Apos olis Za as3,4, and So i is
Ioannidis1,3
1Technical Uni e si y o C e e, Chania, G eece
2Depa men o Managemen Science and Technology, Hellenic Medi e anean
Uni e si y, Agios Nikolaos, G eece
3Founda ion o Resea ch and Technology – Hellas, He aklion, G eece
4Uni e si y o Pi aeus, Pi aeus, G eece
Abs ac . Memo y co up ion bugs emain a signi ican conce n in ap-
plica ions de eloped using memo y-unsa e languages, such as C/C++.
Ad e sa ies can exploi hese bugs and pe o m a bi a y ead and w i e
ope a ions. These a bi a y eads can a ge c yp og aphic keys, se e ely
comp omising hei secu e ope a ion. In his pape , we in oduce iVaul
a ligh weigh app oach o secu ely s o e p i a e and sec e c yp og aphic
keys. iVaul encodes c yp og aphic keys wi hin he machine ins uc ion
immedia es and le e age a chi ec u al mechanisms o p o ec he . ex
segmen om being disclosed. We assess iVaul in e ms o pe o mance
and code size expansion, and we show ha i ep esen s a iable solu ion
o sa egua ding c yp og aphic keys.
Keywo ds: Ha dwa e Assis ed Secu i y ·Key Managemen
1 In oduc ion
Mode n c yp og aphy is ypically used o p o ec sensi i e o p i a e da a om
being in e cep ed and/o leaked when ans e ed o e he ne wo k o s o ed in
memo y. The adop ion o c yp og aphic ha dwa e ex ensions wi hin commod-
i y CPUs has educed he o e heads imposed om c yp og aphic ope a ions on
da a, making c yp og aphy mains eam and widely used in di e se se o ap-
plica ions [16,22]. Besides pe o mance, c yp og aphy is only e ec i e in e ms
o secu i y, as long as he c yp og aphic keys a e adequa ely p o ec ed [15]. In
ac , he p ocess o secu ely s o ing and managing c yp og aphic keys used o
enc yp ion and dec yp ion, known as key managemen , o ms he basis o he
end- o-end secu i y o a sys em.
Key managemen is o en conside ed qui e challenging hough, especially in
cases whe e he keys mus be accessed equen ly, such as eal- ime p ocessing o
s eaming applica ions. This is u he exace ba ed by he ac ha he majo i y
o c yp o lib a ies a e w i en in low-le el languages, such as C/C++, mainly
o access he a chi ec u al ex ensions a ailable in mode n CPUs o accele a ing
2 Geo ge Ch is ou, Gio gos Vasiliadis, Apos olis Za as, and So i is Ioannidis
c yp og aphy. Un o una ely, hese low-le el languages a e no memo y sa e, and
hus, memo y co up ion bugs can allow a acke s o manipula e he memo y
con en s and access sensi i e in o ma ion, such as sec e o p i a e c yp og aphic
keys. One such example is he Hea bleed bug ha allowed bu e o e - eads
due o imp ope inpu alida ion [14]. This bug can be exploi ed o disclose he
c yp og aphic keys om he main memo y and has a ec ed an eno mous amoun
o compu ing sys ems and use s, due o he popula i y o he a ec ed lib a y [8].
To ackle his p oblem, se e al academic wo ks ha e been p oposed o de-
ine sa e egions o s o ing sensi i e da a [23,24]. These wo ks mos ly ocus on
in a-p ocess isola ion, since adi ional ope a ing sys ems o e s ong isola ion
gua an ees be ween p ocesses. Among hese, he deploymen o memo y sa e y
mechanisms o he C and C++ p og amming languages can es ic memo y
accesses and elimina e memo y co up ion ulne abili ies. Howe e , hese mech-
anisms lack p ac icali y due o high pe o mance o e head. O he app oaches
u ilize ha dwa e-based T us ed Execu ion En i onmen s (TEEs), such as In el
SGX [17], AMD SEV [1], o ARM T us Zone [2]. These TEEs p o ide secu e and
isola ed en i onmen s whe e he code and he keys can eside, p e en ing unau-
ho ized access o ampe ing om any ou side en i y. S ill, cu en ha dwa e-
based TEEs do no gua an ee he memo y sa e y o code ha has been de el-
oped wi h memo y unsa e languages such as C and C++. As a consequence,
p og ams unning inside TEEs ace he same memo y co up ion ulne abili ies
as adi ional so wa e, allowing a acke s o iola e hei con iden iali y.
In his wo k, we p opose iVaul , a ligh weigh app oach o secu ely s o e p i-
a e and sec e c yp og aphic keys as immedia es in machine code. The machine
code is hen p o ec ed using ha dwa e-assis ed echniques ha a e able o hide
he . ex segmen o bina ies. By doing so, he encoded keys a e su icien ly
p o ec ed in case o memo y co up ion ulne abili ies ha allow an a acke
o disclose a bi a y memo y egions. iVaul implemen s a ep esen a i e se o
popula c yp og aphic algo i hms, in which he c yp og aphic keys a e encoded
as immedia es in he co esponding machine code. iVaul also p o ides a se o
API unc ions ha allow o easily encode he c yp og aphic keys on demand.
We implemen iVaul in wo di e en a chi ec u es: SPARC and x86. Fo
SPARC, we employ a modi ied Leon3 p ocesso ha is equipped wi h Ins uc ion
Se Randomiza ion. In he case o he x86, we ake ad an age o In el Memo y
P o ec ion Keys (MPKs), a ea u e a ailable on ecen In el p ocesso models.
Ou e alua ion shows ha iVaul can e ec i ely p e en he exploi a ion o
memo y disclosu e bugs ha a ge c yp og aphic keys, wi h an a e age o e -
head o 0.36% in x86 and 8.93% in SPARC.
2 Backg ound
In his sec ion we b ie ly desc ibe he wo a chi ec u al ea u es ha we u ilize o
he implemen a ion o iVaul in ega ds o he p o ec ion o he . ex segmen :
Ins uc ion Se Randomiza ion and Memo y P o ec ion Keys.
Ti le Supp essed Due o Excessi e Leng h 3
2.1 Ins uc ion Se Randomiza ion
Ins uc ion Se Randomiza ion (ISR) aims o o i y applica ions agains code
injec ion a acks [20]. I s undamen al concep in ol es he andomiza ion o he
ins uc ion se o each p ocess h ough enc yp ion. Thus, any injec ed code will
likely ail o execu e, as dec yp ion akes place be o e en e ing in o he p oces-
so ’s ins uc ion cache, po en ially esul ing in in alid code. O iginally, ISR was
no concei ed o de end agains Code Reuse A acks (CRAs) such as Re u n
O ien ed P og amming (ROP) [25] and Jump O ien ed P og amming (JOP) [6].
Howe e , ISR schemes wi h s ong enc yp ion can hwa CRAs by obs uc ing
he disclosu e o use ul gadge s. In ISR, he . ex segmen is enc yp ed, causing
da a accesses on his sec ion o e u n enc yp ed by es. In iVaul , we le e age
ASIST [10], a modi ied Leon3 p ocesso [13], which p o ides h ee dis inc en-
c yp ion modes o ISR: XOR, T ansposi ion, and AES. In iVaul we op o
he AES a ian due o i s abili y o also de end agains CRAs and i s esilience
agains c yp og aphic a acks such as known-plain ex -ciphe ex .
O e all, iVaul elies on he capabili y o ISR o p e en he disclosu e o
he . ex segmen , he eby enabling us o conceal c yp og aphic keys. Conse-
quen ly, any a bi a y memo y ead a emp will ail o un eil his in o ma ion
o po en ial a acke s.
2.2 Memo y P o ec ion Keys
Memo y P o ec ion Keys (MPK) is a mechanism in oduced ecen ly in In el p o-
cesso s [18]. I allows use -space applica ions o di ec ly modi y he access igh s
on g oups o memo y pages. Each g oup o pages is associa ed wi h a unique
key, wi h applica ions capable o managing up o 16 page g oups. The access
igh s o each page g oup a e delinea ed in a h ead-local and use -accessible
egis e known as he P o ec ion Keys Righ s Regis e ( o use s), deno ed as
%pk u. Gi en ha he %pk u egis e is speci ic o each h ead, MPK acili a es
a pe - h ead pe spec i e o he p ocess’s memo y. Fo ins ance, dis inc applica-
ion h eads possess di e en access igh s con igu ed o each key wi hin hei
espec i e %pk u egis e .
I a memo y page is ma ked as execu able in he page able bu con igu ed
wi h no access in he %pk u egis e , he memo y page is ea ed as execu e-
only. This occu s since any a emp a da a access will lead o a misma ch
be ween he igh s speci ied in he page able and hose in he %pk u egis e .
Linux le e ages MPK o suppo execu e-only memo y pages. In oking mp o ec
wi h only PROT_EXEC speci ied as pe missions will esul in he alloca ion o a
p o ec ion key associa ed wi h he memo y pages passed o mp o ec . Subse-
quen ly, he %pk u egis e will be se o DISABLE_ACCESS o he newly alloca ed
p o ec ion key, while he page able igh s will be con igu ed as execu able and
eadable. Any a emp o access execu e-only pages, excep o ins uc ion e ch-
ing, will igge a memo y iola ion excep ion.
In iVaul , we le e age execu e-only memo y o achie e simila p ope ies as
wi h ISR. By p e en ing ead access on he . ex segmen , he embedded keys
will no be disclosed due o memo y co up ion bugs.
4 Geo ge Ch is ou, Gio gos Vasiliadis, Apos olis Za as, and So i is Ioannidis
C yp og aphic
empla e
Un olled C yp og aphic
empla e
Execu e
only bina y
Sou ce Code Bina y
x86
gcc
ISR
bina y
SPARC
gcc
Applica ion
code
Fig. 1: iVaul empla e inclusion in applica ions.
3 Th ea model
Ou h ea model assumes ad e sa ies can exploi memo y and ype unsa e y
in applica ions ha u ilize c yp og aphy. Consequen ly, an a acke can exploi
memo y co up ion ulne abili ies o enable a bi a y memo y ead capabili ies.
These ulne abili ies can lead o unau ho ized access o sensi i e da a. Finally,
we conside side-channel a acks and ha dwa e aul s as ou o scope.
To secu e keys s o ed in he . ex segmen , speci ic OS and ha dwa e ea-
u es a e necessa y. We p esume he W∧X policy is en o ced, and he applica ion
excludes sel -modi ying code. Ou c yp og aphic implemen a ions a e designed
o coexis wi h o he secu i y mechanisms, such as AppA mo and RELRO,
which can u he enhance applica ion p o ec ion. The ha dwa e mus include
Memo y P o ec ion Keys o a unc ionally equi alen mechanism. Fo ou Leon3
implemen a ion, we employ ISR. Al hough ou equi ed ha dwa e ea u e is no
as s anda d as ou OS p e equisi es, i is included in he la es In el se e CPU
se ies. Addi ionally, he MPK unc ionali y can be emula ed h ough memo y
agging, which is a ailable in ARM’s la es p ocesso se ies [4].
4 Design
We ou line he design o iVaul and he c yp og aphic sui e ha implemen s.
Fo each c yp og aphic algo i hm, iVaul uses empla es ha can be employed
o encode he keys as immedia e ope ands a a ious s ages o he applica ion’s
li e-cycle, such as pos -compila ion, p og am ini ializa ion, o p og am execu ion.
4.1 Sou ce code ans o ma ions
To co ec ly embed he keys o each c yp og aphic algo i hm, i is essen ial o
ensu e ha e e y c yp og aphic ope a ion is implemen ed as a block o ins uc-
ions wi h only one en y and exi poin , namely basic block. This is equi ed
because, o he wise, i would be imp ac ical o modi y he ins uc ion immedia es
a un ime, on e e y i e a ion o an enc yp ion algo i hm (e.g., AES equi es 10
loops). To un oll he loops, we se ialize and ans o m each ound o he block
ciphe s implemen ed in iVaul as shown in Figu e 1, ensu ing ha all da a
ope a ions a e execu ed wi hou any b anch p esen .
Ti le Supp essed Due o Excessi e Leng h 5
4.2 C yp og aphic key se
The c yp og aphic keys a e se a a ious s ages o an applica ion’s li e cycle.
Ini ially, he immedia es o he key ins uc ions a e se o dummy alues. Each
c yp og aphic unc ion is analyzed o p oduce a map o he key by e loca ions.
The eal key is embedded by i e a ing h ough he map ha loca es key pa
posi ions wi hin he bina y. A his s age, ins uc ions ha ca y key pa s a e
pa ched o inco po a e he key used du ing he applica ion’s execu ion. Nex , he
key can be modi ied du ing he applica ion’s un ime, a unc ionali y ha a ies
wi h he a chi ec u e in which iVaul is implemen ed. Fo he x86 a chi ec u e,
he unc ion included in he c yp og aphic lib a y modi ies he key pa s a
un ime, u ilizing he key map. In con as , in ou ISR-based implemen a ion,
whe e he . ex a ea is enc yp ed, and he ISR key is s o ed in he ke nel p ocess
able; we depend on he ISR-awa e ope a ing sys em o co ec ly enc yp he
ew i en c yp og aphic unc ions— hose pa ched wi h he new enc yp ion key.
As we show in Sec ion 6, encoding he c yp og aphic keys in he ins uc ions
immedia es educes he memo y accesses equi ed du ing each c yp og aphic
ope a ion.
5 Implemen a ion
We now desc ibe he implemen a ion de ails o iVaul o symme ic and asym-
me ic key c yp og aphy, espec i ely.
5.1 Symme ic c yp og aphy
We implemen wo block ciphe s o e alua e he design o iVaul : XTEA and
AES. XTEA is a block ciphe enc yp ion algo i hm ha ope a es on 64-bi da a
blocks using a 128-bi key and employs a Feis el ne wo k s uc u e [28]. This
in ol es spli ing he inpu da a in o wo hal es, pe o ming a se ies o ope a ions
on each, and hen me ging he ou comes. The key gene a es mul iple ound keys
ha al e he da a du ing each Feis el cycle, wi h a ypical con igu a ion o 64
ounds, enhancing i s secu i y. Due o i s simplici y, speed, and compac code
size, XTEA is equen ly chosen o embedded sys ems. We un oll he algo i hm
loops o he c yp og aphic key embedding and eplace key a ay accesses wi h
dummy cons an alues. We hen compile his modi ied code in o a bina y ha
embeds hese dummy pa s as immedia es in he machine ins uc ions. Now, a
sc ip associa es each key pa wi h he co esponding ins uc ion and pa ches
he bina y wi h he eal key.
We also implemen AES algo i hm in ECB mode, in which he inpu da a
is pa i ioned in o ixed-size blocks (128 bi s o AES), ha a e enc yp ed sepa-
a ely using he same key. This di ec enc yp ion p ocess equi es no ex a da a
o compu a ions beyond he key and he inpu da a. Iden ical plain ex blocks
will consis en ly yield he same ciphe ex blocks. Ou app oach o implemen
ECB is simila o XTEA: we un oll all ounds, use cons an alues as a dummy
key, and la e pa ch he ac ual key o be used in he a ge ed bina y.
6 Geo ge Ch is ou, Gio gos Vasiliadis, Apos olis Za as, and So i is Ioannidis
5.2 Asymme ic c yp og aphy
In iVaul , we inco po a e he 256-bi Ellip ic Cu e Digi al Signa u e Algo i hm
(ECDSA) [19], which is a digi al signa u e algo i hm ha le e ages ellip ic cu e
c yp og aphy (ECC). ECDSA is widely used o e i y he au hen ici y, in eg i y,
and non- epudia ion o digi al messages and ansac ions. The ECDSA p ocess
in ol es a pai o public and p i a e keys; he p i a e key gene a es digi al sig-
na u es, whe eas he public key is used o hei e i ica ion.
The algo i hm ini ia es by c ea ing a andom numbe , known as a nonce,
o de e mine a poin on an ellip ic cu e. This poin is hen used o calcula e
he signa u e, comp ising a pai o in ege s: he x-coo dina e and a alue de-
i ed om he nonce and he ellip ic cu e poin . Fo signa u e e i ica ion, he
ecei e employs he sende ’s public key o compu e he co esponding ellip ic
cu e poin and e i ies i s cong uence wi h he poin in ol ed in he signa u e
c ea ion. The ecei e hen alida es he signa u e using he same ma hema ical
p ocedu es o iginally used o gene a e i . In iVaul , we ha e implemen ed he
sign unc ion, he sole unc ion ha employs he p i a e key. A no able dis inc-
ion om he block ciphe s we ha e de eloped is ha ECDSA u ilizes a la ge
in ege o he key a he han a by e a ay.
5.3 A chi ec u al speci ic implemen a ions
We implemen iVaul on wo di e en a chi ec u es: x86 and SPARC. A no able
dis inc ion in ou app oach is ha ou x86 p ocesso ope a es on a 64-bi a chi-
ec u e, whe eas ou SPARC p ocesso is a 32-bi . This a chi ec u al di e ence
does no a ec ou block ciphe s; howe e , o ECDSA, he key di ision in ol es
ou ins uc ions on he x86 a chi ec u e and eigh on he SPARC a chi ec u e.
We also employ di e en a chi ec u al ex ensions speci ic o each a chi ec u e
o enhance secu i y. Fo he x86 implemen a ion, we use MPK o designa e he
page con aining he c yp og aphic unc ions as execu e-only. Con e sely, we use
ISR o he SPARC implemen a ion o enc yp he en i e . ex segmen o he
applica ion ha employs he iVaul c yp og aphic sui e. A no able di e ence is
ha in ou ISR implemen a ion, he whole . ex segmen is p o ec ed, whe eas,
in x86, only he pages con aining he c yp og aphic ope a ions a e con igu ed as
execu e only. Thus, in ou x86 implemen a ion, we ha e o page-align he i s
sensi i e unc ion and he i s non-sensi i e unc ion o a oid he co-exis ence
o c yp og aphic unc ions wi h no mal ones on he same page.
5.4 Changing enc yp ion keys
In each o ou implemen a ions, we ha e de eloped unc ions ha enable he
c yp og aphic key o be changed a un ime. Fo he x86 a chi ec u e, his unc-
ion employs mp o ec o ma k he page con aining he c yp og aphic unc ion
as w i able. Then, he new key is pa ched in o he immedia es o he ins uc ions
using he map we p oduced du ing he ini ial s ages o he implemen a ion. This
Ti le Supp essed Due o Excessi e Leng h 7
map includes he add ess o se o key pa s in he c yp og aphic unc ions, cal-
cula ing he ue add ess by adding he unc ion’s base load add ess o he o se
in he map. A e pa ching he new key, he key change unc ion uses mp o ec
again o se he access igh s o execu e only.
In ou ISR implemen a ion, di ec modi ica ion o he c yp og aphic unc-
ions’ code is no easible, as i is enc yp ed, and he key esides solely in ke nel
space. The e o e, we i s use mp o ec o make he pages con aining he c yp o-
g aphic unc ions w i able and hen comple ely o e w i e hem wi h a new unc-
ion embedded wi h he new c yp og aphic key. We hen use he asis _enc yp
sys em call o enc yp he new unc ion wi h he p ocess’s ISR key. Finally, we
call mp o ec once mo e o se he access igh s o execu able.
6 E alua ion
We e alua e iVaul in e ms o secu i y and in e ms o pe o mance. To achie e
his, we use a se o popula c yp og aphic algo i hms bo h in s andalone se ups
and eal-wo ld scena ios. Ou aim is o answe he ollowing e alua ion ques ions:
EQ1: Can iVaul p o ec c yp og aphic keys agains memo y disclosu e?
EQ2: Wha is he impac o iVaul on he bina y code size?
EQ3: Wha is he impac o iVaul on he un ime pe o mance?
6.1 Secu i y analysis (EQ1)
We assess he esilience o iVaul by delinea ing a acks con o ming o ou
h ea model, desc ibed in Sec ion 3. We also implemen syn he ic a ack sce-
na ios o showcase how iVaul p e en s he ex ac ion o c yp og aphic keys
om an applica ion.
A bi a y memo y eads. In iVaul , he c yp og aphic keys eside only
wi hin he . ex a ea o an applica ion, which is su icien ly isola ed in bo h
implemen a ions (i.e., x86 and SPARC). On x86 a chi ec u es, accesses o he
. ex segmen a e p ohibi ed because i is con igu ed wi h execu e-only pe -
missions. Simila ly, in ou cus omized SPARC V8 p ocesso , he . ex segmen
is enc yp ed. Consequen ly, any a emp s a a bi a y ead p imi i es, such as
bu e o e - eads and use-a e - ee, will ail o disclose he c yp og aphic keys.
Ex ac ing in e media e s a es. In iVaul , each c yp og aphic algo i hm is
ealized as a basic block, implemen ed as a code block wi hou any b anches.
Du ing e e y c yp og aphic ope a ion, he unc ion execu es independen ly o
any o he a iables in he applica ion. A he epilogue o each unc ion, we en-
su e ha any in e media e s a es gene a ed du ing he c yp og aphic ope a ion
a e nulli ied and, he e o e, canno be e ie ed (e.g., h ough a bi a y eads
accessible om o he code blocks).
Code euse a acks. A majo class o exploi a ion echniques ha a ge mem-
o y ulne abili ies is code euse a acks. In his scena io, he a acke exploi s
8 Geo ge Ch is ou, Gio gos Vasiliadis, Apos olis Za as, and So i is Ioannidis
Table 1: The code size g ow h (in
by es) o iVaul in he execu e-only
memo y e sion (x86).
Bench Vanilla iVaul O e head
XTEA 1205 16981 1309.21%
AES 6789 13189 94.27 %
ECC 30581 34677 13.39 %
SQLi e 868564 881412 1.48 %
Table 2: The code size g ow h (in
by es) o iVaul in he Ins uc ion Se
Randomiza ion e sion (SPARC).
Bench Vanilla iVaul O e head
XTEA 29496 44428 50.62%
AES 49852 56624 13.58 %
ECC 87780 94312 7.44 %
SQLi e 1207720 1221992 1.18 %
a bi a y memo y w i es o o e w i e con ol- low a iables. S ill, an a acke
migh use he iVaul ’s API o al e he c yp og aphic keys. None heless, his
ac ion would no disclose any da a enc yp ed wi h p e ious keys. Fo code euse
a acks o succeed, he a acke mus know in ad ance he loca ion o he code
snippe s necessa y o implemen he payload. Howe e , he . ex segmen s o
iVaul a e un eadable, ende ing he a acke unawa e o he loca ion o use-
ul code. The idea o emo ing ead access om he code segmen has been
s udied [3]. Ad anced code euse a ack echniques ha e demons a ed ha ap-
plica ions can s ill be exploi ed e en wi hou knowledge o he layou o he
. ex segmen [5]. Howe e , concealing he code segmen signi ican ly aises he
ba o a success ul code euse a ack.
Take Away: iVaul can e ec i ely p o ec c yp og aphic keys in applica ions
agains a bi a y eads.
6.2 O e head on he code size (EQ2)
As we men ion in Sec ion 4.1, iVaul un olls each and e e y loop con ained in he
a ge ed c yp og aphic algo i hm in o de o ha e only a la ge basic block ha
con ains all he ins uc ions ha will enc yp o dec yp a block o da a. This
ine i ably expands he . ex segmen size o he inal bina y, which we measu e
by compa ing he o iginal e sions o he algo i hms u ilized o p o o yping
iVaul wi h he modi ied bina ies. As depic ed in Table 1, he g ow h o he
. ex segmen in ou execu e-only memo y implemen a ion su passes ha o
ou ISR implemen a ion. This dispa i y s ems om MPKs ope a ing on a pe -
page g anula i y. Thus, we page-aligned he i s sensi i e unc ion and he i s
subsequen non-sensi i e unc ion o he bina y. In he case o XTEA algo i hm,
his inc eases . ex by hal a page (app oxima ely). One could a gue ha he
execu e-only memo y could be applied o he whole . ex segmen in o de o
educe g ow h. Howe e , his is no always possible since compile s may emi
da a (e.g., jump ables) in he . ex segmen .
We no e ha he ISR implemen a ion does no equi e page-aligning sensi-
i e unc ions, since he whole applica ion is p o ec ed. To p o ec bina ies, we
compile hem s a ically and wi hou jump ables and s ic aliasing (emi da a
Ti le Supp essed Due o Excessi e Leng h 9
o he . ex segmen ). We also use he same compila ion lags o bo h anilla
and iVaul bina ies in o de o ga he consis en measu emen s o code size
g ow h and un ime pe o mance. As we obse e in Table 2, he pe cen age o
he code added is lowe since he bina ies a e s a ically linked and a e amo ized
in bo h cases when he implemen a ions a e included in la ge code bases (i.e.
in ECC and SQLi e).
Take Away: iVaul code size o e head is no p ohibi i e in applica ions wi h
la ge code base.
6.3 Run ime pe o mance e alua ion (EQ3)
To assess he un ime pe o mance o iVaul , we un benchma ks on popula
c yp og aphic algo i hms and eal applica ion scena ios. The s andalone execu-
ion o c yp og aphic ope a ions can pinpoin he pe o mance impac o ou
modi ica ions, while la ge applica ions p o ide us mo e insigh s wi h ega ds o
he eal-wo ld expec ed impac .
Se up. We e alua e iVaul on x86 and SPARC V8 a chi ec u es. Ou x86 sys-
em ea u es an In el Co e i9-10900 CPU wi h 32GB RAM and uns Linux e -
sion 5.4.0-84. To ensu e consis en measu emen s, we disable equency scaling
and u bo boos . Fo e alua ing iVaul on he ISR-enabled SPARC V8 p oces-
so , we u ilize a Leon3 p ocesso con igu ed wi h a 64-KB (4-way associa i e)
ins uc ion cache. The cache ope a es wi h a single le el and ollows a pu e Ha -
a d a chi ec u e. We syn hesize and map he ISR-enabled Leon3 p ocesso on o
a Xilinx XUPV5 ML509 FPGA boa d wi h 256 MB DDR2 SDRAM memo y,
ope a ed a 80-MHz co e clock equency. Ou measu emen s include he o e -
head imposed by he ISR, as we un he anilla esul s on a non-ISR Leon3 wi h
iden ical con igu a ion ( equency, RAM).
Algo i hms and applica ions. We i s e alua e iVaul by execu ing s an-
dalone c yp og aphic unc ions o indi idual algo i hms. We measu e he execu-
ion ime o iVaul by execu ing 1M c yp og aphic ope a ions (enc yp ion and
dec yp ion) o XTEA and AES and 1K ECDSA ope a ions. We hen modi y
SQLi e and Mbed TLS o alida e ou app oach in eal-wo ld scena ios u he .
Ou modi ied SQLi e u ilizes AES o p o ide ully enc yp ed da abases, while in
Mbed TLS, we al e he ECDSA signing and e i ica ion unc ions. Fo SQLi e,
we un he de aul benchma k alues in x86 (100K en ies), while in Leon3, we
con igu ed he benchma k o ope a e on 100 en ies due o he sys em’s limi ed
capabili ies.
Ou indings sugges ha iVaul is a p ac ical secu i y s a egy. In x86
(Figu e 2a), he un ime pe o mance anges be ween -3.8% o 2% and is a ec ed
nega i ely by he code size g ow h and educed cache locali y (due o page-
alignmen ) and posi i ely by he educed numbe o memo y ope a ions equi ed
o each c yp og aphic ope a ions. This is especially p e alen in ou SPARC
implemen a ion (Figu e 2b), whe e he educed amoun o memo y ope a ions
