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/654 Thanks!
I'm going to talk to
you about an idea, arhats on
how we can kind of regain a
little bit of trust in
the everyday computers we
use.
So what is the
problem?
Well, the problem is basically these guys
I mean, the thing
is,
like we all use computers in our lives.
We use them for
like I don't know what use them for, but
I use the most important thing I think
I'm doing with my computer is actually
talking to other people.
I mean, yes, we are all watching videos,
but, you know, talking to other people.
And we do have quite a
problem there because even though we
have developed quite a lot of solutions
to make this talking to other people
more secure and to actually
hide from these guys what we are talking
about,
like all of these solutions, like, for
example, or TIAR
or signal,
like executing in.
A like basically this
so this is a block diagram of a modern
computer, in this case the Lenovo Extra
30 I'm using to show this presentation to
you.
It's a kind of
three year old or something laptop
based on an Intel CPU.
And like as you can see from this
block diagram, the thing is super
complex.
And the thing is that
on this machine, I'm executing my GPG
and everything is encrypted and
everything is fine.
The only problem is like the plain text
of my emails, which I'm decrypting, even
if I'm using something like a smart card,
it's going all over the place.
So A
we have like a super complex system.
We have like also in this case, the
red highlighted things are
like subsystems that contain some form
of proprietary firmware, which we cannot
audit.
And all of this makes.
I would say pretty easy for a
sufficiently well-funded attacker
to actually attack that system.
So now, if we want to consider
this system and like
what we ultimately want from it, I mean,
ultimately, I want to talk to
my friend about computers because
I like computers and
I generally use a keyboard to
like type stuff.
And then I click send and then get
send and encrypted and
decrypted. And on the other end it's
displayed on a screen as
worts and my friend reads it.
Now, the thing
is that as
you can see from my plot diagram of
highlighted, like the parts that I like,
I actually need for that communication
and green like keyboard and display.
Um.
If we say that, OK,
at the display and at the keyboard, I
basically need to use plaintext because
Krypto glasses are not you have to think.
And also I cannot really
type in hours or something.
So in the end, I kind
of need to have plaintext there.
But on the other hand, I don't really
want to trust all of that other stuff,
especially like these things running
unflustered firmware, like the things
we've read. What is the problem
in that case? It's like since a couple
of years now, Intel has
gifted us something, namely CPU's
and basically
the platform controller, which is
containing the integrated graphics, which
are both running proprietary,
a pretty robust engineering
resistant firmware.
So I have to use
this CPU. I kind of need that because
I want to encrypt stuff and decrypt
stuff, but I
don't really want that thing to be
handling plaintext. But on the other
hand, like, I have no choice because
there you see all the arrows are pointing
to it. There's no way, no way around it.
So we need to
like, think about where can
we place that kind of trust boundary.
And I think realistically,
there's really only one choice,
and that is basically to place this trust
boundary like up to where do
I want my plaintext to be and where do I
want my ciphertext to start
right at the input and output devices.
Because realistically, I don't
think there's a really high chance that
we will be like reverse engineering
into management engine and then better
control of firmware for any
any for any practical
number of platforms and keep it
open for any number of years.
So the places
where we need to put this
kind of encryption or
something that makes it happen is
a in the display plus or display busses
and the laptop.
That's primarily a Alvidrez bus,
which is a digital display based on
more modern devices you would use and
better display port, which is basically
very similar to everyday, just with added
protocol layers.
It's like very high speed, but it's just
plain pixel data.
So there's not much encoding happening
there, no video codecs or anything like
that.
And on the keyboard side of things, that
is basically the
and that is like this laptop.
And I think most of our lenno
devices, the embedded controller,
which is some kind of management thing,
which is doing basically everything that
couldn't fit somewhere else,
is basically scanning the keyboard
continuously. And the keyboard is just
really a dumb matrix of switches.
So pretty much no active
devices there except for a couple of
LAT's for like muite and polla.
So from this
point of view, we need something
in between of these components that
will be receiving hopefully only
unflustered ciphertext from
klavern controller Hape, which contains
the integrated graphics and the embedded
controller, which contains
the basic keyboard,
keyboard, matrix scanning and forword
like do some decryption there and
encryption on the reverse path and
forward that to display and keyboard,
which fortunately are
pretty simple devices.
So there's not much logic happening
in there yet if we
ignore and but at this report and
so on.
So the thing is now if we
look at that looked like CPU and better
controller platform controller hub,
the intercept to display keyboard
and these two pretty simple basses.
That has a nice side effect of
implementing a system that way, and that
is that these two simple busses
are used pretty widely.
For example, this is a block diagram
of what's in this case.
Texas Instruments would like your
smartphone to look like
it's pretty much the same for the
windows. They basically just
exchange, like who makes the parts.
They all do this basically the same thing
you have, like the CPU in the middle of
this application processor, which in
fact it's a huge system on a chip like
modern ones even include like packet
switched memory boxes and stuff like
that's a really advanced stuff.
But in the end, that thing is only
talking to your display
via something
very similar to Alvidrez.
Some are even using embedded display
port. So like a high speed protocol, but
still pretty dumb.
And I mean, you don't have a keyboard and
most smartphones, but you have like
touchscreen. And these touch screens are
generally also controlled over like a
simple super protocol, like
ICSE. So we can definitely
adapt the solution from before to
also work. In a case like this, you will
obviously have like poor management
issues and form factor issues, but.
Purely technically, from the electronic
and computer science side of things,
this should work.
Um, so if
we look at this block
diagram of of this
general idea on how we could organize all
computers, we have this intercept
device.
So it needs to kind of do something with
words like receive that
process and send it back out and
do something with the keyboard switch
matrix scanning.
Like how does this like how
how would you actually control that from
an application point of view from
software running on the host machine?
Um, basically this is the general
idea I have for that.
This is a diagram of what a frame
sends from a basically
basically any moniteau standard today.
Looks like you have like this vertical
and horizontal sync signals,
which basically are framing information
stemming from back when Vijay was a
thing. And then you have like
the actual content area, the
where most of the time you have some kind
of desktop desktop environment running
and then you have like a application
window inside that desktop,
which may contain something worth
protecting.
As an example, think, for example,
of Thunderbirds, where you want
where I want to send encrypted email
to my friend or I want to receive an
encrypted email from my friend.
So in that case, Thunderbird is like
running on my Linux system,
displaying a window.
So if I'm receiving an encrypted email,
that window is displaying, like
basically if I would not have like an
e-mail or something installed, it would
basically display ASCII Ahmad
GBG Binary.
Now, what we need to do in
this to make this work in this
scenario is we have some kind of add
on which which recognizes
that I'm just playing like GBG Armored
cipherText and which will
take this Fujiyama
like convert it back to binary form
and then formatted it as a simple bitmap,
a bitmap that contains a special header
at the front that tells
the intercept a device something like the
width and half a height of the bitmap
and contains a authentication code.
So I can't just
cannot just anybody go and a business
which would work with my incepted device.
And then I need to display that bitmap,
which fortunately I can do on basically
any operating system, any platform.
And this bitmap is then
interpreted by the interceptor
and decrypted
on the fly with
the intercept. Since it has access to the
keyboard and this may ask me to input a
passphrase or two,
I don't know, insert a smartcard or
something depending on the
implementation.
And the decrypted plaintext
is then rendered into a
pixel buffer which is inserted
in the life display
data stream, basically at the same
place where this payload was communicated
before. So basically, if I'm running
Thunderbird, I would make this.
And also the entire window
where I'm reading my email would be
this payload area and containing the
ciphertext.
And this interceptor would exchange that
by the decrypted data in flight.
Now, how would you actually make
that work?
The thing is, this interceptor needs to
be able to process
this really high speed display, places
like Elwood's and do
like in-flight transformation on it.
So that's a pretty hard task.
And also we want it to be like
somewhat not too complex so
we can actually secure the thing itself.
So we don't just replace like one huge
attack surface with another huge attack
surface.
Now, the like,
to me, the most obvious way to do a way
to do this would be to use an FPGA
for most of stuff, because these
things are
basically very nicely suited for
this application, because they're really
good at handling large bandwidth,
high bandwidth, high frequency
data like and display bars.
And yeah, this is basically how I would
imagine a such an FPGA
based interceptor to work.
By the way, sorry for the non-plan on
graphing.
So like without looking too
much into it, we can already see that we
have an advantage against like
this eighty six, uh, platform
like Vilanova X to thirty here in
that we have like we do still
have a lot of components, but they are
not like that, they are not that
centralized.
There is like some some factor
of combat combat compartmentalization
there. So
I have, for example, a
I will for example, if
you consider the display data path,
if my display signal does not contain any
payload, any headers, any special
markers, and it's just regular display
data, then
it will like it will go in.
This diagram would go up, go in on the
bottom right side, which is basically
the from the untrusted domain,
from the platform controller up on into
platforms, it will go through a Ovid's
serializer, which spacer converts it into
a smaller frequency, lower frequency
signal for F.J.
internal use that would go into a pattern
detector. Now, if that pattern detector
does not detect like this special mocha
header I put in front of my jpg
payload,
it will not do anything.
It will just pass on the signal.
The signal will then go through a frame
buffer for like Klok reasons.
Then it will go through a buffer switch,
which in this case also does nothing
because there's no payload there.
So there's nothing to replace.
And then back to serializer.
And the interesting thing is that at no
point this high bandwidth
display data signal, which may contain
like other sensitive information, I don't
want the interceptor to know.
At no point does it even touch
anything.
Apart from some relatively
simple parts
of like digital logic, so that it's not
going through any kind of CPU or
higher level processing, it's basically
just a bunch of schist registers, pattern
matching and a couple of Paphos.
So in this way, I can organize
the system. So that's
like sensitive data is really
only touching parts that absolutely needs
to touch, like from an electrical
point of view. This like on the Fuge
separate busses for this kind of data.
And this way I can kind of
reduce the attack surface of that
somehow somewhat.
So let's consider now
the case of a frame
that contains actual encrypted payload
data.
Now, the key for this data is in
the like, depending on the
implementation, even the FPGA itself or
in a external access module.
So basically the smart card
and the CPU and
graphics processor, which format of that
data for me do not know that key.
So that can decrypt it.
They are just running a basically a
bitmap graphic and
now the pattern detector and this
device will, when it's receiving this
data, recognize that header
which was previously formatted and that
it will go on and write the payload.
In this case, like the A probably
probably some lightweight protocol
and then the actual JPEG data
into a payload Tafa.
And upon completion, it will
notify something I called
the application processor because
basically I think you will probably need
something like that.
And this application processor will then
do processing on that.
Like, in fact, what it will do in the
case is it will
probably do some protocol decoding,
then extract the actual
cryptographic payload, send that onto
the to a Cryptochrome processor.
I think it makes sense to distinguish
these two things here because A,
the application process, like for
most things you don't need like any kind
of cryptographic acceleration.
And on the other hand, maybe you don't
want the thing that is handling all the
complex protocol logic to actually also
do the encryption, decryption and
handling of plaintext.
And this Cryptochrome processor would
then decrypt this payload,
possibly with the help of a smart card,
secure access module, and
then for the plaintext via a
separate data path to the renderer.
So physically, the application processor
in this scenario would never be in
possession of a plain text.
So even if you compromise it through
some way, some means you would not be
able to access plaintext data there.
And the render would be a piece of
basically prolly another processor
realistically probably running something
like free type that is converting
like UTF eight inputs into
pixel data, which as it turns
out is a really complex problem.
But I will be coming back to that later.
And this renderer is then outputting
a bitmap and to render buffer
and this render buffer
is then dynamically switched into
the inflight leader.
So I am at a display signal by this
uSwitch thing. So the buffer switch
basically just needs like the position
where to flip between
upstream display content and the above
and into account
the position and X and Y coordinates and
then switch over and switch back.
Now, the nice
thing about like this entire
compartmentalization thing is that
it enables also some kind of
some neat security features.
For example, one thing you can do is
for the you see,
the retina has to inputs like a the
application processor may want to render
some kind of some kind
of user interface.
So like a password prompt or
a I don't notice a message.
On the other hand, like the crypto
processor wants to render like plaintext
data. So in this case,
the renderer is getting two different
data streams. It could, for example,
color coded.
So to ask to make
like spoofing of,
for example, the application process of
messages from a
from Bii, like having a cipher text
decrypted in the device a little harder.
So you kind of know that if the Texas
v. Texas blue, it's the application
process, the interceptor directly talking
to you. And it exists like Ratto
something. It's the it's
like a decrypted email you're reading
now if in this this
scenario. So now I kind of like to
decrypt and securely display
GPG immense.
Now, assuming I want to actually write
an email, how would I do that
when this case basically what you would
have is you have this keyboard, DeCota
and emulator on the top and
bottom. So you have like the DeCota,
which is reading all of my physical
mechanical keyboard, and the
emulator is then simulating another
mechanical keyboard to the rest
of his system, like
implementation detail for two thirty
would be that you can have like the
function key, which is wired into the
rest of the system as a physical
data line instead of like multiplexed
data lines.
You could have that like, say, electrical
override so that this keyboard emulator
can only actually emulate
the keyboard when you are pressing that
key so as to like, still make
it a little harder to exploit.
That's an order, too, like, I don't know,
and a command center or something.
And the refillable would basically be
like this. I would press
like I would sort of start writing an
email and then when my cursor is
in the editing field, I would,
for example, press a certain key
combination which tells
this interceptor device to and
the application process within it
to display me a like basically
a very simple text.
It just needs to be complex enough that I
can enter like text
in a language of my choice and
to be like internally representing
that Texas, some kind of like you'd have
eight. Now I enter my email
message into this application processor
and then I would press on this case
a certain key combination
to, for example, I could like choose
the recipient key ID, or I could
possibly also communicate that
information about extension that is
highly implementation dependent.
But in the end, the application processor
would send the plaintext to the crypto
processor, which would then input
the encrypted ASCII Ahmed
ciphertext via the
keyboard emulator into my actual email
client.
Now, another interesting thing is
that here the krypto, like nobody but
the cryptococcal processor, doesn't need
any access whatsoever to the keyboard
emulator because basically I don't
I can't think of a reason why the
application process of what would want to
push keys on my keyboard.
So in this case, I kind
of have like the cryptochrome process of
having exclusive access to the keyboard
emulator and then it is entering
this ciphertext as if I was be
like typing GPG really fast.
And my clients in this case wouldn't even
necessarily have to know about
that, because for it's for it.
It's just a keyboard.
Also nice thing about it is like
there's no you don't need any operating
system level drivers.
You may not even need
like application level support, for
example, you could maybe you
could have like parts of this like office
bitmap, formatting, running in the cloud
or something like on a different machine,
which you trust more.
So now we have like a physical device
which can do some kind of encoding,
like encrypting and decrypting of data,
and which in order to do that, has
to do key management.
And I mean, putting a smart card next to
it, I don't think it's a terrible idea.
But still.
That doesn't look too secure to me.
Also, I have the advantage that's like
compared to a full
six mainboard,
this system is pretty simple, like the
you could probably do it with like a four
layer PCB.
So this is actually within the realm
of possibility for a hobby is too like
Soldo themselves.
So I think one thing we should
seriously consider that is making
that taking that concept and making this
device into an actual security
module, as they are usually
used to like stole SSL certificates and
so on, because they are not
actually that complex to build, I think.
And that would present a
much higher hurdle for an attacker to
actually pull any plaintext or
key data out of that system.
The call suddenly and like not prosecute
anybody is basically you have a
intrusion detection feature on the
circuit whereby the circuit detects when
you open the case or drill holes in it
or remove it from the device
and you have like a backup battery that
keeps that online no matter what happens.
And the interesting thing about making an
officer out of that would be that you
could like, for example, have it
wipe actively wipe a key
when it detects that the case is being
opened over the case of the prosecution
itself or even just the laptop.
So.
Talking about how a security modules like
how would we actually do that now, I have
actually just assembled a couple of those
myself. So generally
most of the security modules that I
actually use today basically consist of
a some kind of CPU and
some memory and some SRM, which is used
for storage.
And all of that is put in a box.
And on the inside of that case box,
there is like a so-called mesh
printer. This is basically just to
like PCB tracks
printed on the inside of a case making
their way all around it,
contacting the main PCB at like a
couple of points.
And now the there's a part
of the circuit inside the hardware
security module that is continuously
monitoring these traces, whether
they are broken.
And the idea is that in order to get to
the keys, which are in the memory inside,
you need to first open the case.
And to do that, you need to break these
tracks because they are all over the
place and you can drill a hole in it
without breaking them.
Now, I think that can
be done pretty easily and is pretty
effective. For example, one of the more
effective approaches I've seen
in practice so far is like a basically
a flex flexible plastic foil,
which is printed with some kind of silver
ink. It's basically exactly the same
material you find inside really cheap
keyboards, you know, on this rubber
dumb things. And
that stuff was just wrapped
around the PCB on all corners.
And then everything was puttered with a
little flexible but really chemically
resistant potting material like epoxy
resin. And now as soon as you would
try to remove that, it would totally
rip apart these
sensible traces on that
on that plastic foil.
I think that's a nice approach.
I think there's a couple of other things
I would kind of like to try.
So like one thing is RF interference.
So you have like a metal can instead of
plastics and you have, like, just wire
randomly stuffed into it.
So you can't really predict where the
wire is. And then you have it puttered
and then you continuously measure the
frequency response basically of the
of different wires and traces within
that case against each other,
the coupling between them
and measure when that significantly
changes.
Now, whether that works in practice, I
don't know. It would probably be pretty
expensive, but it might be worthwhile
to at least explore what
I could also imagine, like using a some
kind of ultrasonic measurement.
So you have like a positive bias.
And on the main circuit board, you have a
couple of small ultrasonic
pixel transducers and you are sending
like ultrasonic through the physical,
like the the the potting material.
And you are measuring if that response
does change at all,
I think that might actually be pretty
effective, because in order to, like,
open it or do anything to it, you would
actually need to, like, touch it.
And if you like,
maybe you could use a laser against
something like
Advanceable. That would be that would be
pretty cheap, though.
This may come with like high current
consumption.
Another approach that I would like to try
out is like tribal luminescence.
So basically you put a couple
of photo diodes through like really
sensitive light detectors on the PSP
itself,
and then you encase everything with a
clear potting material that is
like mixed with like
so-called like friction glow or smash
glow crystals like that.
Certain chemical substances, which in
crystal form will emit a
bright flash when you break the crystal
or when you wrap two crystals against
each other.
And now if you would have that inside of
your potting material, I think it would
be really hard to like in some
way if the potting material is like
chemically resistant in some way, like
remove the potting material without
exerting mechanical force on these
crystals, which would cause them to
flash. And you could detect that before
to dilute and wipe all.
Um, yeah.
So these are like just ideas,
what you could do in order to make this
security model, like at least moderately
resistant against an attacker.
I mean, they are not bulletproof, like
any helpful security module
out that can be breached with sufficient
resources. But the thing is, from all
I've seen, this would probably already be
like more than that,
at least like most
commercially available hardware security
modules provide.
I know some military stuff then like
detonate the device.
But yeah, we kind of don't want to do
that. I think
so. Now, I like praise, like
this new idea for a device I have,
which I want to put into a laptop.
Now, one thing we need to consider
that is like
you are adding a and additional
piece of like complex piece of circuitry
inside a thing
in order to, in the end, reduce
attack surface. So like what
attack surface does this device itself
provides?
So, like, this is not an exhaustive
list, but is like things that I think
are probably pretty critical,
like one is.
You need some kind of protocol decoding
that thing, you need to, like find this
head and the in-flight display signal,
you need to like pass GPG payloads,
you need to
do some state handling on top of that.
So
that would definitely be a complex part.
And there is some potential there to like
construct Inverloch payloads, which may
affect the state of the system and on
some unintended way.
Now, the countermeasure I would propose
for that is a keeping it as simple as
possible.
The nice thing is sensors in hardware,
we can kind of do that.
We don't need to, like, configure Emilian
registers in order to make some
some some like video input, call
on some system on chip.
We can just exactly put into
this piece of like fabric
what we need and nothing more.
And also we have like some
of that protocol handling running in like
not really running, but implementing
physical hardware circuits.
And these are generally like you can't
really, like, fuzz around with the state
there, but you can probably not,
or it will probably be harder than on a
CPU to actually persistently
modify the state in any useful way for
an attacker.
That's the social engineering rechter
now. Yeah, the thing is,
this would definitely be targeted as
at like
Fredi, capable people like not
really like not really
average users, so
like people like you. So I guess in the
end, social engineering will probably
not be a terribly,
terribly large,
important attack scenario since
my experience like.
People like sufficiently
knowledgeable about computers,
somewhat decree's, and they're
they're there
in like they're being susceptible to
social engineering attacks.
Compromise is obviously an issue
like what happens if somebody can,
like, open the security module without
admitting noticing?
Yeah, well, the thing is,
um, I think we can not
eliminate that, but we can at least make
it a little harder with this limited
security model stuff.
Um, I put in effigy back on
up there because it was kind of like a
like highly published topic,
at least in, like, security research
there. Now, the thing is, I don't think a
pacto back to in this instance
is super realistic because I
think it would be really hard to make
something into an FPGA that
will actually provide any useful
like compromise in that scenario.
Um, logic, flaws.
Well, obviously, you can have like logic
flaws within the device.
So I think
we can do some stuff against that.
So, um,
the the thing is that since
we we are implementing
our own hardware there, we can do some
more countermeasures than you can
do purely in software.
We can't, for example, have the code
in a physically read only memory.
So it cannot be modified no matter what.
We can have, uh, like
independence memories for different
things, like memory, for a memory, for
heve memory, for codes and like have lots
of arrows. If you try to do accessors
across state boundaries, um,
we can do some, we can do some
like primitive separation of tasks
into different use like crypto and
application and rendering is I think like
three major areas I can think of.
We can do some hardware level access
enforcements on places where
we need to share resources.
For example, in the FPGA
implementation, we will probably have a
common dirham external for
all the pixel data.
And we but we can like
securely separate that by like
hardware level access
enforcement. So like the different
components cannot write into their
respective address spaces.
Um, we can generally keep it
simple. So if it's like too
complex, it will, I think, really hard
to keep it secure.
Um, but if we keep this
super, super simple, at least compared
to a full blown platform,
I think we can actually keep the attack
surface within the manageable area
and actually all the thing to a
meaningful extent.
Um.
Like, one thing I would like to note here
is that, for example, for the CPU's, one
thing that would really lend itself to it
would be the risk we project, which are
who are currently actively working on
a basically entirely
open source CPU that is pretty
well specified, pretty well tested,
like they are even some efforts to
actually prove it, that it works
like logic, logically proof the
functioning of it.
And that's also some work on, for
example, tact, memory and other like
hardware level security mechanisms.
They have like
another thing I would like to point out
is that since all of these parts
of this system are operating
at a very low level, we
can just reset everything really
frequently.
It's not bulletproof, but it can at least
make attackers life lives harder,
because if we, like, reset the entire
state of the system like everything but
the actual keys, every frame
or something or every time a new payload
is received, it will be much
harder for an attacker to actually
compromise the state and bring it to any
to any new state that is useful
to the attacker.
It will not prevent anything, but it will
at least like make the practical
exploitation harder now.
Considering this attack surface, like
what would be practical scenarios
with this device and a laptop
and with the same laptop without
that device.
So I just wrote down a couple of those
little made like little colorful
tick marks on how it would perform.
Obviously, this is not absolute.
It like depends on the implementation and
on the how you are particularly using
it.
But I think as a general guidance,
this should perform quite well.
So like in the last device case, for
example, if you don't have
this kind of interceptor inside the
device, you
can already get pretty secure
solutions.
If you are using secure but correctly, if
you are encrypting a hard disk, if you
are soaring your keys
in some kind of secure memory
and so on.
But it depends on the implementation.
And like with this intercept device, I
think it will be a little easier
to actually make sure that if you lose
the device, you like
the idea that neither
the keys themselves nor any plaintext
can leak the device.
Now, second scenario is like unlock
device stolen. So somebody comes and
takes your laptop away while you're
working at it and you don't have time
to lock the screen.
Now, the thing is, fundamentally,
you will have the same problem if you
kind of unlock this intercept
device over a period of time.
But the thing is that since you only need
this interceptor device in order to
decrypt and encrypt MS and you don't do
that all the time, you can have it
blocked most of the time that your screen
is unlocked.
Also, some since this intercepted
device like Hotfoot, we are building
ourselves, we can
include additional security features that
are not offered in Off-The-Shelf laptops,
for example, we could have like some
capacitive sensor in the Palmeiras
that is detecting when, like, your hands
are removed from it. And that will just
wipe the keys in that case.
And then you need to reenter your
password. That would be too annoying for
something that would lock the screen.
But like for Weiping,
like a clearing, a
hearing, for example, that might be
a adequate like a tradeoff.
Now, target to attack what
I described as a targeted attack
is basically somebody with a
lot of money really doesn't like
you. So, for example, somebody
specifically wants your email
now, Vodoun Interceptive,
you really have a problem, because even
if you are using locutions and you
encrypting everything with GPG, in the
end you have a off the shelf
Linux operating system with X and
hypervisor running on a
platform with lots of proprietary
firmware and many places that are
handling
plaintext data.
And also this system,
the entire stack is so complex
that I think it's practically
guaranteed for every part of it that
there will be flaws.
And we see that all the time.
For example, Apple's iPhone has a really
good security architecture, but it's
still pretty complex and people
are getting around us.
Also fix the X and hypervisor, which is
on Hueso s, which is the primary
isolation feature there.
That thing is also highly regarded.
Still, there have been flaws found in it
because it is a huge, complex thing.
And I think we can lower
that attack surface by
basically concentrating it on this
interceptive device, which really
only prevents very simple interfaces
to the outside world, which I think we
might be using,
which I think might be easier to
actually audit.
Now, an obvious failsafe
scenario for like both things like
a laptop with or without this device
would be like you are blocked.
So like somebody places a camera behind
you and your flat, your apartment or
something, because like
since you need plaintext data
coming out of your screen at your eyes,
since we don't have krypto glasses.
Like anybody in the same room will be
able to kind of foom that, like even if
you're using like one of these privacy
filter things, like at
the right angle, people will be able to
read it. So in that scenario,
obviously, any mechanism
that still uses a display will fail.
Um.
You may like you some kind of Snowden
cloak or something, but, yeah,
I think that would be really hard
physical access.
So like somebody has temporary
physical access to your device, like
during shipping or at the border
checkpoint.
In that case, I think it depends
on any in any instance, because
without intercept, well, maybe they can,
like, install a rootkit exchange.
It would flash or something
with the intercept.
Well, maybe they can place an interceptor
in front of the interceptor or something,
you know, like there's really nothing you
can do that if you you don't even know
whether you getting the same laptop back
or whether it's like a I
don't know, some simple device, which
is just like which includes
like monitoring for CPU and, uh,
for keyboard and display.
So I think in that in that case,
like, we can make it a little bit harder
by having, like, these sort of security
modules, features to like detect
when the case is open so we can
provide some incentive against, like
opening the case and messing around in
the system there.
But it won't be bulletproof, um,
like total communications surveillance
as it is happening in practice.
I guess that's
that's like any
system is pretty secure.
And the way that we are leaking metadata,
we are leaking metadata is really hard to
avoid that.
The difference is with the intercept.
You're also just leaking metadata instead
of plain text to your operating system.
But that might not be like
for communications. So that's irrelevant.
Now, what needs to be considered, of
course, is that by placing an additional
device in your laptop, you are actually
from a whole system point of view.
You are increasing attack surface.
And if that device
like this interceptor would be
compromised, that would be totally game
over because it has access to your two
most privileged things and the laptop
like the display output and the keyboard
input.
Um, so basically any secrets
you communicate to your computer are
there on these busses.
So I think
that we need to be really careful
implementing this in order to not make
this an actual security,
a security
threat instead of a security feature.
Major tasks I have,
like I think we have we
need to solve in order to actually make
this practical are basically
disassembling and reassembling this, I
might add, this report and stuff, because
as it turns out, it's not easy
if you have some expertize.
And that's I'm really interested in
feedback and suggestions there.
I think rendering Unicode will be hard.
I mean, we want to we want people to
actually be able to communicate in any
number of languages with this device and
actually supporting Unicode font
rendering on a embedded thing.
And that in a secure way.
I don't think that be trivial.
Then we need to define this packet's
payload format in a secure way.
So like it cannot doesn't provide too
much complexity.
We need to get the keyboard passed
through semantics. Right.
So don't accidentally input sensitive
data into your host machine
without you really noticing it.
We need to split like this and do this
entire process.
Separation like cryptochrome process was
application for processing in some sense
of a way that we actually gain something
by it and we don't have
like a huge amount of code running in
the process of, for example.
And I think the if he if
we want to implement this with the smart
card as a Keystart like long term
storage, it will probably
also be hard to get that
right, because
I don't think as a private citizen,
you can just go out there, buy a smart
card software development kit
and write your own as a
force for forty nine to six
like geeky handling
on the smart card.
So we need we may need to figure
something out that if we want to do that
now, I don't know.
I hope I could actually
like I could make
you interested in that idea if you have
like any feedback, any suggestions,
any ideas
or like some expertize, even in
the relevant fields.
I'm really interested in feedback
and help
with this.
I'm reachable like that email address.
The key is below.
And this talk like the slides
will be on the GitHub repository
up there. So you can also
just give feedback as by raising
an issue that if you have something,
um, thank you for listening.
Everybody that who I haven't
bought to heart you, I think
we can do a question and answer session
now.
Yeah, thank you very much.
That was enlightening.
That takes us to the Q&A.
There are two microphones
set up here. Please form an orderly
queue.
I'll try to
make sure that I realize who's
first. And we would just
wait for the people filing out for a
second, I think, because
we we got enough time, don't we?
I think so.
Great.
Ten minutes.
Q&A answer, I think, will pick me.
OK, we started that,
Mike, and then ping pong to
the room.
Yeah, so as far as I
understand, the idea of the interceptor
on the keyboard side is that plaintext
goes in, ciphertext comes out.
Yes. All right.
So I would like to edit all of my emails
in Emacs or vem with
all of the fancy packages on line.
Obviously, we will need to compromise
like some amount of usability there,
except if you want like a full imex
instance running in that intercept.
I mean, technically it's possible.
Yeah, you can like in these refugees
who can actually make the development
system and using you can actually run a
full Linux in there.
But I don't think you would want that
because it would pose like some attack,
as I think.
Yeah, but generally the benefits
of having your applications in software
rather than hardware is that you can
update them. Also, new crypto protocols,
better encodings than UTF eight.
All of that is lost in your design.
Yes.
Or could you maybe
make the monitors a little louder?
I can barely understand them.
So I repeat,
shall I repeat the question or you got
to, like, update ability of the phone?
Yeah, yeah.
I mean, the thing is, you can like
if it is implemented in the FPGA, not
in an ASIC, you can actually
easily update it. I think it is
very sensible to make it as hard
as possible to actually do that in
practice. Like you need to open the
hardware security module and like flip
some switch or place a jumper or
something as to make it impossible
to do that via a software only
attack, for example.
And like, if you do that.
Well, yeah, you could update us.
OK, yeah.
OK, how do you actually know that what
you're seeing is coming from the
interceptor and how do we know that when
you're typing it's actually being
intercepted and not going to the
hardware?
That question. So
I don't actually know that what I'm
seeing. Oh, OK.
Well, it depends. Like, I cannot
absolutely know it because somebody could
have placed like an interceptor between
me and the interceptor.
Now, just like I
think the other way to talk about it is
like what I
want to have is I don't want a
application on my operating system being
able to spoof intercept output.
I think one way to make that is
to have the
urge to have a
like the easiest way to implement that in
practice would be to have just the
intercept always and full screen
and use one of the physical LEDs
on the keyboard of a pat
in order to like, signify
where the input and output is going
is coming from and going in to the
interceptor or from the underlying
device. So you have like the you could
repurpose them, you'd make muite led of
immutability for that.
Other possibilities would be like for the
output case to like draw a border around
the screen. And if it's red means like
Linux talking, if it's green, it means
like interceptive talking for the input.
Basically the same thing.
You could have some like visual
clue.
I think the input case will be pretty
like in order to get that right
would be pretty hard because we don't
want you to accidentally input a
password. And if you input
a password often you don't necessarily
care that much about the screen.
Why? Look why you were typing it.
So I think a visual clue might
even be not enough in that case.
Well, I guess we finally found a good
use for the think bondage button.
Well, except that one can be controlled
from the CPU.
Yeah, somebody mapped it to Newt Newt on
whether they did the
signal.
The Internet is talking to us.
Yeah. So the first question is, would
the interceptor work in a way cavium
does? So instead of adding a chip to the
main board, you put a box next to the
computer to which you plug the keyboard
and the display and the box just presents
the encrypted input to the computer.
Definitely like in a desktop use case.
That would definitely be how I would
implement it in the laptop use
case. Obviously, it's tempting to
actually include it in inside the
actual case
for some extra 30.
We could just replace the hard
disk with a smaller SSD and use the
free space there
because it's already quite close to
display and keyboard connections.
OK, I really like
I really like the creative idea, but
I was wondering how you feel about I
mean, you touched upon the
open the risk
C.P.U implementation that we
not open risk, so risk
the risk fee.
OK, I'm not sure.
But the university in England, where
they are doing research on an open
architecture and if
you go into towards that
direction, wouldn't how do you feel about
having a system on its own
that you can trust instead of having
an implementation in a regular
machine?
I think that would be really interesting.
Like the that that is one of the more
interesting points of actually
doing this. I mean, the thing is, we can
still you can still use, like all the
amenities of your operating system with
like Compiz wobbly windows
and like windows
hourglass depending on the operating
system.
But you also get like this trust
it, the trust aspect from
the C.P.U implemented in the FPGA.
So like for a start,
I would definitely keep the firmware
running inside. It's as simple as
possible
in order to avoid like making the crash
and like avoid like adding a khattak
surface there. But yeah, of course, like
long term, you might want to add
more functionality into it with
sufficient isolation.
Of course.
Thank you.
OK, the Internet is at
it again.
Just a short question.
What about USB keyboards?
Yeah, well, it depends.
Like if you have some means of plugging
that into the intercept on an issue like
USB is still simple enough
that you could implement it with some
effort on an FPGA like both hosts
and device parts
in the laptop use case.
I don't think it will be that easy
because you would need to intercept like
all the USB ports.
I understand that the whole point of a
device like this is
to bring about something like
the Krypto goggles you mentioned at the
beginning, but in a more limited
fashion.
However, it does seem like there's
opportunity for the
solution that you've proposed to have
integration points for operating systems
like Genard and Cupolas and so on and
so forth.
Is do you think that there's another
angle, this a different thing that you
can isolate, or is this the
only way in which it can be done?
And if it's this is the only way which
can be done to the things that you
propose that should be done?
Are there any integration points for
operating systems like that?
I mean, I don't think this is the only
way you could do something like this.
For example, you could also like for a
much like from a implementation point
of view, much simpler architecture.
You could just have a device packed into
your USB port, which has a display and a
keyboard like separate to
your regular displaying keyboard.
Like the only difference would be it
would be a little less convenient to use.
So I think there will be there are other
many other ways.
It I think the intercepting the actual
display data thing is kind of interesting
because it's pretty portable across
platforms.
As for integration points for like the
operating system, especially something
like Huff's, I think there's a lot of
potential. I mean, I would I didn't
think about that much yet because think
about like A.I.M.
made being integrated with the system
that you're talking about.
You made for a pretty resistant
system that cannot be spoofed.
Yeah. I mean, you could also, for
example, you could even like in case of
cubes, you could integrate that.
Some of that. I think you could actually
integrate into the display manager in
order to have like both Qs and the
interceptor cooperating.
So like Cubes knows what the interceptor
is doing and can actually, for example,
you could maybe handle the inputting
your password into the wrong
device. The thing
there, OK, whatever.
That was my screensaver.
OK, there's another one from the
Internet.
Yeah, what about ciphertext that
are longer than would then what would
fit?
Almost nice Christian like the same thing
goes, by the way, for plaintext that is
longer than what fits on the screen.
Like, I didn't touch upon that too much.
But basically what it would do is you
would spread across different frames
since the like the actual pixel
bandwidth, the bandwidth for pixel data
on a like even on a low resolution
display, like the display of that laptop
is like already in the gigabit per second
range. So no matter
how long your emails are or what amount
of ciphertext you are outputting there,
you will be able to stuff
it into consecutive frames.
You will have some processing limitations
on the FPGA because it's like trolly
clock pretty slowly and you will
have some like memory limitations also.
But like, I think for a general system
at the cost of a slightly higher
complexity of the protocol handling in
the intercept, this can be solved.
And for the outputs case, like you just
scroll, you just need to wire like
the up and down arrows, all a screen up
and screen down keys to like
the renderer or something.
Thank you.
OK, so your
main argument was that your system
is less complex and therefore less
attackable, but then I wonder why
you make the effort
of intercepting your traffic?
Like from my experience,
I guess about 90 percent of
the complexity of that system will
be on intercepting the display
data. So if you want to have something
plain and simple and with a
low attack surface,
why you don't use is just a standard four
times 20 LCD display
and just intercepted
the keyboard line.
And this would be doable and like
one or two days and you could even
let it run on SDM thirty two point
FPGA.
But that would be boring.
No, seriously, I think the
V.V. like doing the life interception
of display data has a serious usability
advantage in that you can
like in my laptop use case
I have this laptop looks exactly
the same as before, except for
providing me this high assurance for like
certain operations, like
with any kind of external device.
I would need to carry that around, need
to have it, and then like use two
different keyboards and two different
displays of different things.
And like
I think for serious email reading, at
some point you would want, like a serious
display on that thing and on that
at that point, it gets just as
complicated. Also
the like
considering the development time.
Yes, intercepting leads and embeddedness
report is a lot of work, but that's not
because it's super complex, but because
it needs to be tuned. Pretty.
Pretty, exactly.
Because you need to take care of a lot of
details there, like face alignment
and stuff like that.
OK, thanks, next question.
How exactly do you think
there's going to be something
on the CPU sending your
text away or whatever, doing
with it?
And if there would be something like
that, why do you think it would
pass something like Wireshark
listening on the network?
I mean, if you have, like a some kind of
spyware running on your operating system,
intercepting, for example,
all encrypted emails before encryption,
you might not actually be able to discern
that on why even using
Wireshark, if the if
that spyware is any good, like if it's
any good, it would probably be using like
some steganography techniques in order to
hide its own traffic inside
your usual traffic
so you can't easily detect it.
OK, thank you.
OK, OK, so I understood
your proposal for writing email.
And with that, so if
you're hitting on a key, it's
doing something and it encrypting
it and putting it into a buffer for
the operating system to pick it up, to
place it in the application buffer.
Right. So if
if that is correct,
what kind of encryption do you plan to do
on the actual keep pressing?
So if it's your own
publicly, how do you.
How do you actually send an encrypted
email to somebody else with their
public key
that highly depends on the
implementation?
Like my first approach would
be to try to extend
an email. So the if
you open an email, you're typing like the
recipient and plaintext because that is
metadata anyway.
And then in email will use
like the same payload format in order
to provide the public key of the
recipient.
Ideally, with the signature of your own
private key to the interceptor,
so that thing can actually then display
the V.V.,
the key, like the kid of the recipient
asked, validated by your own signature
with the key that it's private
with the with the private key that
is only contained within the interceptor.
It's a little awkward, but I
suppose it can be done.
Another way would be to do the entire key
management in the interceptor.
So you kind of press a key combination
and a menu pops up and you then like
choose the recipient's email address
by typing in their.
OK, we got one more question.
Not really a question, just like I
think you have found a
good use case for the
dodgeball,
but it's good for Newt.
Newt to
one more serious question.
Right.
I missed the beginning of the talk.
So is this already, like, ready?
Do you have a prototype ready?
I wish I guess at this
point I have two small Raspberry
Pi zeros in my laptop and I'm able to
close it perfectly.
And so this is what I'm trying to do
exactly what you're doing.
But I'm planning on having one control
or control of the keyboard and then want
to control the network so I can separate
those out.
So have you thought about, you know,
maybe something like that?
Yeah. I mean, the thing is, I would like
to avoid, like, arms talks like Sussman
or Chips, because all of them, like
Broadcom, Qualcomm, Texas Instruments,
I've seen some of the insides of them.
And it's not pretty like it's super
complex. And I don't think they're any
easier to secure than the Linux.
You are running like Qualcomm, for
example, making arms talks, just had
like several serious breaches
of their hypervisor and trust
and security in the last months.
So I think we can basically rule out
like any modern arms.
OK, well,
thanks, everybody.