Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/155 Thanks!
Hello, everybody, and welcome to our talk
about wide box cryptography,
the systÃ©matique of Patrick from the
University of Luxembourg, and he will
present this talk to us.
Please, could I ask you to remain
seated until the talk ends
or to exit very quietly because it's
disrespectful to the speaker if
you leave?
Yeah, and allow.
And also, there will
be no sitting in the aisles.
I'm sorry if you need power, tape it or
unplug it.
OK, where ed start
to floss is yours?
Please give a warm round of applause to
the military of its.
Hello, everyone.
So my talk
is words of two white box cryptography
today. It's a talk.
It's partially inspired by the research
we're doing at the University of
Luxembourg in our cryptography group,
together with Professor Alex Burakov.
And this talk is intentionally
not much technical.
Well, I suppose you're somewhat familiar
with the main cryptographic principles
and some cryptographic tools.
But I will not require much,
and I will not go deeply into details
of white box implementations.
So I suppose that those who are
interested will just
go for a reference and to
read appropriate papers.
And the purpose of my talk would be
to somehow give you
a brief picture of what white box
cryptography is and what the problems
are in this area.
So probably many of you had heard
of this term, and but
you might have had some troubles in
actually defining it.
But I should agree that it's either not
a well defined notion this wide box
psychographic.
So some people think that its
application.
Maybe some people think that it's
almost the same as public use
cryptography.
Yes, it's also partially true.
Some people think that the just
so not so better defined that no one
knows exactly what wide box
photography's.
Well, all this versions
of bars are true.
OK, so I will president
first, I will give you some more or less
details of three of my talks, so you
would know what to see in the
next slides.
So first, I will talk about
adversary models.
So when we talk about security
of cryptographic primitives and schemes,
we usually assume some standard model of
an adversary.
And when they when white
box cryptography takes place,
the model is nonstandard, some
unorthodox model.
And this it's sometimes called
manner the end model.
I will introduce this model
to you. Talk about some difference to the
standard model.
I will introduce you.
I will introduce this model to you in the
context of contact protection.
A protection of some media while
movies, songs, whatever.
I will give you some details about
current protection schemes and you
will see when this model
appears.
And you will see that the main problem in
this model is how to hide
cryptographic keys, the keys that
are assumed to be secrets and send
models. But in this model, they
are not secret until our big problem is
to hide them somewhere.
Then naturally, the notion of white
box cryptography comes, and the
crucial
notion in the area of white box tipped
over is the white box implementation
of some cipher or a function.
Whatever you will see that
the majority of white box implementations
of ciphers I build
up on the so-called lookup table
suggests a large, stable start in the
memory, and you will see why this
method is important.
You will see how the famous
block cipher, a current encryption
standard, is white box.
How a white box in current office
looks like.
You will see how it can decrypt analyze
how an attack can be constructed and how
actually. And you will see why
the initial proposal for a white
box is weak and you will see why
it is weak. And actually, you will see
that many of such proposals are weak and
actually no one is strong.
I will then talk about weak
and stronger sidewalks implementations
because there can be different
definitions in this aspect.
And I will tell you that while weak
white box implementations can be
constructed somehow, but with strong
white box implementation, we have serious
problems. So third scale background
doesn't allow us to build this sort
of cryptography, so-called strong
white box cryptography.
And then they will give us some.
I will explain some new directions
how we try to build white
box implementations, white box usable
ciphers from scratch, how we construct
that, the weak white box candidate, how
we face the nonlinear stability problem.
And finally, how we try to construct
white box cryptography schemes from
polynomials in final fields.
So this is a long cover your
my token. Now I will go
deep into details.
So throughout my talk, we can, I
consider a projection of really large
amounts of data.
So these are huge databases,
this digital media sort of gigabytes
or terabytes large.
This is some scientific experiments data.
So there is a huge amount to start our
hard drive storing data centers.
And of course, one person and protecting
this large amounts of data performance
is crucial.
So we have to deal with
parameters that are fast enough to
to enable a reasonable person
the data and a reasonable time.
And when they talk about performance
and security simultaneously,
we usually
work with so-called asymmetric
cryptography, so symmetrical cryptography
is some part of cryptography.
It's it's called symmetric because
secret components of some sort of
ciphers, usually secret keys are shared
between parties shared by parties.
And
the feature is there.
It's really fast, really fast compared
to noncompetitive close to a public key
cryptography.
So confidentiality and
privacy are achieved
with usually with ciphers,
of which the most widely known is a
yes block cipher.
There are three versions of it, and the
versions differ only in the key size for
us is not really important what the key
size is.
So the block cipher, it's called a block
cipher because that process it blocks
are fixed size and to process large
amounts of data.
Some modes of operation has to be used
so called there are counter and chain
modes of operation.
So you've just provided some
abbreviations to help with some
sort of recall.
I think you've probably seen in wireless
cryptographic implementations and
when we talk about when we want
to shift out in this situation, we want
to protect integrity of the data.
We usually deal with hash functions,
message authentication codes or
a larger, authenticated encryption
schemes.
I give so much details
about symmetric things because
they are not to blame.
They have interest in feature
so-called. So first, I say that
all these designs withstood two years of
cryptanalysis.
Years of attacks by different people
and their security are often
backed up with various sorts of security
proofs and arguments, but not so often
with formal and rigorous mathematical
proofs. Quite often, the security
of all the schemes are based upon
just observations.
Just some ideas why this particular
cipher is strong and secure,
and performance.
Why we love symmetric orthography.
As for performance performance, and it
has some cost.
While the RSA encryption
is believed to be secure because
it's directly related to a well
known mathematical problems, which is
believed has been believed to be HIH's
for centuries, the hardness of factor
in large numbers, in contrast,
is look, cipher is believed to be secure
just because no one has ever
broken it ever
published a successful attack.
And many people try it.
Ace was designed so that
it's easy enough to understand and is
enough to try and sort of attack.
But it wasn't designed for the forum
tiger security proof inside.
So here's the important difference.
So here we achieve performance at
the cost of not so much a rigorous
proofs.
And when they talk about
proofs and arguments, when the doc that
some cipher is secure,
we usually, of course, assume some more
or less formal model of an adversary of
an attacker.
A standard model wherein
where most of cryptographic algorithm
Cipher Subhash, for instance, are related
validated. This model dates back to the
previous centuries, and
usually we assume that the algorithm
itself is open publicly
available for scrutiny, so everyone
may try to find some weakness
in the algorithm itself.
But when the algorithm, when a scheme
is used, the key a secret key
is secret.
Key is stored somewhere when adversity
cannot access it.
It's in the reality, in hidden and in
hardware. It's the code is
running in some remote computer and what
an adversary is able to do is usually to
observe inputs and
outputs of a cipher, or possibly
an endorser can supply some desired
inputs to decipher and observe its
output. But it cannot control the key.
And this is the standard model.
This is the model that's usually used to
assessing the security of cryptographic
algorithms.
However, quite often in practice,
the latter assumption is very difficult
to establish and sometimes just
doesn't hold.
I mean, not it doesn't hold, not in the
sense that the key is public knowledge,
but it's quite difficult to hide the key.
And at some point we have to assume that
we can't find the key and we have to
present it within the algorithm,
but in quite a sophisticated way.
When that happens.
So the model when the
adversary has access to
also to the key is called man
at the end because
it's usually usually the we deal with
some sort of application where
cryptographic algorithms are performed
and an adversary has full access
to this application.
A typical example of
a man event model is as follows,
so suppose you are
a legitimate user or a legitimate user.
Some Ania Tucker, just she
just downloads a protected song from a
server I know from via
iTunes or whatever, and plays
this song on an authorized
music player.
Of course, ideally their copyright
owners want to protect it in the sense
that a person can file form
is downloaded about it.
Kind of.
A user is not supposed to be able to
distribute to share this
music elsewhere.
And of course, adversaries
may try to break this
sort of protection.
And in this game, industry
has, well, generally speaking, has
a lot of way to do this because
internet connection can be eavesdropped.
The music player code can be
viewed.
Also, the code can be
dynamically executed.
And if there is some cryptographic
transformation within some crazy
procedure, some schemas running, then
it's possible to view its internal
variables and possibly
read even the key.
Because, well, in cryptographic
algorithms, it's usually if it's
just normal code, that's quite easy to
see when where the
secret variable self-catered, and it's
quite easy to locate the key if if
there are not hidden.
And in this in this scheme,
it's rather difficult to hide the key
because, well, when in a software music
player, there is no match, way too
much way to store it.
Of course, downloading songs is not the
only application where you can find
the source of problem.
So when you work with the
larger media, with the movies, for
example, when movie owners
broadcast the just produced
cinema to movie theaters and
want to protect it when you're
playing, when you download and play
encrypted movies in some authorized
players, or you just stream
protected media directly.
Pretty much the same problems appear,
and you probably heard that
quite many of these protocols have been
previously attacked.
Well, how they were
attacked.
I've already described several
Wallner ability points, some potential
vulnerability points.
And indeed, there are quite many
ways to attack those algorithms.
Consider some specific example.
For example, a protect in digital cinema
is just a Real-Life example how
movies are distributed from their own art
to movie theaters.
So First Server possesses some
media, and then since
the content is rather large,
it's encrypted with symmetric cipher
s, for instance.
And but the player
doesn't know by default the
key, which was used to encrypt
a particular.
Movie and the
Askey must be attached somehow
to the media, as
you see here.
So we have encrypted
the content with the ASCII and you have
to send it to the player.
However, if if we send a key any
ASCII as a plain text, then
it would be possible just directly to
intercept it, tend to use it and decrypt
the media elsewhere.
So the ASCII must be protected
somehow. To do this, public
key cryptography takes place.
So RSA algorithm
is much slower compared
to a year.
But to encrypt
not so large key, it's pretty much
sufficient.
So in our algorithm,
there are two keys public key and
private key.
So suppose the player
has RC private key.
Then the server uses
its counterpart public key to encrypt
their key and then
attach it in an encrypted form.
The cipher text of the key, attach it to
the media and send it over
to the player.
And on the player side, the backlogs
process is initiated.
It means that the player uses its own
private key to decrypt
their ASCII.
Then this ASCII is
used to decrypt the media and
to stream the content to a TV,
to a screen wherever,
and quite typical
that the server wants to reduce his
own workload. And
if Sarah distributes the movie to
thousands of theaters, then
he does want to encrypt the movie a
thousand times. That can be quite.
Quite costly.
And the key
may repeat over theaters
over distributions.
So in this quite much complicated
schemes, you have probably noticed a lot
of well in our Bill 2.0,
a lot of points where this scheme can be
attacked.
So if we don't protect a device,
it's called the use of memory,
then wonder
how it.
For example, an attacker
might try to read the RSA key
directly from the device memory
and use it subsequently
to decrypt to make the letter
steps on his own.
An attacker might try to read the RSA
private key at the moment, where
it's used for decryption of a
key. Or finally, an attacker
might try to eavesdrop
the decryption process
of the large contact and may try to
to obtain
the key itself.
And quite famous
attacks on
DRM protects media protocols
like CIUSSS and the course they
all.
All this first could have been broken
along this line, so attackers
found the weakest link
in such schemes and obtained
our obtained encryption keys.
And after those keys are obtained,
it's it became rather easy to decrypt
quite a lot of content.
Well, you might wonder why
we want to use why
we want to extract the keys while it's
sometimes possible to, we
have the methods of lifting to adjust,
extract the entire code of a player and
use it for decryption.
Well, quite often it's possible, but also
quite often it's complicated because the
decryption routine might not be isolated
so easily, and
handling keys is easier because
keys are smaller.
There is it to distribute.
It's easier to update a particular key
if it's changed by a server.
The keys are much more difficult to
trace. So, for example, a
software can be watermarked
and well, if you can extract
keys, it's always much better.
And in the further text, we assume
that.
So in the front of the textbook and said
the problem of hide and keys, not
the problem of protecting their
code from code lifting.
So how can we hide
those secret keys in such
schemes?
There are two well known ways
of hide in
secret kiss first awake.
One can try to store a key in
the well protected hardware,
which is tamper proof.
Well, it's a success
story. So this method works, and
it has worked for four years.
Of course, it's obviously increases
the costs of an attack for an adversary,
but.
Well, it does make it usually a hardware
storage. Does it make that an attack
impossible? But it makes it much
more expensive?
But on the other hand, while making
that tech expensive for a foreign
adversary, this hardware method also
makes the procedure
itself for the protection the defense
more expensive for users
because, well, hardware has
some non-zero costs.
It's much less agile.
It's much more difficult to update,
and it can be vulnerable to all sorts
of side channel attacks like Diamond of
Power Analysis.
So you're starting keys and hardware
is one way and another way
is stored in here, somewhere in
software.
And when we talk about
hiding the software, then turn
the variables in the source code
somewhere. This is pretty much the same
as we know as obfuscation.
So obfuscation is another not
really a well-defined term, but
we'll understand that it's just the
method somewhat of concealing programs,
logic or behavior.
There are quite many heuristic methods
that are full scale programs, but
they all have some issues that
do not a law allow us directly
to use it to hide
cryptographic keys.
So some of them do not target here
specifically.
Some of them are vulnerable to.
Dwyer sorts of static and dynamic
analysis.
And another problem is that
the application is not well supported
by theory.
So on the third scale site, we have quite
many negative while also positive
results, but we also have a negative
results of sorts that we cannot
build to program that can obfuscate
everything
on the end. On the other hand, we
can obfuscate some very, very simple
function, so-called by functions,
but there is no good results in between.
There is no theoretical method that
is just for the moment flow in theory,
but just waits for its optimization.
No, the situation is worse, and there
are quite many holistic methods
which are, well, not
provable. They are very far from being
provably secure
while even convincingly secure.
OK. What?
I would like to elaborate a bit more
on obfuscation.
So if we cannot make something provably
unbreakable proof the secure, we
can follow the strategy of designing the
block cipher and at least try to make
something similar breakable, seemingly
secure and convincingly secure.
We may remember that in the beginning
of public cryptography, the
way of obfuscation cipher was
proposed, but eventually
public cryptography was built
on mathematically heart
problems.
OK, so if we talk about obfuscation,
so how could we officiate Key's
secret kiss and what sort of security
we actually get?
I mean, can we formally
defy and then, you know?
And security can be achieved this year.
Can we somehow prove that we indeed
get this sort of security from a
particular implementation and
that's where it box cryptography appears?
So white box approach appropriately deals
with the plus in
secret cryptographic keys in
cryptographic.
In the software algorithms.
So the crucial point
for why it works cryptography is
why it works implementation of a cipher.
It can be can be simpler stated
that why it books cryptography is the
white box implementation.
So white box implementation is
a pure software without any
hardware help and rendition of a cipher
with key insights, so it's either
decryption or encryption routine.
It doesn't matter much because they're
usually symmetric.
And when analyzing it security,
we first assume that this implementation
is fully available to an adversary in
the source code. So all the internal
constants, tables, whatever are fully
available to an adversary and
for defining security.
Well, first I use some not really
well, some vague definition
of security, but at least it gives you
some understanding what you want.
So for a good wide box
implementation, an adversary that
looks into it, she gets
no while little to no advantage
over a just black box implementation, so
block black box implementation.
It's the same implementation of a cipher,
but where the key is hidden and we
observe only plaintext and ciphertext,
but no internal variables.
So if our white box implementation
provides the same information as a black
box one, it's good.
But it's not a very rigorous
definition will proceed with the
definition of further.
So when you look at
this list of requirements, you will see
that this pretty much resembles public
key cryptography, so why not using
encryption schemes like RSA?
Well, clearly because of
performance.
Yeah, we have remember we remember that
performance is important, and we know
that RSA is several
orders of magnitude slower
than a yes. So for as I think and of
course, the the fastest implementation
on the recent Intel processors
with appropriate instructions.
So RSA also can be optimized somehow,
but still a huge gap
exists between the public key and
symmetric cryptography speed.
And when we talk about white box
implementation of some cipher,
of course we want that performance loss
should be minimal. So of course, we
cannot achieve the speed of
naked. Yes, we can achieve
one cycle per bias, but we can
achieve something in between.
Possibly.
So that was the goal of
the first designers of a wide box
implementation of some cipher to obtain
a white box implementation of a yes or a
similar cipher.
And apparently, people
quickly realized that when the design
in the white box implementation of a
cipher, our tools are very
limited. Because when can we hide
the key if everything is available to
an adversary?
So if historic is a constant and
adversity will seize if restore
a key is a function of adversarial, read
this function and this function is pretty
much equivalent to key.
So where to hide it?
Well, probably only in
some sort of table, since some where your
large tables swell, from which the
keys are are quite difficult to extract,
and what a naive way to hide.
The key is just compose
out a full so-called full codebook,
a look up table for every plaintext.
So given the key we are
and forever plaintext the computer cipher
text and store it in a
large lookup table.
But the problem is that conventional
ciphers and that's a requirement they
have quite large blocks at,
well, usually 128 bit.
And such a table, of course, is
impossible to generate and store.
But the idea of hiding something
in a large lookup table is
really profitable.
And well, how about smaller, key
dependent tables?
Well, they implement.
They can implement any function in the
appropriate domain.
So if we talk about
tables that process 32 bit inputs,
it's several gigabytes.
Well, not for like here, but a bit more.
So they can serve our purpose.
But note and it's very important that
all lookup tables that compose
are easily convertible.
We will face then
inverse ability problem in the fertile
slides. But
you will see that if you are given
a look up table, then by properly
sorting inputs or outputs that can be
easily inverted.
And here we comes to a white box
implementation of a yes, the first
implement, the first, the design
of this kind.
So a group of researchers led by Stanley
Cho in 2002, they simultaneously
proposed a white box.
Implementations for both both deals
and a sales just appeared to the
standards at the time.
But they will talk a lot about this
because I found it easier to introduce
say yes as a cipher.
So their idea was to obfuscate
its implementation with the key
insight to publish,
algorithm and use mainly
small lookup tables.
As algorithms, logic and published
as a sequence, the algorithm itself has a
simple sequence of smaller
table lookups where
input for each table is carefully
composed of the outputs of
previous table lookups.
And their goal was
the security goal was to make the key
recovery difficult.
So the recovery of the internal key
that's used in the.
So their goal was to hide the key so
that their goal was not
to make the cipher a non-negotiable
to prevent decryption given encryption.
It was possible, but the goal
was rather limited to make the key
recovery difficult.
How did did that?
So here comes the bit of
technical details.
So this is a so-called
block cipher, so it's versus
16 byte blocks
of data.
Well, as follows.
So this 16 bytes are split
it into four
blocks of size 32
bits.
Well, here are the denote as boxes as
the D2 and ACE
has structure of so-called 10 rounds,
10 almost identical transformations,
and each transformation works
as follows.
So first, the key
is taken. It's just sort
into the internal state into every
well. It's also has four
16 byte long, and it's just
sort of every bite.
Then every bite undergoes
some nonlinear transformation called
sub bites, and then
a linear transformation is applied
to this to every block of four bytes
wide.
And after this, the sequence of three
iterations of this six and bytes
are permeated.
And this is this is done for
this done 10 times.
So pretty much the same 10 times.
So the key is to be different every time
to prevent some very specific
sort of attacks.
But the main feature is like this.
So the
main point of this description is that
A splits its input into four
blocks, so four blocks undergo
each undergoes some specific
transformation. And then there's the
bicep muted.
That's the thing.
And having this picture in mind,
the designers of the first
white box implementation, they press it.
This follows. So their goal was to hide
the key key in the scheme,
and they had to do this at
every round. We'll consider only one
round, but the procedure
is pretty much the same in other ones.
So now I will describe a white
box and cordoned off a round.
I will. Well, the original
idea was much more complicated
than I describe here, and
it was much more optimized.
So what I describe here is first a
stronger version.
And second, it's requires
much more memory.
And even though this version that
I described here is stronger, it still
can be broken and badly broken.
So you don't lose anything
in listening to
my view of what they've done.
So the original version was just
a bit weaker, but also smaller.
So the designers
worked mainly with this 32 bit blocks,
so they left this byte
permutation apart.
And their goal was to hide the key.
So what they did, they
secretly generated
linear transformations.
P and Q made them
some sort of mutually exclusive
compensating so that if
you put P
right after Q, they would compensate each
other
so that the encryption process
would still be the same.
But this 32 bit block?
It will operate a bit differently, and
the idea was to hide this
secret key between
the two secret lunar
transformations.
So
they generate a distance formations for
every round and for every block and
the resultant 32 bit block.
They just computed
a full lookup table, which is
again key dependent and has two
to the thirty two entries.
Well, originally less, but we'll
assume that it's just like this.
So to the thirty two entries
and they start all this tables in memory
and having like this, so
the ten rounds of layoffs were just
sequences of this tables and byte
permutations tables and by table
look ups and by permutations.
And this worked pretty much the same
as the original is.
And, well, the same idea was
used for the DEA Cipher.
But the problem of all this
implementation is that they can be badly
broken.
So the well known methods of differential
cryptanalysis applies to all
of this proposed implementations.
So the idea of differential cryptanalysis
is that we can see their differences
will be the difference between
pairs of inputs.
So I recall that
the full lookup table is available to
the adversary and
looking at inputs, you can compute
the difference of inputs and difference
of outputs, and
that worked briefly
as follows.
So we consider multiple inputs
and we look we consider the evolution
of difference between them.
And we just guess that for some
pair of inputs, the difference
becomes after it goes through linear
transformations, it becomes non-zero
only in one as box well,
possibly in two as boxes.
Well, suppose they're in one.
And the next important thing is that
this input pairs.
They form some sort of linear
space.
This linear space can be detected and
it can be detected because the output
difference they form a metrics and
this matrix.
It has low rent because all
this out for differences
of size 32 bits they were generated
of out of
a difference in only one byte in
eight bit.
So some very simple algebraic
properties are used, and
this is enough to detect
the case when there's differences
shrink to only one byte to recover
P and Q, and subsequently
to recover
well being recovered up to some linear
equivalence. And then the key can be a
simple as well.
This layers are removed and then the key
can be simply guessed from this lookup
tables. It's very simple.
And with other optimizations, the entire
key from the whole wide box
implementations can mean that in just
two to three operations, which is on
modern desktop with just seconds
and all the subsequent
ideas and proposals for refinements
of this simple principle.
And they all were broken.
Part of problem, why they were broken
because, well, heaven on the two
linear transformations and one nonlinear
layer is not enough.
There is a paper more than 10 years
old that shows that even if we had three
nonlinear layers here, then they
can still be attacked.
And when we consider a yes,
there is only one nonlinear layer
in a round and this scheme,
even if we surrounded with unknown
B and Q, it can still be easily attacked
and generally the table based
approach the approach based on lookup
tables, it fails for a yes.
It also fails from any other ciphers
just because of structural failures,
because if we consider smaller
part of a cipher for which.
For which a look up table
can be constructed for smaller ones,
then only a small part of the key
is hidden here.
Only 32 bits.
And if we consider a larger part
of a yes, then the
tables becomes too large.
So hiding in turkey
would require enormously large
tables, which you cannot allow.
And all this table based approach
that failed for years
and other ciphers. So some different
design is required to
sew. A cipher must have completely
different design, and
the key must be injected in different
ways to be suitable
for a wide box implementation.
So here is just an overview of other
proposals, so all that
a white box and
implementation have been broken.
All the DS wide box implementations have
been broken quite
many years ago.
All the attacks have practical
complexity, and indeed, if an adversary
ever gets their full entire record
with this tables, it can be easily
broken.
But to my
great surprise, well,
everything it is broken.
To my great surprise, there are quite
minor proprietary solutions on the market
from different companies, including
companies started by people who
made the first white box implementations,
and they are certainly aware of
the existing attacks.
So this solutions probably combine
well this week academic proposals with
some additional obfuscation techniques,
and we do not know anything
about their security.
Well, there are no public attacks on the
schemes. Maybe they have been
there, Vertex, but they are not
published. So I recommend you not
to trust these schemes at all because
academically, there is no strong white
box scheme.
So
the previous parts of the previous
five books implementations there are
devoted to recovery, but what about other
security goals?
So can we use
this principle fireworks implementation
for something else?
So one definition,
which we do know to the so-called
required books, cryptography deals
with the key very secure
to so-called is the goal that
an adversary cannot extract the key
from the code.
Well, this definition was chronological
at first, and it's apparently easier
to achieve, even though this
previous implementations were broken.
But when indeed the code lifting
was used, then this definition
is irrelevant because when you can use
your white box in implementation
as a decryption routine, then the
white to care about recovery,
it's useless.
So.
People introduced in other definition
of so-called Strunk White box
cryptography, where
we require that even though
their implementation
is published, that verse there cannot
invert the cipher so it cannot
get a decryption routine
from a publicly available encryption
routine and encryption routine is
available together with embedded key.
It applies in the case of code
lifting and but also it's
almost identical to public key
cryptography.
And the problem is that
it's as difficult to design
as public key cryptographic schemes
and all the existing proposals for wide
box implementation that don't comply to
this definition at all.
They are all easily in virtual.
And when we started
our research on weight loss cryptography,
so we started thinking that
indeed. So if
current ciphers are not so
much suitable for white box
implementations, even
recover security is difficult to achieve.
So does the station change if we make a
white box suitable cipher from scratch?
Well, apparently it does,
at least for a quick recovery security,
so we can claim that
we can achieve good recovery, secure a
weak white box orthography.
In our proposal.
And the idea is so if
we have the goal of just hire the
key in a table, then
it's super easy.
So you just
take an iOS like Cipher, for example,
consider a 32 bit cipher
and then just take
128 bit key and
apply a 32 bit block,
then some lean years information and then
get the key. Apply a
32 bit transformation and then make
a linear transformation and eject the key
and do this say 20 times.
So the every bit of the key
is used five times.
And make it a huge
a lookup table out of it,
if you want a cipher with the larger
block. You can.
Make this in Berlin, mixed outputs,
so the cake will be perfectly hidden,
security margin is even larger than in
regular is.
But the problem, of course, it's trivial
and vertical because given this lookup
table, it's rather easy to obtain the
plain text from a cipher text.
And this is the problem of every table
based white box
cryptography since, well,
because of their of the implementation
size lookup tables, allowing inputs only
up to 32 bits.
Sort of. And we
just don't know.
It's really an open problem how to
compose lookup tables
so that they
cannot be invisible easily by an
adversary. So we might allow that
they can be invisible.
If you know the key, if you know how
these tables are structured.
But if
that works to just know the key he
cannot invert and
we don't know how to do it.
So doing this would solve a pretty
good problem in cryptography.
It's pretty much similar to what we know
as one way permutations.
So-called Ted, there are permutations
were introduced in the beginning of
public key cryptography, and
things like RSA has functions
are seeing encryption function is an
example of a trapdoor permutation, and
they are believed the only problem is
that believed to be secure, you
consider a secure for really large
and for which the performance is usually
not attractive.
And for smaller end, for example,
performance, this is still an open
problem.
We also consider some algebraic
constructions because we know that
inversion vector functions,
which are even degree to
polynomials of our finite fields,
is difficult.
And the problem is you cannot
make such a polynomial at random
enough to hide this trapdoor
sight. And there are quite many proposals
in this area called multivariate
cryptography, and they were
all broken up.
Unfortunately, outsold the whole scheme,
it looks like there is.
Publicly available Polynomial A.
It's surrounded by
a fine transformations S.A.,
and while it's inevitable
because of properties of a as
unfortunate, unfortunately, the families
of convertible polynomials are pretty
small and all
this schemes have been attacked pretty
many of them.
Some work in progress and our direction
is to consider two layer
schemes where
we would have to nonlinear
layers A1, A2 and some
supplementary level
multi-level A3,
where we eventually get polynomial
of degree for and
esteemed you.
Here are a fine inverse to both
transformations.
But this is still pretty much work
in progress.
So there is some hope to build white
box good wide blocks of thoroughfare
on the algebraic basis, but it's far from
being explored and finished.
And so
short summary that
white box approach, if initially was
aimed to obfuscate encryption or
decryption the rotis with keys inside.
Isn't it quite similar to public key
cryptography and the
main feature of existing
proposals that they are all
week and they have been broken?
So use every solution
why books are part of solution that is
offered on the market with a great care
and we we are afraid that just
good file box solutions do not exist.
But if they exist, it would be a really
good solution to an
open problem, though.
Thank you for your attention.
Thank you very much, Dimitri.
I expect after this talk
a lot of questions, if you have
questions, could you line up at the
microphones put up appear
in the room?
And I want to ask our signal
angel up there.
Do you have any questions from the
internet?
No, no questions
from the internet.
How about questions from
inside the room?
OK, go ahead, please.
Um, it's more of an practical
application question,
um, from the tax taxi have shown
and are referring to that as a
metric for encryption is too slow to be
feasible in the practical context.
What?
What improvement would I get from using
as a metric encryption, because the
problem is the
user or its antivirus, which isn't,
you know, AutoZone obviously
has to do the decryption.
So the interesting part in the first
place is the description key.
So using asymmetric encryption,
it would keep me from after extracting
the decryption key in several
ways you described.
Asymmetric encryption would keep me from
obtaining the encryption key.
No, it wouldn't.
So what would what to bring
and what what's the good part about?
Yeah.
Well, let me scrub it to
the first example.
So as you
might see here, so you have a
pretty much large content.
So if you encrypt it just with
a symmetrically atrophy, it will be just
very slow.
You can have an encrypted with a warfare
if you're encrypt only
with symmetrical photography.
And the key to this as the
symmetric scheme encrypted with
asymmetric cryptography, then it becomes
vulnerable.
While this semester key is
used, and if you
have a good white box scheme here
that you can replace both encryption
and this scheme with just one white
box scheme. So if its performance
is good enough, then the key cannot be
recovered in this scheme, and
performance loss would
be a much smaller compared to
the total use of asymmetric cryptography.
So just answer the question.
Mm hmm.
And.
And perhaps I just missed the
point of the complete speech a bit,
because in the end, all
the white box encryption schemes look a
bit like, what's up obfuscation to me,
it's not good, not a really different
quality than obfuscation, is it?
They are not much different from
obfuscation. And yes, it can be
simply stated that the just application
of symmetric schemes.
But this obfuscation they
it really brings us to the world of
public cryptography.
So they're just crazy creatures
in between.
OK, thank you.
OK, then microphone number
four in the center of the room, please.
Thank you for your talk.
I had a question because you mentioned
these lookup tables and making them hard
to inferred.
And then you said that you tried
trapdoor functions or someone tried to
get Chapter 14 and that was performance
wise, really difficult.
And I can imagine that
you can't do any better than trapdoor
functions so that you
can prove that if a central function is
just too hard to use, then
you won't find anything better.
Have you looked at impossibility proofs
there?
Well, the fact that we
would not like impossibility proves
because we can't possibly
prove that
some sort of trapdoor are impossible,
but maybe we don't need something
that is provably
non-convertible here.
Maybe we can hope for something
like for a yes, that is just seemingly
non-convertible.
We it's a key to not having
a formal integer as proof that it is
a good trapdoor, but it could be key
if that's just many people try to
inverted and didn't succeed.
So that's our hope to get away from
rigorous proofs here.
So this possibility is not what we
would really like.
Okay, thank you very much.
OK, microphone number two, please.
So I'm not an expert on cryptography,
but
my understanding is that in symmetric
cryptography, you have the same key for
both encryption and encryption.
So isn't it?
Why do you care so much about
inevitability? Isn't it an important
attack vector to if the
attacker is able to basically rerun the
ciphertext for whatever method you use
and then to get the plain text again?
It doesn't matter how you implement it,
even if you just created, he just
gets the plain text again by just
rerunning whatever you have implemented.
Isn't that an important factor of attack?
Well.
So in semantic cryptography, you have
a cipher, so if you have an algorithm
and if you are given a key that
you can easily run it in both directions,
if you're given a table of so-called
full code book table, you can again
inverted and use it in both directions.
But the idea is to
give you some sort of an
algorithm with key and with embedded
keys so that you cannot invert that
easily to give you some sort of function
that you know how to run the tin forward
direction. But it's obfuscated
in a way that you cannot run
into the benkler direction.
You can imagine it, like supposed to
have two functions of the same input that
you just sort of outputs.
Of course, how would you inverted?
But but I mean, my point was that
you couldn't you just rerun it on the
ciphertext to get the plain text again,
basically.
No. So decryption algorithm is
not.
Maybe not.
Obviously, not that easily.
But I mean, isn't it some some possible
way of attacking that?
No, not really.
Sold the decryption algorithm is not the
same one, so it's easily obtainable
from the encryption one, but usually it's
a different one.
OK.
OK, then we can have one question
for microphone breakdown down number
three, please.
So. So if I
understand it correctly,
if you have
the classical problem of DRM
is that you have the algorithm
that decrypted because you have it.
You have to have it to play the movie,
to play the music
or whatever. So, yeah, I
understand it.
I think the key would be somehow
somehow good for the for the implementers
of DRM because it makes
it slightly harder
to to implement
the attack.
But if you
basically I can see how it would be
possible to break
through to not allow the
attack that
uses the code that you have for
playing, oh,
it's full formal, it's impossible.
So and the main implementations that
can indeed easily extract the code
and use it as your
own routine.
But ah, well, this is some sort of
solution for the kids when this is not
easily. So this if you
have this white box implementation
that it immediately increases
their tech costs, it
will require that nursery to use
just the code that it was given
that not anything else.
So it limits their daughter's
capabilities somehow, and that's at
least some partial
achievement.
OK, microphone number one.
Yeah, hey.
So first, I want to thank you for the
presentation because it helps shedding
some light on the mysterious topic of
white box cryptography, and it helped me
calling out bullshit on the whole idea.
And I think somebody should make this
critical comment because the whole
concept breaks with one of the
principles of cryptography that an
algorithm should be verifiable, right?
So if you obfuscated to hide
something, you know, if
it's only hiding the key, it's no use
because I can.
I wouldn't go after the implementation at
all. I would have other ways to attack
and recover the key. Everybody knows how
easy that is.
And if it obfuscates more or even changes
it, then it breaks with the principle of
being verifiable.
Right. So I think the whole thing is
snake oil and shouldn't be used by
anybody.
Thank you for the comments.
OK, last question for microphone number
four over there, please
just have a two part question.
Can you achieve white box properties
with homomorphic encryption?
Theoretically, and the second part is,
can you do that practically?
Are he?
Yes, well,
I think with most of the public
key schemes, well.
You can.
You can achieve this.
The problem is, again, performance.
I would say so, I think the performance
of the main problem that prevents us from
using candidates from
things like homomorphic encryption or the
latest that they're based on, so.
Things like that, there have been some
recent recent improvements, 2012
2013 in fully
homomorphic schemes,
do they bring the
sort of level down to
where this may be practical for for white
box properties? Or have you have you not
looked into this?
Well.
Uh, you know, I didn't really think
in this direction of for the morphine
version, if you give this just some time
off line, they have to think about it,
probably give you a better but transfer.
OK. Dimitri, well, thank you very much
for your talk.
Thank you, John.