- Bonjour, my name is Elie Bursztein,
and today, with the help of Jean-Michel and Remi,
we're going to tell you about
how we went about attacking encrypted USB keys.
So we recently ran a survey and asked people
who have a USB key where they store corporate data
did you ever lost one of them
or is one of them was stolen.
And we had 13 percent of the survey respondents
said yes, I lost one of those.
So that means that one way or another,
someone will get a hand of your data
through an encrypted USB key.
So that begs the question,
if I'm using an encrypted key,
is my data safe, can I sleep at night?
Or do I have a leak on my hand?
Well, to answer this question we need to know
are these encrypted USB key truly secure?
And the best way to do that,
hey we had to secretly confirm this to audit them ourself
because we couldn't find online any good methodology
or correct evaluation of the security of those.
So, today in the real spirit of Black Hat,
we're going to show you real attack against real keys
that we found doing our audit and we want to share with you
the journey where we did audit the key for our own purposes
because we feel it's useful for the community as a whole.
We also would like your help
into making some of the attack working
because some of them who are going very very deep
into the hardware require a lot of work
and a lot of understanding that we don't necessarily have
and we would love to get more people who know this stuff
to help us out so we can all have a very nice methodology.
So we'll show you the attack we have,
we'll show you where we are, and hopefully at the end
you will be inspired to work with us and all of us can have
a better stronger methodology for those encrypted keys
that we give to all our user to protect our corporate data.
Sounds good?
Yes?
- [Audience] Yes.
- Thank you, okay, so to be clear,
we have the key here, as
after the talk come and we can show you
how many of them we broke,
we broke the selection of those
we'll show you a few demo as well,
we have even live attacks hopefully at the end.
So let's get started by quickly recapping
you should, you should sit, guys, (chuckles).
Sorry (laughs). (audience laughing)
Alright, we're going to start with talking to you
about how a encrypted USB key looks like from inside.
Okay, so this is the diagram of it
so you have obviously a USB plug
and the PCB where your electronic component are,
then you have something which we call the controller,
which is usually a microprocessor
which is also in charge of doing
the cryptographic operation,
and ensuring that your key stays secure
and of course you have the storage
where you store all your data,
but the extra price tag come from those keys
is obviously the controller
which contains the crypto-end stuff of, right,
and then you have some sort of input mechanism
who the controller takes input from
to know that you have the right password,
might be a fingerprint, might be a PIN code,
might be a software, might be RFID tag.
Either way the controller is the one
who is a gatekeeper of your data.
So, here is a real one,
same thing, right?
You have the controller in the middle
and then you have the storage on the right side,
exactly what I described to you.
We also see some keys which are
more compact and where they actually
backed the controller and the storage into the same system
sorry, silicon, sorry,
so it's harder for us to analyze
because we can't obviously get out the chips
out of the hardware key, otherwise,
the thing on the right side is the fingerprint reader
where you can put your thumb and then unlock the key.
Alright so the first question to answer is,
why the hell are we doing a audit methodology
for a security key, we have the NIST, right?
And the NIST have certification for
USB key, so why
we doing something which already exists and is working?
Well, let me tell you about the NIST methodology
so you can see it for yourself.
There is two certification, the first one is the FIPS 140,
which is supposed to verify
how cryptographic operation are done.
It's a disclosure process by every vendor
which is certified and is going to be validated by the NIST.
There's another one, which is the FIPS 197,
but basically it say I'm using AES
so we're not going to talk about this one.
So FIPS 140, well, to explain why we want something better
or actually more comprehensive, to be clear,
is because they only interested into
the cryptographic operation that the key is doing.
Everything from manufacturing to security of the PIN input,
or everything like that is not covered by certification
so there is enough room as we will see for attack
which are not covered by certifications,
that's why we would like and are advocating
for a certification which is more comprehensive.
We have another way to explain that,
sorry, before that,
and we also found, we did review this document very slowly,
we spent tons of time looking into every certification
and look at this,
here's an example of the certifications for the IRONKEY,
and what is for a little bit concerning
for us is as you can see, it's for the IRONKEY except
the documents say, well, it's for the datatraveler D4000
so somehow someway the NIST validation process failed here
and they actually have a document
which have a lot of copy paste,
and so we're not even sure the document is correct,
and again this is very hard to verify
because it is baked into the silicon,
so we would like to have a little bit more
thorough verification when document is submitted.
Another way for us to summarize what a NIST is for us
when we looked at is this.
Basically if you trust your security to NIST,
you are missing a lot of things,
we would like to cover them today.
So, we come up with a new methodology,
and we're going to walk through to the basic,
and then we'll go through a few attacks
which illustrate our point.
So what was the first thing we did is we separated
the attackers into three categories.
The first one we called the serendipitous attacker,
is the opportunistic attacker which has minimal resources,
that's someone who finds a key on the ground
or someone who grab the key from a desk
and have no prior knowledge, or is not very resourceful
and will try to plug it and try to do something.
Probably the most common type of attacker.
The second type of attacker are professional,
these are for hire or for mercenary company who tries to go
and have in-depth knowledge of how encrypted key works
and if there is an attack they will know how to carry it.
Last but not least, we have what we call
state sponsored attacker which is a fancy word to say
someone who really is after specific data
which might be on the encrypted key,
whether it's like a specific set of cryptographic key
or specific document or backup data,
and they will make a large investment to break a single key.
And the difference between the professional
and the state sponsored is that state sponsored
is more interested into breaking one specific key,
whereas a professional will be more interested
in breaking as many key as possible, right,
so two different mindset.
We also have three type of impact,
the first one is weakening the security,
which is basically, it's not the flaw by itself,
but it actually make our job easier as an attacker,
the second one is a single drive break,
so basically the attacker usually break one key
and recover some of the data which is in one specific key,
and the last one is what we call a full break
which is that there is a logical flow inside the key
and you can recover the data from every key
which has the same model and has the same making.
So
what do we want to cover during the audit?
There are five categories that we would like to cover,
because we believe those five encompass
most of the attacks you can carry out.
Those five are manufacturing, secure manufacturing,
how you manufacture your key
so that it's actually more resilient to attack.
Second is input security, how do you make sure
that the input part of the key is actually safe?
Third is controller security because obviously
you don't want the controller to spill your secret
and probably destroy the key,
third is as, fourth, sorry,
is as it is an cryptographic operation,
make sure that you use correct crypto,
and last but not least, you want to verify storage,
where you would want to make sure that
the data is really encrypted on the storage device,
on the chips itself.
Alright, so we're going now to go through
each of those five in turn and show you a bunch of attacks,
and Jean-Michel will start with talking about
defensive manufacturing.
- Thanks, Elie.
So for the manufacturing, the goals we had in mind
during the investigation and the audit
was that it's the first layer of protection you will get,
because it will mitigate hardware attacks,
it will slow down the analysis by hiding the components,
and preventing people from tampering with the key.
But it's also the last layer of protection,
because that's also what will protect your key
against very advanced attacks such as
electromagnetic radiation measurements
with TEMPEST-like attacks.
During the audit, we discovered some keys
which were providing some copper shielding,
and this copper foil was actually connected to the ground
of the USB stick, making the protection effective.
Some of the keys were also using
some epoxy, like this one,
which basically prevents you from reading
what components they are using,
and it's quite tedious
to remove that layer of epoxy.
We also saw some other keys during the audit
like this one,
and the coating didn't look like real epoxy,
so I started using a piece of rag with some acetone
rubbing into it,
and the piece of rag was turning into black,
so it seems to be efficient,
so it was keeping the key
into a bath of acetone over the night
and I ended up having a very clean
USB stick at the end (chuckles).
(audience laughing)
So be careful to use real epoxy.
And on this one, this key was actually certified
by the NIST, and on the documentation
there were actually stated that it was coated in epoxy
which means that the NIST validation process
was failing at seeing it was not real epoxy
or validating that it was real epoxy.
Another layer of protection is laser etching
the references of the components,
even if it means security through obscurity,
it's really hard to find the data sheets
of the USB controller that I used there,
except when they leak, so if you don't have the reference,
it will be very hard to identify
which components they are actually using.
It's hard to see on the picture,
but it's not just black marker,
it's really milled, so the reference is not there anymore.
But that's an extra cost at the manufacturing pipeline
so you have to be sure that you use the right service,
because here they paid the extra for nothing,
because we can still see references of the component.
Another thing that you have to pay attention
at manufacturing, is about the debug ports
they use to test the USB key at the manufacturing level
or during the development process,
and on this one on the far right side,
you can see some pins, some small solder pads
that are there and labeled which are actually used
as a debug port, and you will see later on
an attack leveraging those.
So this is how we summarized for each category
the different control points that we have
they are ordered by the level required for the attacker,
and then also by the impact
that it means.
And now I will let Rémi talk to you
about the input mechanism.
- Thanks, Jean-Michel, my name is Rémi,
I'm a software engineer at Google,
and I'll tell you about the security
of the input mechanism of the keys.
We identified two main components
the first one is that only valid users
are able to unlock the key and have access to the data,
and the second one is that we should then be able
to add new user to the key.
During the audit, we had multiple kind of input mechanism
on the key we selected.
The first one is the pinpad, where you enter a number
and then you unlock the key, you get access to the data.
The second is using a badge.
You swipe the badge and, it unlocks this hard drive.
Then we have the fingerprint reader,
same thing, you put your finger on the fingerprint sensor,
and it unlocks the drive.
And last is software based.
So, you plug the key and you have a first partition
that pops up that gives you a software in which
you can enter a password and when you type enter,
it will unlock the key if you gave the right password.
Let me tell you about the first attack we found
during the audit.
It targets a fingerprint-based key,
in which we can replay an unlock command.
The impact of this attack is a full break,
meaning we can actually recover the data
of all the key of this model.
And we rate this attack as doable
by the professional as it require a few tools.
This kind of attack is not new, and actually in 2010,
another model of key was found vulnerable,
where you could recover the data,
without knowing the password.
Here is the new model.
So fingerprint-based, you swipe the finger,
you unlock the key.
When you open the shell, you get this PCB.
On the left you have the USB controller,
then on the right you've got the fingerprint sensor,
and on the far right, you see silkscreen and pins
with the label of a debug port.
So you've got USB, you've got clock,
and you also got RXD and TXD,
which are the serial line.
So we mapped the PCB and here is
the logic diagram of the key.
So the sensor is connected to a fingerprint manager,
the fingerprint manager reads your fingerprint,
this fingerprint manager is controlled by the USB controller
over the serial line, and it's the USB controller
that's responsible for unlocking
the storage and decrypting it.
You can see we found a design flaw
in the serial line, because it was not protected
and we were able to read what was
sent over the serial line.
Here is a picture of the attack.
We started by pulling the key on our computer,
soldering some wire on the debug pins,
and then wired that to a serial port here, Bus pirate,
and we conducted the attack
by simply using the key normally,
and using the Bus pirate, we read what was going on
on the serial line when we swiped our enrolled finger,
and what we saw was a static command
saying which was the number we swiped,
just number, like finger number, zero.
Then we unplugged the key, plugged it back again,
and using the buspirate to write the exact same command
we saw the first time, and it will unlock the key.
Let me show you a small video of the attack.
So on the laptop on the left you see the actual
command that you have to send over a UART,
pluging in the key, little light, wiring the buspirate,
on the right you've got the Windows laptop,
I sent the command and you see the partition got
open on the Windows with access
to all the data without using the fingerprint.
During the audit, we found another attack
which was that the input tag
of the USB harddrive could be cloned
and the impact of this attack is only a single drive
because you clone the tag of the drive you want to attack.
And as it also requires some tools,
we rate the attacker as professional.
Here is the vulnerable model along with the tag
that you have to swipe to unlock the drive.
When you open the drive, you have this PCB
with the SATA port that's used to connect
to the actual hard drive that would be encrypted
the RFID coil used to read the tag
with its little controller and the configuration
and to conduct the attack, you need an RFID research tool,
here it's a Proxmark, and a reprogrammable RFID tag
to be used to clone the tag.
Here is a video of the attack.
Here is the open USB drive
red light mean it's locked,
and we will use the real tag.
Green light, it's unlocked.
Using the RFID research tool,
we read the content of the tag and write the content
back into the reprogrammable tag.
As you can see, pretty fast.
And then using our custom tag
we swipe it just like the real one,
and you see green light.
The drive is unlocked, we got access to all the data.
Summing up for the input audit criteria,
we found the one in bold are the one we actually found
attacks against and which models are vulnerable
which are the unlock command can be replayed,
and we found an attack where the input could be cloned.
Summing up with the impact,
and the kind of attacker that can conduct the attack.
Moving on, I'll have Elie talk to you
about the security of the controller in USB keys.
- Thank you, Rémi, so,
so the third part we want to cover as Rémi said,
is the controller, which is kind of the brain of the key.
And here we have many goals,
because that's the place where most of the security happen.
The first one is, and that seems obvious,
but you'll see we have some attack against it,
is the controller is supposed to protect your secret,
which means the controller should never leak your password,
or the AES key, that seems obvious,
but somehow, some people fail at it.
Second thing is, you expect the controller to lock the drive
when it's needed, meaning if you unplug the drive,
well, the drive should be locked,
and if you have a glitch on the USB port,
it should lock itself, and so forth and so forth,
so we expect it to do that.
We also expect the drive to destroy secrets,
at least zero out the AES key
so that the drive become unusable
when it's under attack after a few unsuccessful attempt.
You would imagine, again, that is something that is granted.
Turns out it's not.
And last but not least,
and this is more like wishful thinking,
we would like to have firmware attestation,
meaning today there is no guarantee that there is not a way
to have a backdoor firmware, we have no way to attest
that the firmware running to those key is really the one
we can audit, because we have no way
to have firmware attestation,
so we would like in the future to have
a key who are fully attested.
Similar, very, very similar to the secure enclave
that we start to deploy into Intel, right?
We would like to have the same thing for the key
because we can trust that the key's
really operating the firmware we have.
So hopefully that's going to be
in the next generations.
So the way we do some of the
analysis, and this is a little bit
of the behind-the-scene stuff,
is we do a lot of interceptions.
We'll talk about how we do an interception
between the memory and the controller later.
Later on, Jean-Michel will tell you about that,
but we also do interception
between the key and the computer,
and we monitor what happened.
The reason why we do it at the hardware level
is because we really want to make sure
we see everything happening on the USB bus
to make sure we don't miss anything.
It seems a little bit overkill,
but turns out we found a very cool attack
that I'm going to demonstrate to you in a second,
by doing this kind of interception,
and maybe this, to show you what happened in practice,
this is what it looked like.
So we have in this blue box is actually a
is a dedicated hardware which will allow you
to do interception of USB traffic,
full-speed event for the USB three,
which is very difficult due to the timing and the speed,
and it basically have three parts.
One you connect your key,
so that's one of the key we connected to it,
and then the second cable in the front
goes to the target laptop, or, target desktop,
we used a laptop because it's easier to put on the desk
next to our desktop sessions,
and then the cable at the back,
go to our desktop station where we do the recording
and we do the analysis and we use custom software for that.
So that's what our interception platform looked like,
and we've been running it on every key we have audited
to make sure we understand exactly how the communication
between the computer and the key are happening
and making sure everything is square and fair.
Turns out it's not, and it gave me
what is my favorite attack of the talk,
because I think this is the most mind-boggling one,
this is also the one we do feature
and we shared on social media, because we really feel it
showcase how dangerous this thing can be.
So again, it's a fingerprint key, this is one of those,
and we were actually wondering
how many of those were having this problem,
so we bought a few other brand,
which we were believing having the same chipset,
and turns out they're all vulnerable.
So we have this one, and then we have a bunch of others
we have here.
Actually if you would like to see the demo live,
after the talk, please come on here or in the wrap room
and we'll show you live the attack.
Show you how easy it is.
So it's attacking fingerprint keys,
we deem it a full break,
and even a serendipitous attacker know how to do this one,
he know what to look for,
and this is as insane,
as you can recover the master password.
So do you want to see it done live?
- Yes. - Yes?
- Yeah. - Okay.
So the key, unplug it, that look like this,
nothing to see except the fingerprint reader,
nothing to see, right, so you have the fingerprint reader
and the controller, so here's how this goes,
we made this one very nice because that's our demo,
so you have someone on the coffee shop and which is leaving
and the attacker is spotting a key,
so he is going to steal the key, right?
And the key has a fingerprint reader on it,
and so later, when he's back to his lair,
he's going to try to log for the key, and obviously
you can't, right, because the fingerprint reader
do work as intended, so you can't.
And then you're really sad, but, turns out
there is a secret USB command which allow you to recover
the master password, and that's how fast it is.
So all you have to do really is just say oh, I'm an admin,
here's my master password, please do allow my fingerprint,
and then you add a new user, let's call it,
well, I don't know, evil user,
and then you click on next,
and you start to tap in your finger,
and a moment later,
you will have a, your fingerprint enrolled
as a legitimate user into the key.
That's how bad it is.
So any of those key are definitely broken,
because you can extract the password from the controller.
Yeah, I see people shaking their head, yep, that sucks,
I can't imagine how someone designed security project
could do that, but actually they do,
which is why we need to audit all of them and make sure we
verify clearly the spec, even if you think it's obvious,
actually it turns out people still make mistakes,
and we're here to protect our users.
So another one.
You would assume a controller will not,
will you know, lock, after like five or six attempt,
that seems obvious, right, you should not keep doing it.
It turns out that when I do it, we did our audit
of a encrypted hard drive who use RFID badge,
we found out that's not the case,
so we deem it again, a full break,
and a serendipitous attacker can do it,
because that is again very easy to do.
So here's a badge, so you can use them
or use like a proxmark to start to do the brute force.
It turns out they do lock the hard drive after six attempt.
The only problem is when you power off and on,
counter goes back to zero.
So you know, with a simple electronic manipulation,
we turn off the voltage, we turn off the disk,
brute force, and now you can brute force it
as much as you want, and so basically
it's completely useless (sighs).
Anyway.
So, audit criteria, to sum up,
well, the device should burn after nth unsuccessful attempt,
and you should not be able to reset the counter,
obvious, but, well, important,
and the password and AES key
should not be able to be requested from the thing,
we also have other bunch of stuff, like
the AES key needs to be regenerated and so forth,
and those are more technical things.
They will be in the slide
and later on we'll publish a full methodology on GitHub
so you can actually download it
and help us to make it even better.
So moving on to the fourth part which is cryptography,
we don't have much to say, because
of course we know what we want,
we want data to be properly encrypted,
and we want the encryption key to be truly random,
which means you should not use the same key over
many, many device and you want your key to be truly random
and then we can't guess what the key is for a given device.
We did see that for example in Wifi routers
a while back where they were deriving the key
from the MAC address, hopefully no one do that for USB key.
So problem is the cryptography is literally baked
into the silicon which makes the audit
very, very difficult and almost impossible
if you don't have the correct spec,
so we feel that the tests are too expensive
for us to do, so we can skip all of them
and we hope to solve that not by
going ourselves doing the hardware audit
but instead having a better certification process
and having manufacturer disclose more information.
So that being said, we did find a few oddities,
I'm going to just mention a few of those.
People use outdated crypto in certain keys,
we found one key who used RSA-512,
don't do that because you are vulnerable
to a factoring attack, and we also found some key
who are doing file by file encryption who are using RC4.
Of course RC4 is considered broken cipher
so they should use, I don't know, AES, and they don't.
Or they can use any stream cipher like Salsa20
or something like that,
but they still use very outdated crypto.
So we come across a few things where
even by just doing the audit, normal audit,
we found oddities, but for the very hardcore
and in-depth analysis of the crypto,
we believe it should be done at a certification level.
So here's a bunch of recap of what we think should happen,
our encryption key should be unique,
there is no recovery master key, so no backdoor,
and data is encrypted using AES or newer standard,
those would be the three main things,
and then we have a bunch of technical requirements
which we think are useful
to improve the security of the key.
Alright, for the last part,
and which is the most experimental
part of the talk, and you will have no video there,
will be how we attack storage.
So, Jean-Michel will walk you throught that.
- Thanks, so the goal we had in mind for the storage audit
was obviously what you expect from the encrypted USB key,
which means doing a full disk encryption,
but also providing you with some integrated checks,
so that if someone tries to tamper with the data,
it will be detected and prevented.
Extracting the content of the storage chip
appears to be not easy at all.
First you have to do the chip removal,
which means potentially go through the layer of epoxy
until you get access to the component,
then remove the component from the PCB.
Then you have to dump the content of the memory,
because of the way the memory technology,
the flash technology works, you also have some algorithm
to compensate for the read errors that you will have,
and you have to understand that algorithm to recover,
to emulate it and recover the real data.
Then you have to undo XOR scrambling algorithm
that is mainly used by people by manufacturer.
This is not a security feature,
it's just to optimize the lifespan of the flash memory.
Same thing for the next step,
you have to interleave blocks the right way,
it's just for the lifespan of the chip.
Then you have to undo the file translation layer.
If you're familiar with the X86 architecture,
it's like mapping between the physical memory pages
and the virtual memory pages, so you have some area,
some storing some metadata on the flash,
and it will explain to you how to reorder the memory pages
in the right order to get the file system back.
Once this is done, you have to strip away
the metadata you just used,
and finally, you have to decrypt the file system.
Don't worry, we'll go through the steps
with something more visual (chuckles) soon.
We discovered during the audit some
some families of keys which were using the CD-ROM partition
to store the tools to unlock the key for those who are
providing a password-protected USB key.
It's used for convenience,
at least it's a read-only partition
from the operating system point of view,
and it also provides you with the autorun feature
which will prompt you for the password
as soon as you plug the USB key.
So this is the key, one of the key
that was vulnerable to this kind of attack.
We already saw that this is not epoxy,
then you remove the chip.
You put the chip in an end-reader
to be able to extract the content,
and that's basically what you have.
So if you look at that, you may think,
it's properly encrypted, nothing appears in clear,
that's just the effect of the XOR scrambler.
So if you look
at the data turning the bits into pixels,
you start seeing some patterns appearing,
you see some scrambled data,
and you can see the artifact of the XOR scrambler
with the sort of diagonal stripes
that appear on those blocks.
Then you have
some metadata, because they don't change a lot,
and that's what will tell you to reorder the lines
on those pixels.
Then a bunch of bits that are looking like noise,
and that's the ECC correction,
and then you go again on the scrambled data
and over and over.
If you undo the XOR scrambling,
that's what the patterns will look like at the end.
And if you look at the x dump it's even clearer that you
you haven't done successfully the XOR scrambler,
because you can see some clear text.
This is the parameter of the USB stick
which contains some strings some vendor ID
for the USB and stuff like that.
If you go a bit later, once you've undone properly
the file translation layer,
you will see the CD-ROM partition,
and if you continue a bit down on the memory
you will see the P file that allows you
to enter the password and unlock the key,
which means the CD-ROM partition was not encrypted at all.
But how do you backdoor that thing?
Well, remember the graph,
you have to go the other way around,
so you patch the EXE file with,
so that it can leak the password of the user
when you will enter it,
then you have to reapply the XOR scrambler
before computing again the error correction code
and update it
and then you have to rewrite the memory chip,
solder it back, and rewrap the key so it
it looks stealthy.
Sometimes the manufacturer will help you
because no soldering skills needed,
it's just a microSD card on the reader,
so you just have to press it and extract the SD card
and read it with a card reader (chuckles).
But the thing is where are the secrets stored?
It's an encrypted USB key,
most of the USB key will use AES,
and they need this key to be there.
It turns out that we had to build a platform
to be able to look where the AES key could be stored,
and it was a quite difficult task.
So this is the overview of the platform we have.
So after desoldering the chip,
we connected it with individual wires
the USB key with an FPGA, the FPGA will emulate the memory
and will basically act as a proxy
between the researchers workstation,
which contains the data
and we will see that coming through,
we can tamper with the data
and see what happens, and in parallel,
we connect also a logic analyzer
which will just analyze what's happening on the wire
to ensure that our emulator is working properly.
This is a simplified view (laughs) of the platform.
And physically, that looks like that.
So here you have the key
with the memory chip being removed,
connected to custom PCBs that we design
and the FPGA sitting in the middle
to emulate the memory chip,
and on the top you have the logic analyzer
that will give you the view of the lines.
Zooming a bit on the way you have to wire the USB key
to the custom PCB, this is again the USB key,
the custom PCB, which is a breakout board
and those are individual, very thin wires.
And if you look on the USB key, this is what it looks like,
and we had to use some duct tape to release the strength,
the stress from the wires
because it's soldered on very thin pads
and we broke some keys during the audit (laughs).
Here you have the view of the logic analyzer
which will give you the digital channels in gray,
in blue you will have the analog view of the channels,
which happens to be very useful because sometimes
you have some glitch artifact on the line
that will switch on the digital view,
a zero to a one and you don't understand why.
As an overlay, you can have also your protocol
being automatically decoded by the software,
and on the right, you have the measurement panel.
Why were we using the FPGA for that
is because the eMMC protocol appears to be
a high-speed protocol with very strict timings,
and emulating it in software was not possible,
because just a runtime trip between the software emulator
and the USB key was going
away off the tolerance of the timings,
so we had to build it with the FPGA.
And this is the output we have on the system,
you can see all the comments, the fact that the comments
are going from the host to the device,
if the CRC is correct the argument and stuff like that.
So can the AES key be recovered?
Well, that's basically the part that is still
a work in progress, it's very complicated,
and we are looking forward to collaborate on that
to get some more resources on that.
This is the summary of the storage audit criteria,
the most important thing is as we said,
ensure that the data is actually encrypted,
and all the data, including the CD-ROM partition,
and obviously that some secrets
should not be stored in clear in a memory chip.
The takeaways from the talk is that the certification
is very important because that's the only way we can audit
the way the cryptography is implemented on the USB key,
but on another hand, it's not enough,
because it only focuses on the cryptography,
and it misses four other points
that we covered during our methodology.
Another point we discovered is that
not all the manufacturers, and more important,
not all the models from a given manufacturer
are equal regarding the security implementation,
which means that you cannot trust the reputation
of a manufacturer and just look at the package
and pick your key, you have to actually audit the key
you're going to pick for your company.
As the next step, we encourage you to use secured,
encrypted USB key, because at some point
as we saw on the survey at the beginning,
an employee is going to lose
a key containing company data on it.
We also have to ask for more transparency
from the manufacturer so that it's not that hard
to audit those USB keys,
and because such audit is very time-consuming
and requires a lot of effort,
we believe that crowdsourcing the effort
and make it a community effort will be
the best for everyone.
And I think we have time for couple of questions,
so please use the mic.
Thank you.
- Please use the mic. - Oh.
(audience applause)
For more infomation >> Rose Nascimento As 30 Melhores | Melhores músicas Gospel Mais Tocadas 2018 (SELEÇÃO DE OURO 2018) - Duration: 2:08:06. 
For more infomation >> As 20 Melhores Damares 2018 | Melhores Música Gospel 2018 (SELEÇÃO DE OURO 2018) - Duration: 1:52:44. 
No comments:
Post a Comment