hi I'm Jonas from the guards University
of Technology and I will now tell you
how we can even further improve computer
security against rohama and because this
question will probably be asked yes you
can combine csro Hammer with rhaegar for
perfect security I would say because you
already heard a lot of the background of
brohammer I will jump right into it with
the problem with roheimer
countermeasures
many previous throw him accounting
measures focus on characteristics of
rohama that later turn out to be
incomplete I have a few examples for
example that urham isn't that bad and
bid Clips are infrequent so we can just
increase the refresh rate or use ECC RAM
and then it's fine that's certainly not
true
or that we can detect rohe Hammer with
performance counters there were
mitigations built with that
characteristic but that's sadly not true
as well
another one we already talked about the
blast diameter it was long thought that
the Blaster meter is one and a lot of
mitigations are based on that
but last year
I'll show that this is not true as well
so what do we actually need
CSR rohama
a generic approach to data Integrity
protection
what do we mean by that we mean that
we have CS arohama we are able to detect
all data interrogative failures with a
cryptographic map so we don't care where
bit flips come from it could be rohama
it can also be cosmic rays or something
entirely new we don't even know yet that
it exists but we'll be there in a few
years who knows
together with this detection of all bit
flips we have a best effort correction
and with this we can
mitigate all Rohan attacks in the worst
case to denial of service so in almost
all cases rohama is completely fixed in
the worst case it's the nylon service no
privilege escalation or stuff like that
how do we do that
you have the dram this is where rohama
happens
and here we have the CPU with the memory
controller
and on every read and write to the dram
the memory controller computes a
cryptographic Mac of the data
and then stores it
an additional chip of ECC drum so we use
ECC dram for that like in every server
at the moment
on this additional chip of the ECC
theorem we store the Integrity
information
and then on each reads we compute the
Mac of the data again compare it with
the stored Mac and we know if the data
changed or not
if the Mac is not equal we can correct a
single bit flip in Hardware
and if there are more bit flips we
delegate the correction to the operating
system
through a new exception
the operating system has an exception
Handler and in there you can do two
things first it can do a correction as a
search which is a simple brute for
search which sounds bad now but is
actually quite performant
or another big advantage of a software
correction is
oh no the corrections research uses a
new CPU instruction to compute the Mac
of the data so we do this completely in
Hardware with a key that's not known to
the software
but another thing that the software can
do
it can do Advanced correction because it
has knowledge about the data that is
corrupted for example data that is disk
backed we can just reload it from the
disk we don't have to do any correction
the last thing that's there is that the
whole operating system is in the dram so
an attacker could Hammer the exception
Handler
and break the system
to prevent that we add a secure memory
into the CPU it's only four pages large
so tiny compared to the caches of modern
CPUs so area overhead is not a problem
and we put the exception Handler in the
secure memory in the CPU this is the
whole design
let's look at it in a bit more detail on
every read and every right we compute
the Mac so this has to be as quickly as
possible fix this for this we use a p
Mac Construction using the karma block
Cipher that's also used by RM for
brighter Authentication
and we use the physical address as a tag
to have different Max for the same data
at different locations and with this
design we can compute the Mac of 556 bit
data in only 5.30 nanoseconds and for
512 bit data in 6.6 nanoseconds which is
small compared to the 100 nanoseconds it
approximately takes to access the dram
let's look at the data correction Max
cannot correct bit flips that's part of
the design
so what we have to do is
you need a boot for search with
approximate equality
the Mac is stored in a dram which means
that the Mac can also be hammered with
row hammer and single bits in the
magical change
to prevent that
or not not to prevent it but to be able
to handle that
on the Mac compare we don't expect the
Mac to be exactly equal approximately
equal is fine so here you can see the
Mac is computed we get also the maximum
drum one bit is different that's fine
for us I will talk about this in the
security evaluation
clip okay
um
and we have parity pistol shrink to
search space
this is our correction time we need
to correct bit flips with output for
search we can see for a single bit flip
which we do in Hardware we're in the
range of a few nanoseconds
you can also see how long it takes for
ECC theorem to correct bit flips there's
a huge range that we took from different
papers that looked at ECC
and then for the software correction we
first have an overhead of the exception
Handler and then the correction time
increases exponentially but we can still
correct by five bit flips in under
seconds and 8 bit flips in an almost
reasonable time of a few hours if the
data is really important
I could be fine
but we also have advanced error
correction in many cases we don't have
to do Brute Force search
because the operating system has
knowledge about the corrupted data so it
could just reload disk back data or
recommute data for example if page
tables are flipped which is a really
common exploit Target for Rohana
exploits and then we don't need any root
for search and the overhead is really
small
okay we also evaluated CSR hammer and
for this we used champ5
to implement the Mac computation the
comparison
in hardware and we modify the Linux
kernel to have the exception Handler and
perform the advanced correction
everything in software
we use this first to evaluate the
correct functionality so we induced bit
flips in the dram of our Channel 5 model
and the Mac was able to detect the
failure and then correct everything
and he also used it to evaluate the
performance overheads because we have
this Mac computation on every read and
every right
this is the performance overhead we get
for the parsec and splash2x benchmarks
and the geometric mean is less than one
percent
and
the highest overhead is
a bit over four percent for ddr4 memory
where we have a 6.6 nanoseconds delay
and a bit of three percent for Theta 5
memory where we have a small smaller
delay because you have less data and
this is quite a nice result because if
we look at the approximately 100
nanoseconds it takes to access the dram
and around five nanoseconds it takes to
compute the mac and we have this very
memory bound Benchmark ocean CP we can
see that the performance overhead is
around five percent there
so that's the maximum we can get for a
really memory bounce application
we also evaluated the security
and especially the approximate equality
because this is
it sounds kind of fishy at first to not
require all bits in the Mac to be the
same but we looked at that in detail so
we need this again because raw Hammer
can also induce split flips into the Mac
and the approximate equality decreases
the Mac strength from the initial 56 bit
we have
and we computed this table for example
if we have five data bit flips and we do
the Brute Force correction as a search
we need 2 to the power of 26 attempts
while brute forcing for the correct data
and if ignore three bits in the Mac
the max strength decreases from 56 bits
to 41.2 bits but this 41.2 bits is still
a lot higher than 26. so we are still
safe
and the same is true for higher bit uh
pitfully High number of bit flips in the
data if you just ignore less bit flips
in the Mac
we are always safe and for less data bit
flips than 5 which is the most common
you have a single or two or three bit
flips in the worst case
we don't allow more than three bit Clips
in the mac and in this very common
uh
case of a few bit flips in the data we
are really strong
we computed the strength and the silent
data corruption rates so of a system
that's not under attack is that we have
one
not detected bit flip in less
than 10 to the power of 9 billion years
so that's not of any concern
and if you have a system that's really
under attack by a really fortunate
attacker that is able to hammer multiple
that is able to flip multiple bits every
250 milliseconds for a full year
straight so that's not really realistic
at the moment with drum if
the chance that it finds a second
pre-image is less than 10 to the power
of minus five percent
that's it for now
if you want more details about for
example the corruption exception nesting
detection that we need
or how csro Hammer can work with
virtualization with or without guest
support
we have many more interesting
implementation details for example how
to protect the stack of the corruption
exception Handler
and also a multiple security evaluation
that shows why this works really well
read the paper
thank you very much I'm happy to answer
questions
thank you
just go on to the mic
I really nice work love the overhead
being low and everything I have one
question regarding the
uh the action taken when the air is
detected right you're trying to correct
it
and uh coming from the hardware crypto
Community I mean these kinds of problems
have been around for a long time and
embedded Community when you detect the
fold
uh you attribute it to an adversary
being present and then you basically
stop the computation right I mean
because that might also the correction
itself might give you a timing channel
potentially
yes we looked at the timing side channel
in the paper that's not of concern but
of course the operating system knows
about uh potential attacker so you can
do different things it could also kill
processors that have many that did yes
that's also everything is possible there
thank you there was also a paper just
recently published that just
um
moves the page that is attacked
somewhere else I think copy and flip
that's possible with the solution as
well yeah
great work is there any reason you
didn't include encryption on the memory
contents as well as the Mac uh yes
performance basically we wanted to have
a
least performance overhead as possible
but if you combine this with encryption
of course you get additional security
more questions
so I have one and you show that you are
able to correct the bit flip faster this
with less variability than current ECC
based Solutions I'm wondering how are
you able to do it faster than simply CC
um and
let's try again
you're talking
yeah that's it right so um
we are correcting a single bit flip in
256 bits of data and ECC is correcting a
single bit flip in 64 bits of data
but if we look at Rohan attacks
that the chance that they're usually not
really
uh
in a high locality so this is comparable
okay
no more questions
okay so let's thank the speaker again
[Applause]