
Falling through the KRACKs - kjhughes
https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/
======
goalieca
> As the KRACK paper points out, there is no formal description of the 802.11i
> handshake state machine.

This, to me, is one of the biggest problems facing our industry. In first year
undergraduate in engineering we learn how to design a state machine. We learn
to design one before we learned OOP and circuits and assembly. Yet, how many
APIs or Protocols have you come across or has your organization developed
where there isn't a state machine described somewhere. It may seem difficult
and tedious, but this is how you engineer something rather than merely
'develop' it. We programmers sometimes spend far too much time juggling stuff
in our heads and communicating with coworkers in a wonderful game of workplace
telephone. If the state machine has become too complex, then we have lost all
hope to fully manage it and must accept the risks. Some things just shouldn't
be risked!

~~~
userbinator
_This, to me, is one of the biggest problems facing our industry. In first
year undergraduate in engineering we learn how to design a state machine. We
learn to design one before we learned OOP and circuits and assembly._

I think one of the causes is that a lot of CS is taught top-down and not
bottom-up, so things like flowcharts, state diagrams, and other similar visual
aids are completely skipped in preference to more abstract thinking. I wonder
if at least some of this aversion is directly related to the "gotophobia" that
started with Dijkstra's famous paper.

 _It may seem difficult and tedious, but this is how you engineer something
rather than merely 'develop' it._

As someone who learned the "old school" way of planning out your code --- yes,
even drawing flowcharts and state diagrams --- before writing a single line of
it, I can assuredly say that it should be a natural and completely pleasant
process; what's "difficult and tedious" is trying to debug and coerce
something you (or someone else) wrote without planning into working correctly.

Over the years coworkers have been puzzled at why I spend "so much time"
flowcharting and just thinking before writing even a single line of code ---
only to try adopting the same method once they realise how much time it saves
in total, since all the cases have already been accounted for and the only
thing left to do is test out any of the few remaining and often trivial bugs
introduced during the design->code process.

~~~
closeparen
Except at the highest level of abstraction, my Lucidchart diagrams and Google
docs never survive their first encounter with the compiler. There always turns
out to be some fatal flaw that's obvious in an editor but totally escaped me
in the word processor. My (limited) experience has been teaching me the
opposite: dive in as quickly as I can and write some code to explore the
problem space, then go think harder about a design after getting my feet wet.

~~~
jl6
I once worked on a Finance project which had grand aspirations and decided it
was going to Do Things Right by starting with extensive specifications.

The developers insisted on all behaviour being specified and documented before
they would start coding. Of course, a truly exacting specification is
equivalent to code. So the users who had been tasked with describing the
required functionality ended up inventing their own DSL and “coding” the
entire system in Microsoft Word.

Needless to say, they were the only ones who understood the spec. IT cried
foul. Business cried “this is what you asked for!”

Cue months of arguments over what constituted a proper spec, during which the
users essentially taught themselves how to code. The software eventually ended
up being written by transliterating the DSL into actual code.

It worked, but remains to this day an unmaintainable mess.

~~~
vog
So the documentation was simply incomplete, because the DSL, as a language,
was not documented properly. This is why the initial developers were unable to
have it maintained by others.

Essentially the same problem, just on a higher level of abstraction.

Oh, and failing to document DSLs is really a common mistake: No docs, no spec,
no helpful error messages, and so on. Just like the very early parsers or
compilers. But DSLs are really the most important thing to document, as these
are so much harder to get into ... the "simpler" parts of the program are
usually readable and understandable with less effort, even with pure code and
no docs at all.

~~~
vog
To those who downvoted: Do you care to elaborate?

What's wrong with demanding to document a DSL?

~~~
lostcolony
Well, the DSL flowed out of documenting the problem. Having non-technical
people write a DSL, and then proceed to document that DSL, is not really
addressing the core problem which was knowledge transferrence. Why do you feel
they'd be better able to document a DSL than they were documenting the domain?

~~~
vog
The whole purpose of a DSL is to make the whole system simpler, by separation
of concerns.

That is, the DSL as a language is still much simpler (fewer data types, fewer
elements, fewer rules, etc.) than the whole application, which is built
_using_ that DSL.

So I'd expect the DSL's documentation to be short and targeted at the people
writing within that DSL.

If the DSL's documentation is more complicated than the original problem
(spec), it failed at its purpose.

BTW, ultimately you have a chain of languages, such as:

    
    
        Spec <- DSL <- Meta-DSL <- ... <- programing language
    

But in the end, that chain goes from complex/specific to simpler/generic. So
the documentation effort should shrink dramatically from one step to another
(or your system design is seriously flawed). Usually, the Meta-DSL or Meta-
Meta-DSL is already the plain, generic programming language you are using. And
that one requires no documentation writing at all, because is already
documented and widely understood.

------
userbinator
_More importantly, even after the fact, they’re hard for ordinary security
researchers to access. Go ahead and google for the IETF TLS or IPSec
specifications — you’ll find detailed protocol documentation at the top of
your Google results. Now go try to Google for the 802.11i standards. I wish
you luck._

The first result for "802.11i" is the Wiki page for IEEE 802.11i-2004, which
mentions that it's incorporated into 802.11-2007, and if you search for
"802.11-2007", the first result at the top (after the amusing calculation that
802.11 - 2007 = -1 204.89) is the PDF of the full standard.

...and I'm not even a security researcher. But I agree with the rest of the
criticism of the IEEE and the 802.11 standard in particular, once you've
acquired it.

One of my pasttimes is seeking out and reading standards for protocols, file
formats, and other things; and so I've seen quite a few. As an overall
impression: IETF's are very readable, most of the ITU ones are pretty good if
somewhat terse, ANSIs and IEEEs vary widely between "a little bit of effort"
and "I feel like my brain is melting if I read more than a paragraph an hour",
and 3GPPs along with BlueTooth are very much in the "take a 10 minute break to
digest after every sentence or two" category. 802.11 is also like that. The
acronym density in that document is one of the highest I've ever seen.

Maybe KRACK will at least make them consider editing their standards and
formatting them to be somewhat less of a chore to understand; things like
[https://files.catbox.moe/xym9dq.PNG](https://files.catbox.moe/xym9dq.PNG)
should really be put into tables.

~~~
thezilch
And then he wrote...

 _The IEEE has been making a few small steps to ease this problem, but they’re
hyper-timid incrementalist bullshit. There’s an IEEE program called GET that
allows researchers to access certain standards (including 802.11) for free,
but only after they’ve been public for six months — coincidentally, about the
same time it takes for vendors to bake them irrevocably into their hardware
and software._

In other words, it's getting better, but vendors are burning silicon by the
time researchers have the time to even crack open whitepapers -- too late.

~~~
colejohnson66
Why is there a delay at all? If they’re a security researcher, it would make
sense to allow them access as soon as possible.

------
vikiomega9
I don't understand how the attacker can block step 3 of the handshake from the
client. Can someone ELI5?

What I was able to understand so far is that the use of a particular nonce is
being forced on the client and given that invariant keystream one can decrypt
known messages. I'm still fuzzy on how the attacker can force this step.

EDIT: Further question, isn't timestamp synchronization taken into account
here when invalidating a nonce? What happens when I disconnect from wifi to a
mobile network and back to the wifi?

~~~
cesarb
From what I understood, there are two ways to block step 3. The most obvious
way is to jam it, that is, send noise at the same time so the radio fails to
receive it. The other way (and the one which makes attacks easier) is to
pretend to be the AP but in another channel.

Suppose the real AP is on channel 1. The attacker is nearer the victim than
the AP, and is on channel 6. The attacker repeats on channel 6 everything the
AP sends on channel 1, and repeats on channel 1 everything the victim sends on
channel 6. The victim sees the same AP on both channels, channel 1 and channel
6 (the attacker modifies the part of the AP beacon/responses which says "I'm
on channel X"), which is a perfectly legitimate and normal thing, and chooses
channel 6 because it has a stronger signal.

Since now the attacker is in the middle, it can modify anything. Change the AP
beacon to say "I'm on channel 6", drop any packet it wants, duplicate any
packet it wants, and so on.

> What happens when I disconnect from wifi to a mobile network and back to the
> wifi?

The wifi negotiation starts from scratch, with a new step 1.

~~~
vikiomega9
So it sounds like if the user knew which channel were legitimate they could
potentially realize which AP is the real one?

------
agentultra
From TFA

 _" And separately, to answer a question: how did this attack slip through,
despite the fact that the 802.11i handshake was formally proven secure?"_

Implies that the formal verification failed.

Yet from the paper on the attack:

 _" Interestingly, our attacks do not violate the security properties proven
in formal analysis of the 4-way and group key handshake."_

This is a good thing! One of the hard things for software developers to do is
separate the theorem (spec) from the proof (implementation). I can see how the
article author would posit such a question.

The paper answers the question.

What do we do about it? More theorems, modelling, and proofs. Research on
synthesizing the implementation from its specification. Treat events like this
as we treat auto-collisions and correct the processes, tools, and technology
that enable attacks like this to occur in our systems... at least that's my
0.02. :)

------
cryptonector
_This whole process is dumb and — in this specific case — probably just cost
industry tens of millions of dollars. It should stop._

Bingo.

A pay-for-play standards development organization should charge to
_participate_ in the standards-setting activity, and NOT charge the public for
access to the standards.

The ITU-T seems to have learned this, at least as to some things (e.g., the
ASN.1 family of standards, such as x.680 and x.690). The IEEE should do the
same.

Better yet, they should look at the IETF model, which has been working for
_decades_. In the IETF model there is no charge at all, except for attending
physical meetings. Mailing list participation is free. RFC publication is
free. The IETF is financed via meeting fees and donations. Vendors have an
interest in the IETF staying afloat, so they see to it -- their interest is,
of course, the IETF's overall low cost to them (by comparison to OASIS, IEEE,
ANSI/ISO, or the ITU-T), and the amount of review their specifications get.

Maybe 802.x dev should move to the IETF lock stock and barrel, you might say,
but there is a problem: the IETF doesn't have a lot of expertise with physical
layer protocol specifications. _Most_ IETF participants are at layer 2 and up.
Of course, this can be fixed by... just moving all the 802.x work (and the
people working on it) to the IETF.

EDIT: Mind you, getting the work done at the IETF would not be a guarantee of
no such bugs. It would address the procedural and public access problems TFA
talks about. But that alone is a huge improvement over using the IEEE for
highly consequential specifications that greatly affect the public.

~~~
pc2g4d
I recently found the need to understand the 802.11 standards in detail and was
shocked to discover how difficult it is to access IEEE standards. I even work
for $BIGCORP, with institutional access to various IEEE publications, but
802.11 isn't part of our subscription. I'd venture a guess that much of
802.11's security is by way of obscurity.

------
cesarb
> There’s an IEEE program called GET that allows researchers to access certain
> standards (including 802.11) for free, but only after they’ve been public
> for six months

Also, that program only allows access to the latest release of each standard.
Which means that, when there's a new release of a standard, access to any
version of it is closed for six months.

------
cyberferret
Just to clarify a question I had when reading about KRACK - If you are using a
VPN over WiFi, you still have some degree of safety, right? Any way that the
KRACK vulnerability can be elevated to sniff and decrypt VPN packets in
transit?

~~~
manfredo
A properly working VPN should still maintain privacy even if an attacker is in
complete control of your modem. The data is encrypted from your device all the
way to a VPN server. Conceivably, they could redirect traffic to an
alternative malicious VPN but that should fail authentication.

(somebody let me know if I'm wrong in this)

~~~
ktta
You are right, but only for the perfect 'VPN'. There are also many insecure
VPNs out there, which don't cover all your bases (for ex: VPNs that don't
tunnel DNS requests through the VPN is a common mistake)

So while there are VPNs with great security, you have to make sure your VPN is
not vulnerable to common MITM attacks. So choose your VPN which has been well
vetted. I'm a fan of OpenVPN due to it being able to pass as HTTPS traffic,
but a popular recommendation is algo which is IKEv2 based IPSec VPN.

[https://github.com/trailofbits/algo](https://github.com/trailofbits/algo)

------
z3t4
I love the image with the kitchen drawers ... It passed the linter, it passed
the type checks, it passed the unit tests ...

------
cryptonector
This will provide further impetus for not using CCM/GCM and similar AEAD
cipher modes in any context other than octet stream protocols (e.g., TLS, but
_not_ _D_ TLS).

There is ongoing work to produce AEAD cipher modes that do not fall apart when
{key, nonce} pairs are reused (for different message plaintexts, naturally).

Crypto is tricky...

It's easy enough to construct AEAD cipher modes by generic composition that
don't have this problem. For example, the Kerberos enctypes don't.

The key is to construct AEAD cipher modes that are _efficient_ (Kerberos' add
a block's worth (16 bytes) of "confounder" to each message, bloating it, and
also adds a block's worth of cipher operation, slowing it down) and don't
require additional random numbers if at all possible (those confounders in
Kerberos are random numbers prepended to the plaintext). Also, Kerberos'
enctypes use HMAC for the integrity protection part, which is not a very fast
MAC.

------
a3_nm
One thing I don't understand about this attack is whether it allows the
attacker to connect to the Wifi network (in the style of airmon-ng for WEP),
or whether the attacker can only decrypt packets of legitimate users. Has
anyone figured this out?

~~~
grive
This attack is a MitM. The attacker is able to act as the access point and
receive the victim's traffic, unencrypted.

He is also able to modify this traffic and serve compromised pages.

The attacker needs to have a stronger signal than the legitimate access point.
So he has to stand pretty close to the victim, physically.

~~~
blauditore
But still, this is only problematic if you "trust" an access point. If you
treat any wifi network like a public hotspot (i.e. potentially rogue), there's
not much of a difference, right?

In practice, as long as you only trust data received through TLS, you should
be fine.

~~~
rocqua
Do you not 'trust' your home wifi router?

~~~
blauditore
Well, I don't trust whole the network (internet) in general, as I don't know
where and how things are routed, and by whom.

The only situation where trust in the router would be relevant to me is for
communication within a local network, so I'm controlling every device
involved. And there, this attack might actually be harmful, as far as I
understand.

------
danib31
Definitely another big issue, inherent to cryptography (and maybe matematics
in general), is the subtelty of creating the appropriate definitions.

As the post says, they thought about the individual components, but failed (or
maybe it is just too difficult) to define the security considering
composability of schemes. This is a clear limitation of modern cryptography.

Great post!

------
acqq
Funny how 2013 discoveries are tried to be forgotten and not mentioned:

[https://www.theguardian.com/world/2013/sep/05/nsa-gchq-
encry...](https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-
codes-security)

"$250m-a-year US program works covertly with tech companies to insert
weaknesses into products"

"The documents show that the agency has already achieved another of the goals
laid out in the budget request: _to influence the international standards upon
which encryption systems rely._ " [emphasis mine]

Now compare with the details from KRACK regarding Android and Linux:

[https://www.krackattacks.com/#details-
android](https://www.krackattacks.com/#details-android)

"Our attack is especially catastrophic against version 2.4 and above of
wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
install an all-zero encryption key instead of reinstalling the real key. _This
vulnerability appears to be caused by a remark in the Wi-Fi standard that
suggests to clear the encryption key from memory once it has been installed
for the first time._ " [emphasis mine]

Sometimes adding an innocent-appearing remark, and later acting on it would be
all that's needed for a rich and mighty adversary.

I don't claim it happened this time, but I worry when the possibility isn't
being considered and properly investigated.

------
askvictor
Can someone clarify if wpa2-enterprise with radius auth is affected? I have
seen assertions both ways.

~~~
GenericsMotors
It is affected. Note that this isn't an exploit that allows the attacker to
discover the encryption key or connect to the AP by getting around an
authentication scheme (such as radius).

The attacker impersonates an existing AP and forces the client to reuse IVs /
reset the encryption key to zero (in the case of wpa_supplicant), and is able
to decrypt traffic that way.

~~~
PakG1
Yes, but stupid question. If Radius is being used, there's no way to
successfully impersonate the AP and have the victim accidentally try to join
it because the AP won't be able to authenticate the WPA2-Enterprise
credentials? Then the attack fails? Or silly me, the fake AP could be
configured to somehow accept the login attempt by the victim? But if so, then
it'd be able to record the login credentials thus making the attack's impact
even larger than I've seen discussed, because then not only is the attack
successful in decrypting the victim's traffic, but the victim's Wi-Fi
credentials are also stolen?

~~~
GenericsMotors
> If Radius is being used, there's no way to successfully impersonate the AP
> and have the victim accidentally try to join it because the AP won't be able
> to authenticate the WPA2-Enterprise credentials?

From what I understand the credentials won't matter. Anyone else more
knowledgeable please correct me if I'm wrong, but the attack goes something
like this:

1\. Capture trafic that includes the 4-way handshake

2\. replay message #3 of the handshake

3\. client's encryption key is set to zero (in the case of wpa_supplicant),
and nonce/IV are reused going forward

4\. you are now in control of the encryption key being used (again, only
wpa_supplicant) so you can go ahead and MITM the victim's DNS queries, capture
cookies, etc...

The Details section of the researcher's site explains it pretty well:

[https://www.krackattacks.com/#details](https://www.krackattacks.com/#details)

Lastly, the most urgent task for mitigating this is to patch _client devices_
as quickly as possible.

Android's fractured vendor-specific distributions and lack of long-term
support for the low-mid level models is going to make this a
difficult/impossible task...

~~~
PakG1
Thanks, it's right there in the text, clear as day. :)

 _Note that our attacks do not recover the password of the Wi-Fi network. They
also do not recover (any parts of) the fresh encryption key that is negotiated
during the 4-way handshake._

------
dmitriid
Re-read this article every time when you come across yet another blog post or
article extolling the virtues of formall proofs, verifications, and, while
we’re at it, static typing.

None of these work when taken in isolation and given to actual people to work
with.

~~~
TeMPOraL
On mobile and imgur refuses to work on my Fx, so won't post a screenshot. So
just imagine how funny yours and oconnore's [0] comments look next to each
other...

So, which way is it?

[0] -
[https://news.ycombinator.com/item?id=15488391](https://news.ycombinator.com/item?id=15488391)

~~~
ktta
If you look around, the problem touted here was that formal verification was
done, but independently for two different parts of the standard, in isolation.

The layman answer that is formal verification should've been done on those
systems _after_ integration. I'm not sure how much that would've helped
though, since the proofs for each of those was complex enough. And then actual
code written tends to sway far away from what protocol implementers (also
crypto folks) think it should look like.

So I'd say more formal verification, but also make it easier and accessible
for normal developers without a Math PhD. And verification of _actual code_
would be ideal.

Something I've come across recently is formal verification of cryptographic
implementations not on paper (i.e. mathematically) but in plain C using tools
and languages developed recently.

For example, a three part series on how SAW and Crytol were used to formally
verify s2n (AWS's TLS lib):

[https://galois.com/blog/2016/09/verifying-s2n-hmac-with-
saw/](https://galois.com/blog/2016/09/verifying-s2n-hmac-with-saw/)

[https://galois.com/blog/2016/09/specifying-hmac-in-
cryptol/](https://galois.com/blog/2016/09/specifying-hmac-in-cryptol/)

[https://galois.com/blog/2016/09/proving-program-
equivalence-...](https://galois.com/blog/2016/09/proving-program-equivalence-
with-saw/)

PS(A) for the adventurous: I've also come across a github repo that lists
related stuff

[https://github.com/enzet/symbolic-
execution](https://github.com/enzet/symbolic-execution)

------
oconnore
> In the end we all know that the answer is for humans to stop doing this
> work. We need machine-assisted verification of protocols, preferably tied to
> the actual source code that implements them. This would ensure that the
> protocol actually does what it says, and that implementers don’t further
> screw it up, thus invalidating the security proof.

And yet, there are still regular posts here about whether static type systems
have any merit at all... never mind advanced things like linear/dependent
types, theorem provers, TLA+, etc. Just use Go!

~~~
munin
We did formally verify the 802.11i protocol, though:
[https://link.springer.com/article/10.1007%2Fs12204-009-0122-...](https://link.springer.com/article/10.1007%2Fs12204-009-0122-3?LI=true)

~~~
tom_mellior
Question about this, because the featured article strangely doesn't _actually_
say what the problem is: Did this verification result simply forget/not
consider nonce reuse?

The article seems to imply there's nothing wrong with the proof or the
statement of the properties to be proved, it's about integration with another
component. But if "don't reuse nonces" is a standard security property to
verify, then I would think that that is a hole in the verification.

Could someone shed more light on this?

~~~
kruczek
It is covered in Q&A at
[https://www.krackattacks.com/#faq](https://www.krackattacks.com/#faq) \-
basically the proof didn't cover this particular scenario:

> The 4-way handshake was mathematically proven as secure. How is your attack
> possible?

> The brief answer is that the formal proof does not assure a key is installed
> once. Instead, it only assures the negotiated key remains secret, and that
> handshake messages cannot be forged.

------
Perceptes
Question for the HN mods: I submitted this same article earlier:
[https://news.ycombinator.com/item?id=15483452](https://news.ycombinator.com/item?id=15483452)
Why was this one able to be submitted instead of just redirecting to my
submission?

~~~
tonyztan
I have the same question. I tried to submit this same article last evening and
got redirected to Perceptes' submission. I'm curious as to what happened?

------
qznc
This seems so overhyped? Why do you care about encrypting the step from device
to access point? If you have sensitive data, then you must encrypt end-to-end
anyways, because there are a lot more steps between access point and
destination. Thus, HTTPS or Signal or PGP or whatever is enough and WPA does
not matter.

~~~
mhandley
That might be true if we had secure DNS deployed. But we don't, so using this
attack, DNS cache poisoning is pretty easy. And if you can subvert DNS, you
can redirect HTTPS traffic to a typosquatted version of a website. Unless you
check the URL bar every time you visit an HTTPS website that is in your
bookmarks, you'll probably not notice, and there goes your password in the
clear across a nice secure end-to-end encypted HTTPS connection to the bad
guy.

~~~
NoGravitas
Modern browsers are very vociferous about not connecting to https sites with
certificate errors. So while DNS cache poisoning with this attack is Very Bad,
unless the attacker can insert a bad CA certificate in your browser, or has a
valid but improperly-obtained certificate for the website in question, you're
not going to fail to notice that something janky is going on.

