YT YouTube2Text

YouTube2Text → Transcripts → YouTube transcript (544rhbcDtc8)

YouTube transcript (544rhbcDtc8) — Transcript

9,616 words · 1,322 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:11great thank you Michelle and uh let's
0:12get started welcome everyone to this
0:14webinar um I I guess I'm going to tell
0:16you about a few things that we've been
0:17working on recently and uh I hope you
0:20enjoy it so let's see so let's get
0:22started um as I said what I wanted to
0:25tell you about today is some some areas
0:28that we've been working in our security
0:30lab lately in particular I wanted to
0:32tell you a little bit about new
0:33developments in password hashing and
0:35then I'll talk a little bit about um
0:37sort of a new approach we developed for
0:39uh securing program control flow This
0:41falls into the area of what's called
0:43control flow integrity and I'll tell you
0:45about a new technique for control flow
0:47Integrity hopefully we'll still have
0:49some more time and then I'll be able to
0:50tell you about uh other recent work that
0:53we've been doing and specifically on iot
0:55security in particular how do we know
0:57that iot devices are not revealing too
1:00much information about their owner so
1:02again kind of an exciting uh area having
1:04to being an intersection of privacy and
1:07security so I hope we I hope we'll get
1:08through all three topics but if not I
1:11guess we will schedule future webinars
1:13and we will cover whatever we didn't
1:15cover today in in a future webinar okay
1:17so with that let's get started with
1:19password hashing and let me remind you a
1:21little bit about how password hashing
1:23works and kind of the areas that we're
1:25uh interested in uh we've been working
1:26on recently so of course everybody knows
1:29you know there are constant attacks on
1:31serers side password databases that
1:34result in large scale password breaches
1:36so I just collected a random sample you
1:38know this is a very small uh sample of
1:41the actual breaches that have happened
1:43in the last couple of years um so just
1:45to remind you you probably you remember
1:47a few years ago LinkedIn lost um a
1:50collection of of uh hashed passwords
1:52that they stored Unfortunately they
1:54simply stored hashes sha one hashes of
1:57their password these were unsalted and
2:00we'll talk about the consequence of that
2:01in just a minute um so that that was one
2:03event that Lo that resulted in a loss of
2:056 million passwords all these people had
2:07to uh go in and uh reset their password
2:10of course when a password breach occurs
2:12um whoever does the breach is able in
2:15many cases to obtain many of the
2:17original unhashed password and those can
2:19then be used to attack those users on
2:21other sites as well because
2:23unfortunately still many users use the
2:25same password at many different sites
2:27and again we'll talk about mitigations
2:29for that in just a minute uh then later
2:31on uh a year later there was there were
2:34a couple other breaches again this is
2:35just a selected list uh so there was a
2:38250,000 passwords were uh stolen from
2:40Twitter Evernote had an issue where hash
2:42passwords were were revealed and Adobe
2:45had an entertaining uh breach where um
2:47in fact encrypted passwords not hash
2:49passwords were revealed um in addition
2:51to the password hints so as a result uh
2:54the password hints actually helped
2:55attackers recover the original password
2:58and then furthermore um just a more
3:00recent example in 20 2015 a famous um a
3:05fairly common password manager was
3:06actually had an issue where in fact
3:09hashed Master passwords and assaults uh
3:12were compromised and again that um canon
3:15in some cases that can enable the what's
3:17called an offline dictionary attack
3:19where an attacker can try lots of words
3:21in the dictionary until he finds one
3:23that hashes to the user's password and
3:25that essentially reveals the user's
3:27password so the question is uh what to
3:29do about about that and so um this was
3:32just a quick uh survey of what's
3:33happening the question is can we how do
3:35we store passwords in a way that make
3:37these offline dictionary attacks harder
3:39than uh simply just trying all words in
3:41a dictionary so let's talk about you
3:44know uh how to store password 101 and so
3:47of course I hope everybody knows that
3:50you ever never ever ever ever store
3:52passwords in the clear on the server
3:55what you actually do on the server is
3:56you store a hash of the password here
3:59you can see the of the password along
4:01with a salt the salt is denoted by sa
4:03and the salt is also stored uh in the
4:05database and then when a when a user um
4:08submits a password uh for login what the
4:10server actually does is it simply hashes
4:13the password along with assault and
4:15checks whether that's equal to the
4:16stored hash in the database and if it is
4:18equal then the login is allowed to go
4:20through so again this is why we use
4:23assault and so on this is uh fairly
4:25common reasoning in computer security we
4:27discussed this actually at quite a bit
4:29of length in the computer security class
4:31uh that we teach uh which again you are
4:33very uh welcome to to to sign up for and
4:36attend uh so I'm not going to talk about
4:37the reason for the salt here what I want
4:39to talk about today is is this question
4:41of what what hash function should be
4:44using um for hashing passwords so how do
4:47we actually hash passwords when we store
4:49them in the password database so what
4:52happened with LinkedIn is Unfortunately
4:54they used a sha one hash of their
4:57password and in fact a sha one hash was
4:59even on soled so literally all they did
5:01is the computer to sha one hash of
5:03everybody's password and that's the
5:05value that was stored in the in the
5:07password database when that password
5:09database was compromised within 6 days
5:11almost all the CL PL text passwords were
5:14exposed so 90% of the passwords were
5:16actually revealed and the reason that
5:18was possible is because sha one is an
5:20extremely hash fast hash function to
5:22evaluate so uh What uh folks were able
5:25to do is run through a large dictionary
5:28um you know very very large set of
5:30dictionary of of possible passwords in a
5:32dictionary and simply try to Hash each
5:34one of them until they got ones that hit
5:37values in the password database and that
5:39enable them to recover the original
5:40passwords so in some sense this is kind
5:42of
5:43counterintuitive into what's happening
5:45in computer science typically we want
5:47things to run fast as fast as possible
5:50when we hash passwords actually speed is
5:52detrimental to security because the
5:54faster the hash function is the faster
5:56an attacker can try uh all words in the
5:59dictionary until he he recovers the
6:01user's password so what we really want
6:03for password hashing is much much much
6:06slower passwords and by the way I should
6:08say that LinkedIn has since updated
6:10their uh password scheme and now this is
6:12this type of attack is not going to
6:14happen again on LinkedIn so that's um at
6:16least we hope and so that's actually
6:18good news and so the question I want to
6:20ask basically is what is the right way
6:22to Hash passwords and so basically there
6:24are kind of two ideas that come to that
6:26come to play uh the first one is is when
6:30we Hash a password on the server side
6:33one thing we might want to do is instead
6:34of just using um a simple hash function
6:37where we directly just give it as input
6:39the user's password we actually use
6:41what's called a key hash function so a
6:43function that in addition to the
6:45password also takes a secret key the
6:47secret key itself is going to be stored
6:49in some Hardware security module what's
6:52called an HSM so the secret key itself
6:54is going to be stored in some secure
6:56environment that attackers will not be
6:58able to extract and as a result um if
7:01they're able to steal the password file
7:03the the password database if they want
7:05to try a lot of words in the in the
7:07dictionary now for every word in the
7:09dictionary they have to interrogate the
7:11HSM in order to recover to check whether
7:14their guess is correct now the HSM might
7:16be rate limited for example the HSM
7:18might only respond to a th requests a
7:20second in which case the attacker is
7:22just going to take too long uh to mount
7:24his attack so definitely using key
7:27hashes on the server where the key
7:29stored an HSM is a is a very strong and
7:32powerful step forward but in many cases
7:34there is no HSM for example when you're
7:37hashing passwords on a laptop or when
7:38you're hashing passwords on on a cell
7:40phone there are actually no hsms
7:42available uh roughly speaking and as a
7:44result we'd like to have something a
7:46mechanism that that is secure even if we
7:48don't have an HSM in addition also hsms
7:51do not provide foolproof security maybe
7:54there is some still way to recover the
7:56secret key from the HSM so in addition
7:59in addition to the HSM we'd like to also
8:02hash the password using what what's
8:04called a slow space hard function okay
8:07so again these are complimentary
8:09mechanisms that work in tandem if you
8:11don't have an HSM you would just use a
8:13slow space hard function uh and that
8:16would um uh you know be kind of an
8:18alternative to using a key hash function
8:20so what I want to talk about is what is
8:22a slow space hard function and which one
8:25should we use and there's been actually
8:26a lot of progress on this recently and
8:28that's what I want to tell you
8:30okay so the first idea um uh dates back
8:34actually to the '90s and the first idea
8:36essentially again very very clever idea
8:38which is to say let's use a slow hash
8:41function so one that actually takes
8:42quite a bit of CPU power to evaluate and
8:45examples of that are functions like
8:47pbkdf2 and bcrypt so pbkdf2 is actually
8:50a standard that folks can use in very
8:53very very very commonly deployed for
8:55example Apple uses p pbkdf2 in many of
8:57their products the way pbk DF two works
9:00is essentially it slows down the hash
9:02function basically by iterating a hash
9:05function over and over and over and over
9:07again right so to evaluate the function
9:09you sort of have to take your your hash
9:11function evaluated on the password
9:13evaluate again on the result evaluate
9:14again on the result of that and iterate
9:16that like say 100,00 times or so um
9:19until the final result is the actual
9:22hash value okay now it turns out pbkdf2
9:24does actually more than just simple
9:26iteration of the hash function that by
9:29itself simply iterating a hash function
9:30is actually not secure you have to do
9:32something more and that's that's what p
9:34pbkdf2 and bcrypt do and so uh all the
9:39basically what that ensures is that when
9:41the CPU is evaluating the hash function
9:43it takes actually quite a while to
9:45evaluate the hash function so now uh in
9:48fact uh when the attacker wants to try
9:50you know billions of words in a
9:52dictionary it's actually going to take
9:53the attacker quite a bit of time to try
9:56all billion words in a dictionary or you
9:58know even however many words there are
10:00he's trying to uh to evaluate until he's
10:03able to get the user's password so the
10:05question is how many iterations uh
10:07should we do that is how slow should the
10:10hash function be and typically um you
10:12know this would be set so that you can
10:13evaluate the hash function on a modern
10:16uh server about a thousand times a
10:17second so that means that the actual
10:20server uh that's doing uh password
10:22authentication at the website would be
10:24able to evaluate the hash function about
10:26a thousand times a second so a single
10:28server can handle about a th000 logins
10:30per second of course if you have higher
10:33uh load on your server you would just
10:34you know you would have to buy more
10:36Hardware deploy more servers to handle
10:38that load but that's typical typical
10:40parameter that uh one would use uh for
10:43determining how many iterations to
10:44actually run unfortunately there's a
10:46problem with that this is not uh quite
10:48secure and the reason the the the the
10:51problematic issue here is that when an
10:53attacker attacks you they're not when
10:55they're running their offline dictionary
10:57attack they're not going to be using
10:59your Hardware they're not going to be
11:00using the hardware that the website is
11:02running instead they're going to be
11:04using custom Hardware to do their attack
11:06so for example they might use gpus to
11:08compute the hash function gpus as you
11:10know are very parallel and you know if a
11:13GPU for example has 100 cores on it it
11:15could actually do 100 evaluations at one
11:18in one step basically evaluate 100 words
11:20in the dictionary in one step and in
11:22fact you can even build commodity
11:24Hardware that's uh using you know as6
11:27and so on where the hash of valuation is
11:30even faster and in fact the attacking
11:32can do his dictionary attack much much
11:34much faster than a th000 evaluations per
11:37second so let me ask you here's a puzzle
11:39for you just so that this is a little
11:40bit interactive let me ask you so if you
11:42had to guess um when we were
11:45specifically building Shu 56 if we um uh
11:48eval if we uh use Shu 56 as our hash
11:50function um how much faster could sh 56
11:54be made to run on a custom piece of
11:57Hardware over running it on just the
11:59standard Intel processor say Intel
12:01Skylake a zon processor so so how much
12:04faster can Asic um be compared to to
12:07standard AIC uh to standard Intel uh
12:11processors yeah so I'll let you answer
12:13this uh this question while you
12:15answering the question uh let me kind of
12:17explain why commodity Hardware is so
12:19much faster than just you know
12:21off-the-shelf Intel processors so here I
12:24have uh an example uh yeah so here I
12:26have a picture of an Intel processor uh
12:29that just took a picture of Skylake
12:31which is the latest uh Intel processor
12:32on the market today you can see here
12:35this is a four core processor so you can
12:36see here the four cores this is one core
12:39uh this is another core and so on and
12:41you can see that there's a lot of other
12:43stuff on this processor for example
12:45there's a lot of cache that's going
12:46that's being used here in fact as you
12:48know there are three layers of caching
12:50there's a memory controller uh and so on
12:52and so forth there are many many many
12:53components on this processor that really
12:56are completely irrelevant and unuseful
12:58when you're trying to evaluate a hash
13:00function like Shot 2 56 so if you think
13:02about it the actual uh piece of the
13:05hardware that evaluates sh 2 56 are
13:09these four little squares here you
13:10notice the squares there's one little
13:12square um in every core and it's just
13:15this tiny amount of hardware on the
13:17processor that's actually being used to
13:19evaluate sh to 56 so it should be very
13:21clear that if all I want to do is just
13:23do a dictionary attack I would never use
13:26an Intel processor off the shelf because
13:29because you know very little hardware
13:31and very little silicon in the processor
13:33is actually used to evaluate shot 56 so
13:37my question to you was how much faster
13:39would uh commodity Hardware be compared
13:42to uh to an Intel processor and let's
13:44see what you guys answered ah so
13:46everybody says about 500,000 times
13:48faster so you guys are very pessimistic
13:49you think commodity Hardware can be made
13:51like super duper faster than uh Intel
13:54processors well so here's what we did um
13:56uh well here's what I did I just looked
13:58up essentially
13:59how long does it take to uh uh to do sh
14:0256 and come out it on custom hardware
14:05and the folks that are interested in
14:06speeding up uh sh 56 is are the folks
14:09that are doing Bitcoin mining and so
14:11Bitcoin miners when you look at the
14:13processors they build there's no there's
14:15no memory controllers there are no
14:16caches on those processors all those
14:18process do processors do is they just
14:21kind of uh flood the the the processor
14:24with just copies of uh the memory
14:26control of the shter 56 engine uh so a
14:29the engine is optimized and and and
14:31second of all it's replicated all over
14:33the processor so you don't have just
14:34have four engines per core you have
14:36thousands of engines per core and you
14:38can see that uh if you just go to Amazon
14:40and buy just a Bitcoin mining uh rig uh
14:42they cost about $1,700 and their price
14:45is constantly falling and you can see
14:47this is on a LW scale uh that um it's
14:50about 50,000 times faster than uh come
14:53out than than just an install processor
14:55so not quite as pessimistic as you guys
14:57were expecting but still still far far
15:00far faster so again if the Intel
15:01processor can do a th000 hashes per
15:04second the attacker using dedicated
15:07Hardware can do 50 million hashes per
15:10second so essentially the uh dictionary
15:13attack is re-enabled because the
15:15attacker can run through large portions
15:17of the dictionary very fast okay so um
15:21simply using a slow hash function
15:23doesn't really prevent the attacker from
15:24doing a dictionary attack because
15:26commodity Hardware is so much faster
15:29than the Intel processor so what do we
15:31do so what do we do so A beautiful idea
15:33actually appeared uh a couple of years
15:35ago this is this idea that's used in
15:37scripts um and this idea is really
15:39elegant so the idea basically says well
15:41let's use a hash function that isn't
15:43just slow that isn't just hard to
15:45evaluate but also takes a lot of memory
15:48to evaluate as you're Computing the hash
15:50function so now if you think about what
15:52the custom Hardware has to do it can't
15:54just use a little piece of silicon to
15:56compute the hash function it has to use
15:59the little piece of silicon but right
16:00next to it it has to allocate a large
16:03buffer of memory that's that's needed to
16:05evaluate the hash function so that's the
16:08idea behind script so if I'm building
16:10dedicated Hardware to do dictionary
16:12attacks now I have to kind of you know
16:14the number of uh engines I can lay on
16:17one chip is sort of limited by the
16:19number of memory components that I can
16:21put in every chip and since memory is
16:23relatively large now each one of my
16:25chips is not going to have that many
16:27hashing engines and so we kind have uh
16:30we kind of have um more equality between
16:33the actual website's hardware and the
16:35attacker's hardware again because the
16:37attacker cannot replicate uh using
16:39dedicated Hardware the attacker cannot
16:42put too many hashing engine engines on
16:44each chip because each engine needs a
16:46lot of memory and memory takes space
16:49space on the chip okay so so that's
16:51script and that's actually a fine thing
16:52to use there's one problem with escript
16:54however which is that in escript if you
16:58look at the how memory how this memory
17:01is being accessed as you're evaluating
17:03the hash function it turns out the
17:05memory access pattern actually depends
17:07on the password that the user supplied
17:09okay so for my password there would be
17:11one particular memory access pattern for
17:14your password there would be a different
17:15memory access pattern now you might have
17:18heard of uh what call what are called
17:20cache timing attacks where essentially
17:22an attacker who is able to um actually
17:26gain uh a low privilege control of the
17:29web server so the attacker sits on the
17:31web server but just has low privilege
17:34access to it um just by having a full
17:36hold on the web server you can actually
17:38get a lot of information as to how a
17:41high privilege process is accessing
17:43memory okay so basically what you're
17:45doing is you're kind of looking at how
17:46as a low privilege me uh process process
17:49you're looking at how the cash is being
17:51used and by looking at how the cash is
17:53being used you can figure out how the
17:55high privilege process is accessing
17:57memory you can't read the the password
17:59that the high privilege process is is uh
18:01processing but you can see how the high
18:03privilege process is accessing memory
18:06well if you can do that as I'm entering
18:09my password you can just measure uh what
18:11the memory access pattern is and now
18:14when an attacker uh recovers say the
18:17hash password plus the memory access
18:20pattern uh as the as the as the hash
18:22function was being evaluated that
18:24essentially eliminates the memory
18:26requirements for uh Computing the hash
18:28function because what the attacker would
18:30do is he would just try one password
18:32after another but he wouldn't actually
18:34evaluate the hash function he would just
18:35kind of compute the memory access
18:37pattern associated with the hash fun
18:39with the hash function and as soon as he
18:41sees that the word say you know 1 2 3 4
18:435 does not match the memory access
18:46pattern that the user uh generated with
18:49his password he knows that the user's
18:51password is not 1 2 3 4 5 so again he
18:53can reinstantiate the offine dictionary
18:57attack without memory
18:59just using the memory access pattern so
19:02I hope that was clear but essentially
19:04what it says is that script again it's a
19:05wonderful wonderful idea um in that it
19:09requires the attacker to to spend a lot
19:11of memory in order to evaluate the hash
19:13function uh but the minute the attacker
19:15has a little bit of side information in
19:17particular the memory access patterns as
19:19the hash function is being evaluated
19:22that essentially allows the attacker to
19:24now test words in the dictionary without
19:27memory and now we're back to a
19:29problematic custom Asic attack okay so
19:32that's the issue with script and so the
19:33question is what do we do about that is
19:35there a better solution and so again
19:36there's been progress on this recently
19:39the question that we're kind of asking
19:40is there a space hard function where in
19:43fact uh the time to evaluate the hash
19:46function is independent of the password
19:48and the answer is yes there actually is
19:50such a thing and uh here let me show you
19:52the hash function is called um this hash
19:55function is called argon 2 and it was
19:57actually the the winner of this password
20:00hashing competition that concluded
20:02recently and the the nice thing about
20:04argon 2 is it supposedly space hard and
20:07at the same time it's in the memory
20:09access pattern is independent of the
20:10password so the attack that I just
20:12described presumably would be would be
20:14difficult to mount so the one issue with
20:16argon 2 is it's not there's no kind of
20:19um a rigorous security proof to argue
20:22that it really is uh space hard as is
20:25claimed and so one of the things that we
20:28were interested is basically can we come
20:29up with the same prop with a hash
20:31function that has the same properties as
20:33argon 2i but actually has a proof that
20:36it cannot be evaluated with less memory
20:38than what's claimed and so the the hash
20:41function we came up is came up with is
20:43called balloon hashing this is Joint
20:44work with one of my students Henry
20:46Corgan Gibbs and Stuart Shor who uh is
20:49at Microsoft research and the properties
20:51of the hash function essentially as we
20:53said it's a it has a password
20:54independent access pattern memory
20:56independent access pattern so you can't
20:58do the attack that I just described uh
21:01it uses basically standard crypto
21:02primitive namely it's just based on sh
21:04256 so everything here is kind of uh
21:07standardized based on Primitives we all
21:09know and love it's actually uh quite
21:11fast and definitely can achieve you know
21:13rates of a th000 hashes per second uh so
21:16it is so it can be used on real world
21:18servers and the interesting property is
21:20that in fact it has um a proof of
21:22security in the following sense if you
21:24try to evaluate it um with less space
21:28than clck in particular suppose you try
21:30to evaluate evaluate it with a quarter
21:32of the space that we claimed is required
21:36then the amount of work to to do the
21:38evaluation actually kind of blows up
21:40exponentially so if you evaluated with
21:42however much space we said is needed
21:44then you can do it at a thousand times a
21:46second if you try to evaluate with a
21:48quarter of the space that we said is
21:50needed all of a sudden the total amount
21:52of work blows up exponentially so that's
21:55kind of a proof that uh you know at
21:57least when it comes to the total amount
21:59of work you have to do uh that uh can't
22:02be that that evaluation can't be done
22:05without space so again if the attacker
22:07is trying to build custom as6 to do a
22:09dictionary attack he has to spend a lot
22:11of space um to uh to mount the attack
22:14now one thing that's interesting is we
22:16were primarily interested in the total
22:18amount of work that's needed to evaluate
22:19the hash function uh with with less
22:22space but it turns out um if you're
22:24going to build something that's me
22:25that's that has uh that's um me memory
22:28access pattern independent of the
22:30password uh then it turns out there's um
22:33essentially uh kind of a an possibility
22:36result that says that any such scheme
22:39including argon 2i and balloon is is
22:41going to be subject to what's called a
22:43parallel speed up so in other words even
22:45though the total amount of work that the
22:47attacker has to do has to be quite large
22:50the attacker can still speed up some of
22:51what he's doing by kind of laying out
22:53multiple Cordes on his on his um on his
22:56processor so we're kind of um we have to
22:59have a we need to choose between two
23:02options either we have a hash function
23:05where the memory access pattern depends
23:06on the password and then You're
23:08vulnerable to the attack that I
23:09described before or you have one where
23:12the memory access pattern is independent
23:14of the password but then you have to
23:15worry about these parallel speed up
23:17attacks and so what we're actually
23:19recommending now is that since you know
23:21we can't kind of have the best of both
23:22worlds Let's do let's do both so kind of
23:25the natural thing to do is maybe you use
23:27balloon or argun to I to Hash the
23:29password first that prevents uh these um
23:34memory access pattern attacks and then
23:36you apply script so that uh the memory
23:39access pattern attack would only apply
23:41to the hash password not the original
23:43password so basically if you compose
23:45balloon on AR or argon toi with script
23:48in some sense you kind of get uh The
23:50Best of Both Worlds okay so that's
23:52that's one option to use so kind of
23:54that's what's been happening in the
23:55space of password hashing it's kind of
23:57interesting there's been recent develop
23:58vment as you can see uh so there's lots
24:00to say on how to do proper password
24:02hashing um this this is all very new
24:06material uh it has not been standardized
24:08yet um and so if you're considering um
24:12moving away from pbkdf2 you should
24:15because pbkdf2 is relatively old at this
24:17point um but uh what to move to yet is
24:20actually still as you can see a very
24:22active area of research so don't change
24:24what you're doing just wait just just
24:26yet just wait a little bit more but just
24:28realized that there's actually very
24:29active and uh interesting research going
24:32on in the space I wanted to show also
24:34show you what the balloon hashing
24:35function actually actually looks like so
24:39you know I can't give a presentation
24:40without actually giving you a little bit
24:41of code so let me show you what these
24:43space hard functions look like and how
24:46they operate so uh let's see so the way
24:48they work is basically as as I said they
24:50take as input the password the salt for
24:54the password the space requirement and
24:57the time requirement okay so what we do
24:59is first we allocate a buffer where the
25:01password will be where um where where
25:04that that is going to contain the large
25:06amount of memory that's needed to
25:07evaluate the hash function the next
25:09thing we do is uh we basically fill up
25:12the this buffer using values derived
25:15from the password the password and the
25:17salt so what we do is basically as you
25:19can see here we're kind of uh hashing
25:21the password and the salt and all we're
25:23doing in this Loop here is just filling
25:24up the buffer using uh values derived
25:27from the password and we're using as I
25:29said a hash function here as you can see
25:31this hash function this would just be
25:32like shot to 56 or so all right so then
25:36um the next thing we do is we're going
25:37to do a number of iterations so this is
25:39going to depend on the time cost so you
25:41can see the time cost variable here um
25:44the more iterate the more you iterate uh
25:46the more secure the hash function
25:47becomes uh in a certain sense which I
25:49won't make explicit here and then what
25:51we do is basically every every iteration
25:54we Loop through the buffer and do the
25:56following steps basically um we change
25:59uh so we take the previous value in the
26:02buffer in other words we take the uh you
26:05know when we're looking at element
26:06number M actually prev is just the value
26:09of the buffer element at position M
26:10minus one and then we hash that so we
26:13hash the elemented position n minus one
26:15with the elemented position M okay so we
26:17just hash two consecutive values and
26:20then in addition we Hash a few more
26:22values we can choose 20 more values uh
26:25to hash and uh all those values
26:28basically form the new value at position
26:31M and as you can see we're kind of doing
26:33a linear scan through the buffer and at
26:35every step in the buffer we're basically
26:37hashing well essentially 21 values uh
26:40into this uh position m in the buffer
26:43and M just kind of increments
26:44sequentially uh one after another so
26:47that's it that's the whole hash function
26:48we iterate this over and over and over
26:50again and finally the final output is
26:52the last entry in the buffer so it's
26:54kind of cool that this hash function
26:56just fits on a single page it's very
26:58easy to see how it works and as I said
27:00most of the work is in proving that in
27:02fact um the total amount of work that
27:04has to be done to evaluate this function
27:06must take a lot of memory okay so
27:08there's an accompanying proof of
27:09security that shows that if you try to
27:11evaluate this function with little
27:13memory their running time would actually
27:15blow up all right so that's what I
27:18wanted to tell you about uh password
27:20hashing now we're going to change gears
27:22a little bit I see that I have 10 more
27:23minutes so we're going to change gears a
27:25little bit I hope in the remaining 10
27:26minutes I can tell you about completely
27:28different topic that we've been working
27:30on having to do with uh control flow
27:32Integrity so this is Joint work uh with
27:35our students Ali Masa Andrew b a
27:38professor here David maerz and and
27:40myself okay so let me tell you what this
27:43is about so complete change of gear from
27:45password hashing on to control flow
27:48Integrity all right so control flow
27:51Integrity is a wonderful wonderful idea
27:53uh due to a body adal back in 2005 and
27:56the idea is essentially it's a way to
27:59prevent what are called control
28:00hijacking attacks where the attacker
28:02tries to take control of how the program
28:06executes so you know about buffer
28:08overflow attacks return or re
28:10programming attacks I hope you know
28:11about these things if you don't know
28:12about these types of attacks please
28:14please take our um secure programming
28:16course where we go into extreme depth
28:18about all these uh all these attacks and
28:21how they operate okay so uh the goal of
28:24control SL Integrity is basically to
28:26protect a program from these control
28:29hijacking attacks where the attacker
28:31basically um is able to to essentially
28:35uh take control of how control flow
28:37operates of how control flow flows and
28:39in that basically that allows the
28:41attacker to do uh to cause lots of
28:43damage uh to the program okay so there's
28:45actually a lot of academic research on
28:48control flow Integrity there's actually
28:50you know there's a lot of systems that I
28:52just gave some examples here uh and
28:54there's also a bunch of attacks on these
28:56systems and so on so this is a very
28:57active area of research um let me tell
29:00you instead of going through all the
29:01previous work let me kind of tell you
29:03what this is about and I'll tell you
29:05kind of um what what we've done all
29:08right so how does control flow Integrity
29:10work uh well again as I said there are
29:12many many many many proposals the cool
29:14thing is that actually in Windows 10
29:16this has actually been deployed by
29:17Microsoft in um and different systems
29:20called MX and control flow guard uh let
29:22me just tell you how control flow Guard
29:23works so what it does is essentially um
29:28well what it does I would say we
29:30consider this as very coarse control
29:32flow Integrity but what it does is
29:34essentially it builds at at uh compile
29:37and linking time the compiler
29:39essentially builds a table of all
29:42possible entry points into different
29:44functions in the program okay so you
29:46know maybe you have hundreds of of of
29:48functions in your program essentially
29:51what the compiler does is it lists
29:53literally lists all these uh possible
29:56entry points uh all these possible
29:58function entry points in a table it's
30:00represented as a bit Vector yeah so
30:02there's a bit big bit Vector at the
30:05beginning of your code that's that's
30:07zero if that particular address is not
30:09an entry point for for a function and
30:12the the bid Vector is one if that
30:14address is an entry point for a function
30:17and then every time you make an indirect
30:18call so here you know you can see that
30:20you're you're kind of making um an
30:22indirect call say you know a method
30:24invocation or so on what the program
30:27actually does is it takes the address of
30:29the indirect call and then calls this
30:32extra check here you can see the check
30:34that's uh shown here essentially this
30:37guard check I call what it does is it
30:40looks at the address that the processor
30:42is about to jump to and it verifies that
30:45in the bit Vector the corresponding bits
30:48is set to one in other words where it's
30:50about to jump to really is an entry
30:52point to a valid function in the code so
30:55you can't just cause the code to jump
30:57wherever you like you have to jump into
30:59a valid entry point in the in the
31:01program so this makes the uh control
31:03flow uh this makes the control hijacking
31:06attacks much much much harder to do and
31:08you see that if this uh function uh
31:11basically returns in other words you are
31:13jumping into a valid function then the
31:15actual call takes place you can see that
31:17we're now calling ESI which actually
31:19calls the function so the call only
31:21happens if you jump to an address that's
31:23a valid entry point for a function now
31:26so this looks great yeah this is already
31:28making these control hijacking attacks
31:31much harder uh however it's not perfect
31:33when the reason it's not perfect is
31:35first of all you realize it's checking
31:37that the attacker is calling some
31:39function but it's not checking that the
31:41attacker is calling the correct function
31:43right so the attacker can still jump to
31:45the wrong function and that will still
31:48uh cause you know in some cases that
31:50still let the attacker take control of
31:52the code and that's not prevented by
31:54control flow guard so again control flow
31:56guard flow guard is a wonderful
31:58wonderful idea but you can pretty much
32:00see how to get around it by essentially
32:02causing the code to jump into the wrong
32:04function that's an actual valid function
32:07in the program and the other thing is
32:09why can't we make it more precise it
32:10turns out it's actually non-trivial to
32:12build the actual control flow for the
32:14for the for the program at compile time
32:17it's much easier to do this dynamically
32:19at runtime and that's kind of what we're
32:21uh trying to do so let me explain to you
32:23what uh what we're doing so we have a
32:25different approach to control flow
32:26Integrity we call it cryptographic
32:28control flow Integrity so rather than um
32:31building it based on code analysis we're
32:34going to build control flow Integrity
32:35based on crypto and so let me explain to
32:38you first of all what are we assuming so
32:39we're assuming the attacker has a lot of
32:41power the threat model that we give the
32:43attacker is we say you know the attacker
32:45can read and write memory anywhere that
32:47it wants so we're given the attacker
32:50this is a remote attacker say that's
32:52trying to attack the web server and
32:53we're just assuming the attacker can
32:55already read and write any point in
32:57memory
32:58for in this web server um in the web
33:01server that's running that's coming
33:02under attack and in fact we showed we
33:04had a paper actually in 2014 14 we call
33:07this the hacking blind paper where we
33:09actually showed that on a real web
33:11server very very often attackers can
33:13actually induce reads and writs wherever
33:16they want so this is it sounds like it
33:18it's giving the attacker too much power
33:20but we actually came up with attacks
33:21where that's exactly the amount of power
33:23the attacker has literally you can read
33:24and write any point in memory and even
33:27though
33:28the attacker has so much power the
33:30attacker should not be able to cause the
33:31program to deviate from its designated
33:33control flow so again uh control flow
33:37must proceed at uh the allow only at the
33:40intended uh flow and not and the
33:42attacker should not be able to modify
33:43that okay so how do we do it well the
33:46way we do it is as I said using this uh
33:48using this cryptographic control for
33:50integrity idea what we do is essentially
33:52every time control flow depends on a
33:54jump address uh we're going to provide
33:57we're going to very ver ify Integrity of
33:58that jump address in particular what the
34:00code will actually do is every time it
34:03writes an address under the Heap or onto
34:06the stack it's going to concatenate to
34:08this address a 64-bit Integrity tag okay
34:12so here is how we comput it basically
34:14we're we're we're going to depend on on
34:15the AES block side for for this and
34:17again if you want to learn how AES Works
34:19uh we discussed this at Great length in
34:21our crypto course um but AES is
34:23basically is one thing that we can use
34:25AES for is to compute integral tags and
34:28what we do is basically we compute
34:30essentially this Integrity tag on the
34:32jump address uh plus the source address
34:35and you know we prend a zero if it's on
34:37the Heap we prepend the one if it's on
34:39the stack just so that there's no
34:40confusion between addresses on the Heap
34:42and addresses on the stack and now you
34:44can see that now every single uh Dynamic
34:47address on the Heap or on the stack is
34:49going to have this Integrity tag
34:51associated with it and every time we
34:53jump to that address before we jump we
34:56actually verify that the tag is is valid
34:58so essentially what the program is doing
35:00is making sure that um that jump address
35:04was actually generated by the program
35:06and not by the
35:07attacker so we only jump to addresses
35:10that the program generates and not
35:12addresses that the attacker controls now
35:16you should be asking when you look at
35:17this you should already be wondering
35:19where is this keyk going to be stored
35:21right I told you that the attacker can
35:24read and write any point in memory so if
35:26we store the key k memory the attacker
35:29can just read it and once he has the
35:30keyk he can forge these Tags by himself
35:33and he can defeat the mechanism so the
35:35question is where do we store this key
35:37Cas so the attacker can't get at it at
35:39it and the answer is we're going to
35:40store it actually in an xmm register so
35:43this key always lives in registers on
35:45the processor and it's never never ever
35:48written to main memory so the attacker
35:50can't can't actually read it and it
35:52turns out many programs actually don't
35:54use the xmm registers xmm registers are
35:56um sort of extensions extended registers
35:59in the processor uh many programs don't
36:01actually use it uh and as long as they
36:03don't use it you know we can put our key
36:05there interestingly open SSL actually
36:08ends up using the xmm registers and so
36:10to make op SSL work with this uh this is
36:12op SSL is a crypto Library we actually
36:14had to do uh extra work but again that's
36:17all described in our paper and I won't
36:18describe that here for the in the
36:20interest of time so just to complete
36:22this uh this topic you must be thinking
36:25that we're completely nuts in that again
36:26if you think about what we're proposing
36:28is every time uh an address is written
36:31to Heap or stack we compute an AES
36:34Integrity tack on it a tag on it and
36:36every time we jump to that address we
36:38verify the tag so if you think about how
36:40many times we have to compute AES as the
36:42program is running it sounds like this
36:44is just going to have horrible
36:45performance implications but it turns
36:48out actually it doesn't it doesn't yeah
36:50so we implemented this in llvm we tried
36:53this on a lot of kind of common
36:54applications and the Slowdown you know
36:57it is there is definitely a penalty to
36:59doing this but the Slowdown is not like
37:01out of the you know out of the out of
37:03completely completely unreasonable there
37:05is a Slowdown but it it does provide
37:07quite a strong level of Defense so how
37:09are we able to get this to be uh so fast
37:12and the answer is again something you
37:14guys should be aware of which is thank
37:17you Intel Intel has actually made
37:19amazing progress in making AES run fast
37:23on the x86 processor so Intel added
37:26these instructions called the AES s ni
37:28instructions ni stands for new
37:30instructions and what they did
37:32essentially is they implemented AES in
37:34Hardware so um there's an AES ink
37:37instruction now that implements one
37:39round of the AES Cipher so if you want
37:41to if you want to do an AES encryption
37:44all you have to do is just call AES in
37:4610 times for the 10 rounds of AES and
37:49that's essentially one um evaluation of
37:51AES and in fact as you can see over the
37:54years Intel has actually made AES even
37:56faster um as this has been such a
37:59successful project for them that AES
38:02speed is is constantly improving and the
38:04faster it gets the lower the overheads
38:07for our for our system moreover they
38:09even they even made these ases
38:11evaluations fully pipelined so the
38:13throughput for evaluating AES
38:15essentially is is uh you know almost one
38:18cycle per uh per one AES round uh yeah
38:21so this is quite remarkable and because
38:23of these a instructions we're able to to
38:26get the performance for our uh method to
38:28run at a reasonable rate okay so uh yeah
38:31so I wanted to just point tell you that
38:33these AES the fact that there's AES
38:35available in Hardware is great for
38:37crypto on the wire but it's also great
38:40for uh securing applications for example
38:43by using by by providing this strong
38:45control flow Integrity all right so
38:47these are two projects I wanted to tell
38:48you about I guess we're going to I
38:50wanted to tell you more about internet
38:51of things things we're doing but I guess
38:53we will do that at a future webinar so
38:55thanks everyone for the questions
38:56terrific questions
38:58um so let's see so let's get to as many
38:59of these as we can uh so how do gpus
39:02impact the Practical implications
39:04ability for evaluating or Brute Force
39:06brute forcing hash functions so that's a
39:08great question actually so for hash
39:10functions that are not space hard um
39:13gpus actually are quite detrimental
39:16right so again a GPU has many many cores
39:19and as a result you can actually
39:20evaluate um many iterations of the hash
39:23function at once and that allows you to
39:26speed up the uh the uh dictionary attack
39:28significantly so memory hard functions
39:30so functions that require a lot of
39:32memory to evaluate are much harder to
39:34run on a GPU especially because every
39:37core for every valuation of the hash
39:39function the core has to allocate a lot
39:42of memory for Val evaluating that hash
39:44function and as a as a result uh it's
39:46actually quite quite difficult to do on
39:48a GPU so if you're worried about GPU
39:50based attack definitely you need to use
39:53a space hard hash function like balloon
39:55or argon or script and uh you should not
39:58be using pbkdf2 generally I hope I
40:00convinced you in this presentation that
40:02pbkdf2 is at this point essentially on
40:05its way out yeah in in in a few years uh
40:08once the once the discussion of uh the
40:10Next Generation hash functions is
40:11settled we will not be using TB kds2
40:14anymore we really should be using space
40:16hard functions okay the second question
40:18is basically about having to remember
40:20lots of passwords and uh the the the the
40:24uh the question is about why not use
40:26password managers of course course
40:27password managers themselves also get
40:29hacked so why shouldn't we just get rid
40:30of passwords altogether I couldn't agree
40:33more couldn't agree more so um in fact
40:35I'm a very big supporter of uh second
40:38Factor authentication um uh Google
40:40Authenticator is a fantastic tool if um
40:43you're running a website you should all
40:45you should integrate Google
40:46Authenticator into your website um to
40:49let people use it you should advertise
40:50it for your users uh and um there are
40:54even better mechanisms now for uh second
40:57Factor authentication CH challeng
40:59response based if you're familiar with
41:01companies like Duo they've made that
41:03even easier to use um and so definitely
41:06uh I couldn't agree more and that's a a
41:08question that's right on target uh the
41:10next question is uh how much memory are
41:12we talking about so generally for these
41:14space hard functions whether it's script
41:17argon or balloon essentially what we try
41:20to do is fill up the L3 cache so we
41:22don't quite we don't go to main memory
41:24CU that actually would not let us uh
41:26achieve the th000 hashes per second
41:28we're aiming for but the goal here is to
41:30fill up the L3 cache so when I talked
41:32about I showed you the pseudo code the
41:34buffer and the pseudo code essentially
41:35would be as big as your L3 cache uh okay
41:39let's see so my next question uh is
41:41about
41:42ccfi um uh yeah how would this impact
41:47mobile devices you know the answer is
41:49you could so uh I guess on mobile
41:51devices you would be using uh they're
41:53not using uh Intel processors so much
41:55those are more Arm based architectures
41:57so first of all arm has also given a
41:59success of asni arm has also introduced
42:03asni into the into manyu of their of the
42:06of the arm designs and so um it's
42:09exactly the same API as on the x86 and
42:11so in principle pca5 could be used on
42:13mobile devices as well anyone any mobile
42:16device that supports asni and my point
42:19was that the faster the hardware
42:22implementation of AES is the less
42:24overhead that ccfi will take and really
42:27does provide quite a strong measure of
42:29uh security against control control
42:31hijacking attacks and so in principle
42:33this could be used on mobile devices
42:35again there's a performance penalty but
42:37there's also a a strong security benefit
42:40okay um the next question is about uh
42:43ccfi on Sparks and it's basically the
42:45same answer I just gave essentially
42:47whenever a and I is available whenever
42:50you have AES in Hardware you can
42:52actually use it without too much um uh
42:54too much penalty the performance penalty
42:57okay the next question is about Ring two
42:59if I if the attacker gets control of
43:00ring two on the computer yes absolutely
43:03then all bets are off so with ring two
43:06you can do you can extract a secret key
43:08and then you would defeat this this
43:09attack um uh well so the threat model
43:13that this is trying to defend against is
43:15a model where the attacker uh has
43:18control has access read write access to
43:20memory if the attacker has even more
43:23power then absolutely there's uh that's
43:25a much much much harder adversary to
43:27defend against then you would have to go
43:29to um to virtualization and and other
43:32based approaches uh okay so that's
43:34basically ccfi is defend designed to
43:36defend against memory corruption attacks
43:38not so much against uh ring two based
43:40attacks uh can a hacker readed write xmm
43:43xmm registers yeah so if a hacker is
43:46basically using memory corruption to uh
43:48to mount his attacks then he can't um he
43:51can't have access to xmn registers if
43:53it's a more powerful attacker like the
43:54previous question then absolutely all
43:57bets are off there's no Perfect Defense
43:59uh we were trying we were basically
44:01control SL Integrity generally is trying
44:03to uh prevent memory corruption attacks
44:06and we basically we're trying to we our
44:08our mechanism is uh uh essentially using
44:12this uh cryptographic mechanism to
44:14prevent memory corruption okay uh let's
44:17see
44:18um oh are there programming languages
44:21construct compilers that support
44:22generation of a instruction sets well uh
44:25compilers actually don't quite use them
44:27today typically when you want to use
44:28asni you would just inject some assembly
44:30code into your into your higher level
44:33programming language and you would
44:34compile that in uh so for example when
44:37you uh when you use op SSL for crypto op
44:40SSL actually uh is when it's on running
44:43on the appropriate Hardware it will
44:45actually use asni and so automatically
44:47by using op SSL you're getting the
44:49benefits of of asni but yeah typically
44:52you do have to access it using assembly
44:55is the cc5 project going to be open s
44:57absolutely so it's implemented as um uh
45:00into lovm right now uh yeah we'll make
45:03obviously this is academic code so you
45:06know use it to your own risk um but
45:08absolutely if you're interested in uh in
45:10studying this or using it or developing
45:12more um on ccfi we we definitely U make
45:17will make this open source um let's see
45:20on the balloon scheme where did the
45:21number 20 come came from that is an
45:23excellent excellent question I'm really
45:25happy to hear someone asked this so why
45:28do we if you look back to how um we we
45:31did the hashing we said that essentially
45:33as you do your linear sweep through the
45:35buffer you basically hash 20 elements in
45:37the buffer into the current element that
45:39you're looking at so why 20 it turns out
45:43uh the number 20 comes from the security
45:44proof yeah so this is the nice thing
45:46about doing security proofs and that
45:48they guide you into how to design the
45:49hash function so if we if we do include
45:53uh if we do do the hashing on 20
45:55elements that allows us to prove that if
45:58you evaluate the hash function with less
46:00than quarter of the space that we
46:02require the running time would actually
46:04blow up exponentially okay so and by the
46:06way since you asked uh about the
46:08technicalities I'll tell you that when I
46:10say exponentially I mean exponentially
46:12in the number of rounds that the hash
46:15function is is uh using so remember I
46:17told you that there's a timing parameter
46:19how many rounds the hash function runs
46:21for so for example if you run it for 10
46:23or 20 rounds let's say you run it for 20
46:25rounds then if you try to at the hash
46:27function with a quarter of the space
46:28that's required then necessarily the
46:30running time would grow the total
46:32running time uh not the parallel running
46:34time the total running time would grow
46:36by a factor of a million okay so that's
46:37where the number 20 comes from basically
46:39it's needed for the
46:41proof
46:43um uh right so you asked about sh 66 in
46:47fact so in balloon hashing should be
46:48used sh 66 or a different hash function
46:51so our point was that balloon that one
46:53of the nice features of balloon is it's
46:55built from sort of stand IED components
46:58and shot 56 was a reason was a very
47:00common component to use in fact uh the
47:03most of most of our running times we for
47:05most of our running times we actually
47:06use shot 3 which is kind of the uh a
47:09recent uh variation you know a recent
47:12proposal for n for a hash function the
47:14reason sha 3 was better suited for us is
47:16because it has a larger block size than
47:18sha 356 and that actually improves
47:20performance so um yeah but essentially
47:23you can use any standardized hash
47:24function you want if you want uh the
47:27fastest possible performance then uh you
47:29would use a hash function with a large
47:31block Cipher so just use any of the
47:33standardized ones we just happen to use
47:35uh shot 3 for for for running times uh
47:38let's see any research on crypto
47:40Biometrics or related crypto
47:43authentication absolutely there's a lot
47:44of research on using Biometrics for
47:47authentication in the crypto sense um
47:50the question is how do you do hashing
47:52when the credential is a biometric right
47:55so if I have my if the metric is a
47:57fingerprint the credential is a
47:59fingerprint uh well when I read it
48:01initially I get one version of the
48:03fingerprint when I read it uh later on I
48:05get a different version of the
48:06fingerprint that might be a little bit
48:08different uh and the question is how do
48:10we compare the two traditionally when
48:12you do biometric you kind of extract
48:14extract what's called a sketch from the
48:16fingerprint and then you compare the
48:18scetch the sketch that was registered
48:20from the sketch that was that was read
48:22at a later time the sketches don't have
48:24to fit perfectly they just have to be
48:25close to one another so the question is
48:28um if we do hashing how do we do the
48:31comparison if the sketches only need to
48:33be close but don't have to be perfectly
48:35equal and the answer is there's actually
48:36something called fuzzy hashing which
48:39actually is relevant for Biometrics um
48:41again so if you're interested in that
48:42just Google fuzzy hashing and you'll see
48:44a whole bunch of papers on how to do
48:46hashing for the purpose of uh
48:49Biometrics okay so that's going to wrap
48:51up our live session uh on behalf of the
48:54Stanford center for professional
48:55development I'd like to thank thank you
48:57for joining us for our webinar on uh
48:59hashack code emerging Trends and cyber
49:02security there are still a number of
49:04questions in the queue which we will go
49:05ahead and respond to offline so thank
49:08you again for joining us and have a
49:10great
49:20day

About this transcript

This page contains the full transcript of YouTube transcript (544rhbcDtc8) , generated from the public captions YouTube serves with the video. The transcript has 9,616 words across 1,322 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.