Hello and welcome to this video titled WPA3 SAE PMK Derivation.
So as the title says, in this particular video, we're going to go into
the gory details of how the PMK is derived with WPA3 SAE.
Now I should preface that by saying that with WPA3 SAE, there's actually
something that's derived before the pairwise master key, which is something
called a shared secret.
So this is really going to be getting more into how that shared secret
is derived. And once that is created, the pairwise master key can be derived
from it. So let's just do a quick review right here.
So we know that with WPA2, there were really only 2802.11 authentication
messages that were exchanged and we can see them right here.
And so the client would send an authentication message to the access point
and the authentication algorithm was simply open system.
And look at this, the authentication status code was successful.
So the client was already saying, hey, I'm already successful in authenticating.
This is basically just sort of an old carryover from a long time ago,
where I said, look, we have to exchange authentication messages that's
sort of like built into the standard.
But they decide a long time ago, we're not actually going to do authentication
right here. We're going to do authentication pretty much after association
is done. So this is sort of just a carryover from that.
And you can see here that the access point was send a message back to
the client with another authentication message.
Also authentication algorithm open system saying, yep, you're good.
But really, authentication wasn't actually taking place here.
Neither side was doing anything to actually authenticate the other side.
Well, with WPA three with WPA three personal, otherwise known as simultaneous
authentication of equals, they changed that.
They said, look, we're actually going to authenticate each side right
here in the authentication stage.
And we're going to use this to come up with our pairwise master key.
And so one of the things they did to change this is in increasing it from
two messages to four messages.
And you can see them right here.
And you can also see that in the authentication algorithm, they changed
it to simultaneous authentication of equals.
So you can see that right here.
It no longer says open authentication.
It now says version three, which is S A E.
Okay. And then in this, these four message exchanges, there's actually
a bunch of stuff in here.
There's something, for example, called a scalar and a finite field element.
And we're going to be talking about the details of that in this video
right here. Now I will give you a heads up right now.
If your objective of watching these videos is simply just to learn the
bare minimum of NA or some CCMP wireless exam, then you can stop right
now in this video.
Everything I'm going to go forward in this video is going to be above
and beyond what you would simply need to know for the purposes of passing
a certification exam.
You might be wondering, well, then Keith, why did you create the video
in the first place?
Well, to me, if I have an engineering mindset, I will take a look at this
and I will be naturally curious about things.
I'll wonder like, okay, why exactly do we need four messages?
Okay, I understand that the first two messages are called commit.
The second two messages are called confirm.
And maybe if I was studying for a certification exam, that's all I would
need to know. But for me, with my mindset, I'm naturally curious about,
well, what makes the commit messages different than the confirm messages?
And if I do a sniffer trace, like I did right here, I'll notice that the
commit messages will have stuff in it like a scalar and a finite field
element that are not present in the confirm messages.
The confirm message has something else.
And I naturally sort of wonder, well, what are these things called the
scalar and the finite field?
What are they used for?
Why is it important in the whole dragonfly exchange, otherwise known as
SAE, that we have these?
And so this video is really sort of to answer those of you who are like
me a little bit curious about what are these messages?
What exactly do they contain?
And what are these fields in here without going to gory detail into the
really deep math of everything?
And so that's what this is for.
Because for me, once I walk away from this, really understanding what
these fields are and what really makes a commit message different than
a confirm message, I can feel a little SAE above and beyond what a simple
certification exam might ask me in a multiple choice question.
So that all being said, let's go ahead and continue on right here.
Okay. So with WPA3, one of the objectives was we know that one of the
things that made WPA2 bad, or I should say a little insecure, is that
everybody uses the same passphrase to join the wireless LAN, like coffee123.
Well, that's the same with WPA3, right?
You're going to have some when you're configuring a WPA3 personal wireless
LAN, whether it be on the gooey of your access point or the web UI of
your controller or whatever it is.
One of the first things you're going to have to type in is a passphrase
for the wireless LAN.
So both two and three have a shared passphrase.
One of the differences though, is in a previous video, we talked about
how with WPA2, there is a formula that's used called a P BKDRF2, I think
I have that right functionality, which the end result of that was it took
that passphrase and end up creating a pairwise master key from it.
But the problem was everybody had the same pairwise master key.
They all shared it.
Now the good thing is the pairwise master key is not used to actually
encrypt and decrypt data.
We have to do some further key derivation functions until eventually we
get to the temporal key, the TK, and that's what's actually used to encrypt
and decrypt our data.
But it starts with the PMK.
So if everybody has the exact same PMK, that's not a good thing, right?
In a good security world, everybody's keys would be different.
We wouldn't have a shared set of keys among the same sets of people.
So that was one of the problems with WPA2.
So WPA3 said, we need to come up with a unique pairwise master key for
every individual.
They shouldn't all have the same.
And so this is now talking about how does that happen?
How do we come up with a unique pairwise master key when we have, when
we're starting with a shared secret that's the same, like coffee, one,
two, three, or Cisco, one, two, three, whatever the WPA3 passphrase is,
how do we get from that same shared passphrase that everybody's typing
in to connect to the wireless LAN to a unique pairwise master key?
And the way we do that is we have to come up with some unique shared secret
before the pairwise master key.
And that's what this video here is going to be talking about is during
that, that SAE commit and confirm process, the ultimate end goal of that
is to come up with some shared secret path, some shared secret number.
And then that's, that's unique between that client and that access point.
So every client will have a different shared secret at the end of their
four way SAE message exchange.
And then from that shared secret that was derived just for that session,
they can then derive the pairwise master key after that, which will be
obviously unique because the shared secret that was derived before that
was also unique.
So how do we do that?
So WPA3 sort of does away with that whole PBK DRF2 function and comes
up with a different shared secret.
And it looks very much like Diffie Hellman in the way it works.
So with Diffie Hellman, we have some known public information that we
mathematically compute with our huge random number and some prime numbers
to compute the pairwise master key.
So the changes, so we change the random numbers on each successive authentication
attempt, which derives a new unique shared secret and pairwise master.
Don't worry. We're going to go into this in detail.
So let's start with a review of modular arithmetic.
So let me show you something here.
If I showed you something like 32 this, okay, if I said, figure that out
for me, 32, 32, modulo five.
Now if you already know how to do that, you can skip this slide right
here, just, just fast forward and go to the next slide.
But if you say, what does modulo mean and what is this?
How do I do this?
Well then that then you're in the right place.
Okay, let's do a review of modular arithmetic.
Sometimes you want to create an algorithm or a, or a function that divides
numbers by a certain value, X, and in the examples before X and the examples
below X is going to be the number four.
And then after dividing the numbers by that certain value, you're going
to have some sort of a remainder.
Let's say the remainder is Y and you want to actually take the remainder
and plug that into your formula or your algorithm.
So you're not actually looking for what you're dividing it by.
You're looking for what the remainder is of that division.
And we call that modular arithmetic.
For example, here we have 25 divided by four equals six with a remainder
of one. If we take 34 divided by four, that gives us eight with a remainder
of two and 31 divided by four is seven with a remainder of three.
And maybe it's those remainders that we want to plug into our formula
or our algorithm.
So when we're creating a mathematical expression that's looking for the
remainder of something, that's called modular or modulo expressions.
So in this case, our values of 25, 34, and 31, if we apply it against
modulo four, what we're dividing against, that will yield the remainders
we're looking for.
So this is typically expressed mathematically, for example, if we look
at the first one here, 25 modulo four will give us one.
So this is saying we're taking some number, dividing it by some other
number four in this case, and we're looking for what the remainder is.
So that's how you do this expression right here, or 34% four or 34 modulo
four would equal two, 31 modulo four would equal three, right?
We're looking for the remainder.
So this type of expression yields what the remainder is.
So that's going to be important as we go into Diffie-Hellman and then
ultimately how SAE does it.
So let's just do a review of classic Diffie-Hellman.
You've got peer A and peer B.
And the goal of Diffie-Hellman is to use large prime numbers, use modular
arithmetic that we just did a review on in the previous slide, to come
up with a shared secret value without actually ever exchanging the shared
secret value in the clear.
So we want peer A and peer B to come up with some shared secret number.
And if someone was actually looking at the transactions between peer A
and peer B, they will never actually see that shared secret value.
So here's how Diffie-Hellman does it.
We start out with three values.
So two of those are well known.
So we have some sort of a generator, some sort of base number, which is
called a generator.
We'll just call it G here.
We have a modulus, which is like in the previous example, the modulus
was four, right?
We were dividing all three of those equations by four.
So we have some static well known modulus.
And then what is kept secret, what neither side knows about is some randomly
selected exponent.
So for every session, this exponent is going to be some new value.
And peer A is going to have his own exponent, and peer B is going to have
his own exponent.
So that's A and B here.
All right, so using these, how are we going to come up with a shared secret
value that's the same for both of these?
So here's the initial computation.
Both sides will take their generator, their G value, okay?
And they will say G to the power of whatever their exponent is.
So peer A says G to the power of his exponent, peer B takes G to the power
of his exponent.
Now, whatever that is, we will then apply it against modulo M, okay?
And that will give us some result.
So A will say G to the power of my exponent, modulo M will give me some
result, which will say is capital A, and same thing is happening over
here. So these are considered the public keys to start out with.
So peer A will send to peer B the result of his formula, A in this case.
He'll say that's my public key.
And peer B will do the same thing.
He'll say, hey, peer A, let me tell you what my public key is.
Now we haven't gotten to the shared secret yet, but we're getting close.
Now, each side will perform a shared secret computation to come up with
S, which is their shared secret value.
How do they do that?
So peer A takes the public key that he received from B, which is B here.
He says, okay, I'm going to take B to the power of my exponent.
Just like previously, I took G to the power of my exponent.
I'm going to do the same thing, B to the power of my exponent.
Do that whole modulo M equation again, and that will yield some value,
which is my shared secret, because guess what?
If on the other side, if peer B takes A's public key, which is A, to the
power of his own exponent, which is B, modulo M will give the exact same
value as the shared secret.
Let's try this yourself.
So I want you to do this yourself.
So go ahead and pause this video, and I want you to take, let's say that
both sides sort of agree that their generator is going to be the number
five, so that'll be G.
Their modulus will be 23, so that'll be the M value here.
And on the left side, I want the random exponent to be seven, and on the
right side, I want the random exponent to be 11.
See if you can figure out what the shared secret value would be going
through this. Go ahead and pause the video for a moment, and if you can't
figure it out, that's okay, because when you play the video, I'm going
to walk through it with you.
But just pause the video and see if you can figure that out for yourself.
Okay, so let's start working through this.
So step number one would be to work through the equation.
So on the left side, P or A, he's going to take five, because that was
the generator, to the power of his random number.
In this case, it was seven.
Modulo 23 is going to give you 17.
You say, Keith, how did you come up with that?
Well, let's just use a calculator function for that.
So for our calculator, we're going to have to change it to scientific
notation. There we are.
And you know, use whatever calculator you have on hand.
So first I want to do five to the power of seven, because that's pure
A's exponent. So I just simply do five.
So x, y here is x to the power of y.
So I've already put in x, y, seven equals, there we go.
That equals 78,125.
Now I want to do that to the modulo of 23.
So for that, I'm going to change my calculator to programmer in this particular
case, because that gets me mod over here.
So it knows that carried over 70,000, 125.
So I just do mod 23 equals 17.
So that's how I got that number.
And if I do the same thing on the other side, scientific.
So I do on the other side, I'm going to be doing, let's go over here.
The base. To the power of 11 in this case, because that's pure B, that
gets us this big old number.
And if I change it to programmer.
And I do modulo 23.
That gets me the number 22.
So that's how we came up with 17 and 22.
Now to come up with our shared secret.
We do this. We take the number we received from our peer.
So, so a received 22 from his peer.
Right. That was a value of B.
Multiplied to the power of a, modulo M gives us a shared secret.
And if we did the same thing on the right, we'd get the exact same value.
A shared secret being 22.
Let's do our, our calculations here.
So let's go back to scientific.
So a received the value of 22.
From his peer. He did that to the exponent of his own exponent.
Cause that's all he knows.
He doesn't know his peers exponent.
That comes up with that big value right there.
And then we want to do modulo 23.
So I got a view programmer.
I got to take that.
Modulo 23 gives me 22.
And if I do the same thing on this side, 17 to the power of 11, whatever
that is, modulo 23 will also be 22.
So this is real basic Diffie Hellman here.
Now, when you're doing Diffie Hellman, typically one of the first things
you will agree on in your first message.
This is exchange is a Diffie Hellman group number, like Diffie Hellman
group five or Diffie Hellman group 14.
And when you are using classic Diffie Hellman, once you agree on your
Diffie Hellman group, like Diffie Hellman group five, for example, that
group has well known generator and well known modulus.
So that's built into the group.
And if I use Diffie Hellman group 14, for example, that will be a different
generator and a different modulus.
So the thing that you will be secret will be whatever your exponent is
on your right and your left side.
Now, how does WPA3SAE sort of use this to come up with its own shared
secret? So let's go back here.
So notice that in WPA3, we in our commit messages, so our first two messages
are commit, our second two messages are confirmed.
So in the WPA3 commit phase, we are exchanging two values, a scalar value
and a finite field element value.
So let's take a look and see how are these two values derived on each
side so they can exchange them with each other.
Okay, so in WPA3, we're going to start out with three values.
I should say, yeah, so three things, but they're a little bit different
than classic Diffie Hellman.
So in WPA3, we're going to start out with a password element.
And in another video, I'm going to talk about how do we come up with a
password element, but I will say the password element sort of is derived
using the SSID and the pre-shared key and a few other numbers.
So this is going to be plugged into a sort of complex formula to come
up with the password element.
We haven't really gone into how that happens, but just we'll get there.
So let's just say you've already done that complex formula that takes
as the inputs, the SSID, the pre-shared key and some other value and that
gives you a password element.
So both the client and the access point should start out right out the
gate with the same password element.
Now, the client's going to come up with two randomly selected values.
We just call that little a and big a, and we'll see how those are used
in just a moment.
And the access point comes up with two randomly selected values, little
a, I'm saying little b and big b.
And then there's going to be some static well-known modulus.
We'll call it Q in this case.
All right, so here's how we come up with our scalar value and our element
value. Remember, if we go back to this slide, where are we here?
Right here, we're talking about how do we come up with the scalar and
the finite field element.
So now we're coming up with these two values.
How do we do it?
Okay, so the scalar value, and we're just going to call the scalar value
for the client, S, A.
So he's A, so little S capital A, that's going to be his scalar value.
Over here, the access point scalar value is going to be little S capital
B or S B. That's his the scalar for B, the scalar for A.
So how do we come up with that?
Well, we take our two random values, we add them together, so A little
A plus A, and then we do modulo Q.
For B, we take his two randomly selected values, add them together, little
b capital B, whatever that is, modulo Q.
So that is the scalar value that they're going to exchange with each other.
And the element value, so for the element for A, so L, A, that's the element
for A, we're simply going to take his password element to the power of
negative capital A.
So whatever the A was here, we're going to take PwE to the power of negative
whatever that is.
And same thing on the right.
For the element of B, we're going to take the same password element, so
they both have the same shared password element to the power of negative
capital B. So that's what they're exchanging with each other in the commit
messages. We saw that in the SAE commit message exchange, they exchange
their scalar and their element values.
And now we know mathematically how those are derived.
Okay, so now at this point, we in on the backside, we create a shared
secret. So this is happening before the confirms are right after the one
to exchange of the SAE commit messages, just with that.
So if I go back here.
Let's see, where was it?
Right here. Okay, so this is, we're highlighting this here.
So this is from the client to the Cisco access point.
Notice that's highlight in blue up above.
So this is showing the commit message that the client is sending to the
access point. He says, Hey, here's the result of my scalar.
Here's the result of my finite field element computation.
Now, if I was able to click on the authenticate on the commit message
from the access point to the client, we would see he's sending his own
scalar and finite field element.
So after they both exchange their commit messages, before they do the
confirm messages, they are going to come up with their own shared secret.
And so how's that going to happen?
We can see that right here.
So notice the client here says, okay, I just received the scalar value
from the access point.
That's a scalar of B.
So I'm going to take my password element to the power of his scalar.
And I'm going to multiply that times his finite field element.
We call that element B.
So this is the, so I'm going to, I'm going to multiply these things to
two things together.
And then whatever that product is to the power of my little a value.
Oops, let's go back.
And then on the other side, the access point is going to take the same
password element to the power of the scalar he received from the client.
So the next step is the SAE confirm messages.
Okay, so here's the commit phase.
They both exchange their scalar and their elements.
They ended up coming up with the same statement.
So we have the same shared secret value.
And now the purpose of the SAE confirm is to confirm, okay, do you have
the same shared secret as me?
You should if you did your math right.
So the purpose of the SAE confirm exchange is to validate that.
So how do we do that?
So in the SAE confirm message, you're going to see here in just a moment
this big long value, which is called a confirm token.
And this is really just the result of applying in a H.
Mac hash digest computation against the following inputs.
So if I'm the client, I'm now going to take the my scalar and my element.
I'm going to take your scalar and your element that you sent me when you
sent me your commit message.
I'm going to take the shared secret that was derived.
And I'm going to take a sequence number of one and I'm going to hash that
with the H Mac, with, you know, the hash message authentication code.
That's what H Mac comes up with.
And that's going to give me my token value, my confirm token.
And guess what? You're going to do the exact same thing.
My scalar and element that I sent you, you're going to take the shared
secret that you derive the number of one and you're going to come up with
a confirm token yourself.
And this is how we can confirm that we both have the exact same values.
So let's see that right here.
So it's actually it's not.
So here I need to clarify something I said earlier, because you're, you
might be looking this and saying, well, wait a second.
The confirm token values, which means change the color here real quickly.
Are these big, long values right here?
They're not the same.
I can see here they're clearly different because one starts out with a
five five on the bottom.
The other starts out with C A F.
They're not the same number, Keith.
So what gives? So just to clarify something.
So both of these values are the result of an H Mac hash algorithm.
They're taking almost exactly the same inputs.
We saw that previous.
So if I go back to the previous slide here, just a second.
Let's go back here.
They are taking his inputs.
The same scalar and element values.
So both the client and the access point are taking their own.
The client is taking his scalar and element and he's taking the access
point scalar and element.
The access point is taking the client scalar element and the access point
scalar and element.
So that's the same on both sides.
They both came up with the same shared secret value.
So that's the same.
This, however, needs to change a little bit.
Let me just pause and change this.
Okay. Here I've made it a little bit more technically correct.
I've changed this bullet point right here.
You see what's going into the hash digest is a confirm counter value.
So both sides are putting in the scalars and elements that he both computed.
Both sides are putting in the shared secret.
But then there's a confirm counter.
Well, when the client is sending his confirm to the access point, that's
the very first confirm message.
So the client will have a confirm counter of one saying this is the first
confirm number one.
When the access point is creating his confirm message, that is the second
confirm message.
So the access point will put in the value of two.
Well, guess what?
Just those two, those little differences right there of the client putting
in one and the access point putting in two into that hash digest is actually
going to result in two very different numbers.
So the CAF number and this A55 number, this is actually computed from
the client because he used the confirm counter of one and the access point
used the confirm counter of two.
But knowing that in advance, both sides can use these confirm tokens to
validate that the other side has the correct shared secret.
And that is the purpose of the confirm message exchange.
Now, once the commit messages have been exchanged and the confirm messages
have been exchanged, finally, they can compute the pairwise master key
after this. So when they finally start doing the four way EAP over land
message exchanges, they will start with the same shared pairwise master
key. But notice it will be unique just for this pair of people.
This client and this access point will have computed a totally unique
shared secret, which will derive a totally unique pairwise master key
that's different than if another client connects to the exact same access
point. So thank you so much for watching this video and I hope it was
helpful for you.