KRACK, ROCA, and device insecurity [LWN.net]

By Jake Edge
October 18, 2017

Monday October 16 was not a particularly good day for those who are even remotely security conscious—or, in truth, even for those who aren't. Two separate security holes came to light; one probably affects almost all users of modern technology. The other is more esoteric at some level, but still serious. In both cases, the code in question is baked into various devices, which makes it more difficult to fix; in many cases, the devices in question may not even have a plausible path toward a fix. Encryption has been a boon for internet security, but both of these vulnerabilities have highlighted that there is more to security than simply cryptography.

The ROCA vulnerability affects keys that have been generated on keycards, which is decidedly not an activity the general public has ever heard of, much less knowingly used. There are digital IDs that use keys generated that way, however, so some are being unknowingly exposed to the flaw. The other vulnerability has far more widespread applicability, however: KRACK is a flaw in the WPA2 encryption protocol that is used to secure most WiFi conversations. Both bugs are serious, but here we will focus on KRACK and leave ROCA to another day.

Key reinstallation attacks

Mathy Vanhoef discovered the WPA2 flaws, which center around a way to cause clients to reinstall the keys used to encrypt the traffic; thus the name comes from key reinstallation attacks, yielding KRACK. As is de rigueur for security vulnerabilities these days, KRACK has its own logo and web page.

When a client connects to an access point (AP) using WPA2, there is a four-way handshake that is done to establish a key to be used for the session. That handshake is encrypted using the shared secret (i.e. the WPA2 password) so a man in the middle should not be able to see the contents (which include the session key). It turns out, though, that the attacker doesn't need to see inside the packet; instead they can simply cause part of the handshake to be replayed, which will allow breaking the encryption from the client.

If the acknowledgment for the third message of the handshake gets lost (or is blocked by an attacker), the AP will resend that third message. That will cause the client to reinstall the key and, crucially, to reset its initialization vector (or "nonce") back to zero. The ciphers used by WPA2 are susceptible when nonce values are reused, so the protocol arranges that each packet gets a new nonce by incrementing a packet counter. Unfortunately, that packet counter gets reset to zero when the "new" key is installed. Worse yet, in some implementations, including all Android versions since 6.0, the client's copy of the key will have been cleared after it was installed into the network interface. The replayed third message will then result in the cleared key replacing the previously installed key, causing subsequent encryption to be done with an all-zeroes key.

As detailed in Vanhoef's paper [PDF], the problem is in the WPA2 protocol itself and is not a bug in the implementations. Even the key clearing in wpa_supplicant versions 2.4 and 2.5 (which ended up in Android) "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", he said. One of the root causes of the problem is a poorly specified protocol that was created behind closed doors. As cryptographer Matthew Green put it:

If you're looking for someone to blame, a good place to start is the IEEE. To be clear, I'm not referring to the (talented) engineers who designed 802.11i — they did a pretty good job under the circumstances. Instead, blame IEEE as an institution.

One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. 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.

He went on to point out that the IEEE has taken a few steps in the right direction to fix the problem, but that those steps are "hyper-timid incrementalist bullshit". The specifications are now available once they have been public for six months, "coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software". Beyond that, the standards are poorly specified and lack a formal description of the handshake state machine, which requires developers to "implement their code using scraps of pseudocode scattered around the standards document". That pseudocode leads directly to being vulnerable to KRACK.

Green also points out that those implementers bear some of the responsibility, particularly for the key clearing in wpa_supplicant:

One of the truly terrible things about KRACK is that implementers of the WPA supplicant (particularly on Linux) managed to somehow make Lemon Pledge out of lemons. On Android 6 in particular, replaying message #3 actually sets an all-zero key. There's an internal logic behind why this happens, but Oy Vey. Someone actually needs to look at this stuff.

Even though the four-way handshake and encryption scheme have been "proven" under various conditions as far back as 2005, Green said, those analyses did not take into account the integration of the handshake and the encryption. Each was separately proven to do the right thing, but the two were not analyzed together. He likened it to the "two unit tests, zero integration tests" meme.

Effects

With KRACK, a suitably positioned attacker could read the traffic being sent by a client to the AP. That traffic could contain various kinds of sensitive information but, in practice, it probably doesn't have all that much of interest. The ubiquity of HTTPS, SSL/TLS, and other layers of encryption (SSH, for example) for much of the traffic carried on networks these days makes KRACK somewhat less dangerous than it might first appear. Though, as Vanhoef notes, there have been various attacks against HTTPS along the way—there are sure to be more down the road.

Other attacks are possible, as well. A TCP connection could be hijacked and data could be injected into the session, for one thing. There are also three different handshakes that can be attacked under various circumstances. One of those can be used to get an AP to reinstall its key, which could then be used to decrypt traffic from the AP to the client. Injecting traffic in that direction could allow all kinds of nastiness.

KRACK is clearly a critical vulnerability that requires updating affected systems as quickly as possible. There is some traffic that is not further encrypted being carried on most WPA2 sessions; DNS queries, for example, might well contain information a user would rather not disclose. Injecting bogus DNS replies could also be highly problematic. Updating should be relatively straightforward for users of various desktop operating systems—wait for the vendor to release a fix (which most have done) and install it. The same goes for most "recent" mobile phones. Upgrading other WiFi devices may not be as easy—or even possible—for millions of devices.

Untold numbers of mobile phones, Internet of Things (IoT) devices, and other gadgets use WiFi (and WPA2) to communicate. Phone handsets typically have the best story regarding upgrades, in that they at least have the ability to be upgraded, but many existing phones are no longer receiving updates because their manufacturers deem them to be too old. Other devices may not even have a way to inform their owners that an upgrade is needed—or have no easy way for the owner to do an upgrade. As a Wired article said, it will take decades to clean all of this up.

It is a fairly bleak picture from a number of different viewpoints. One almost amusing outcome of this mess is contained near the end of Vanhoef's KRACK web page. He notified OpenBSD of the flaw in mid-July with an embargo (at the time) until the end of August. OpenBSD leader Theo de Raadt complained about the length of the embargo, so Vanhoef allowed OpenBSD to silently patch the flaw. "In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo." That might not quite be the outcome De Raadt was hoping for with his (quite reasonable) complaint, especially given that Vanhoef strongly hints that there are other WiFi vulnerabilities in the pipeline.

Index entries for this article
Security	Encryption/Vulnerabilities

to post comments

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 0:34 UTC (Thu) by bojan (subscriber, #14302) [Link] (21 responses)

> Upgrading other WiFi devices may not be as easy—or even possible—for millions of devices.

In the age of the internet, selling network connected devices that cannot be easily updated (either automatically or manually) should be made illegal, IMHO. If major markets, such as USA, Europe and the rest of developed world enacted such regulation, the cowboys would either perish or would have to get their act together.

Where I live, you cannot buy a car without seat belts. If you don't use them, you get fined. Why should devices that can potentially cause people's money and private information to get stolen be any different?

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 2:37 UTC (Thu) by jkingweb (subscriber, #113039) [Link]

I'm not sure seatbelts are the best analogy, though I certainly agree with the general sentiment. Certainly if devices must follow FCC guidelines not to cause harmful interference, it's reasonable that they should be hardened against recruitment into botnets used for DDoS attacks---surely a form of harmful interference.

Have security updates been demonstrated to save lives more or less directly like seatbelts have? In medical devices, I suppose?

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 6:57 UTC (Thu) by eru (subscriber, #2753) [Link]

Your proposed law would also have the positive effect it would make manufacturers think twice before adding network connectivity to devices that do not really need it: Making the device upgradeable, and providing upgrades has a cost.

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 7:04 UTC (Thu) by pabs (subscriber, #43278) [Link] (17 responses)

That isn't going to help for companies that went out of business or have short security support cycles, their devices will still be out there on people's networks, participating in the latest botnets etc.

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 7:35 UTC (Thu) by marcH (subscriber, #57642) [Link]

Software is a service. Buying a service from an unstable company is and has always been a well-known risk. Nothing new here besides the ignorance by some people that they are buying a service and the illusion to perform a once-off, hardware purchase instead. This type of illusion will pass; stories like this one and unmainted smartphones are making sure of that.

Insurance

Posted Oct 19, 2017 13:54 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (9 responses)

_If_ that became a problem (and maybe it wouldn't) we have seen this solved for services that routinely go out of business leaving thousands of customers inconvenienced. The usual model is something along the lines of some form of mandatory insurance and the state steps in to actually administrate things using the money from that insurance. Good actors in an industry are neutralised, if they're really at no risk then they will surely obtain insurance very cheaply with no fuss, if they struggle to get insurance then it suggests they're a bad risk after all.

Two UK examples:

1. When a small bank fails, the government gives all its personal customers their money back (in theory up to a limit per customer, but in practice it has always been everything) and the remaining industry has to pay them back. This creates a "Last Man Standing" insurance without actually paying premiums etcetera, and it creates an incentive for big banks to tattle on small banks with risky practices to the regulator, because if they wait and let it fail they'll eat all the costs.

2. Package holiday companies have to join an industry scheme with insurance. No membership? It's illegal to sell holidays that include separate elements like flights and hotel booking bundled together and of course members have a powerful incentive to ensure this is enforced. So, when inevitably lots of these companies go broke each year the insurance pays out and makes sure nobody is left abandoned on some Greek island or arrives to find there's no hotel.

In the case of networked devices I'd imagine that some sort of code escrow would be involved, so when a business fails and can't/ won't ship security fixes the escrow gets unlocked, the insurance pays out and some fleet of maintenance programmers are paid to airdrop in and fix things. Deciding how much we, as a society, are willing to pay for that is just a numbers game. If we want it, we can have it.

Insurance

Posted Oct 19, 2017 15:47 UTC (Thu) by NAR (subscriber, #1313) [Link] (2 responses)

There are two small problems with your example:

1. These are (local) services. The (local) government could (more) easily regulate theme and you can't "buy" these services after they go out of business. So for example if I put my money into a foreign bank, the insurance in my home country will not cover me. I actually did have an account at a bank which was registered in a foreign country and they mentioned in all of their communication that my money is not covered by the local insurance (it was covered by the insurance of the foreign country). Also I can't go into a bank office after the bank shut down. On the other hand IoT devices are usually made in a different country and it is very much possible to find a device on the shelf of a local store where the maker is already out of business and thus no longer paying insurance.

2, These insurances increase the hurdle to enter the market. In the case of banks, it's probably not a bad idea. For holiday companies - I don't know. Here they don't have insurance (as far as I know), so from time to time there are news of some poor souls who are stranded somewhere. On the other hand the clients can (and maybe should) insure themselves. My wife is starting a (very) small business where an insurance is compulsory - and it's a real hurdle because initially it takes about 10% of the income (not from profit, from income).

Insurance

Posted Oct 20, 2017 16:32 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

The use of insurance is appropriate when businesses keep failing. If your wife's business is in a sector where new businesses routinely fail and leave personal clients out of pocket, well, I appreciate that it's tough finding the money but wider society has to prioritise ensuring nobody gets screwed over the inconvenience for your wife. In fact arguably the insurance, though expensive, is helping her because without it clients would have to assume her new untested business is likely to fail and stay away.

The idea that clients should insure themselves is inefficient. It can work when clients are all or mostly corporations, though it will usually be inefficient even then. But for ordinary consumers it's ludicrously inefficient. The acquisition costs per customer may be slightly lower, but the insurance has many more customers, so overall a lot more resource is wasted. Where possible laws should put insurance requirements onto the larger entity which will usually be the supplier.

We _could_ say that everybody living in my building needs to take out an insurance policy in case the building burns down. If it happens, the insurers all pay out, together we buy a new building, everything is fine. But that's very inefficient. What actually happens is much better, the building's owner (maybe all the residents jointly, in my case a brass plate company in a tax haven) has to buy insurance and post proof to all residents, and they bill everybody for a share of the insurance along with the other costs of running the building, like elevator maintenance and painting the corridors.

The US has a lot of deliberately anti-competitive policies which can give the idea of regulation a bad name, rather than compete by offering a better service it turns out it's cheaper to "persuade" politicians to pass a law saying nobody is to compete with you, or indeed not to pass a law which would render you obsolete (title insurance, tax filing, and dozens of other things that needn't exist but still do because the campaign donations roll in from those selling them). So I'm not suggesting that every type of business ought to have insurance against the consequences of failing, just that it's a sensible remedy if an industry has this persistent problem the way that banks, and package holiday companies do, and the other poster suggested IoT manufacturers might.

Insurance

Posted Oct 22, 2017 1:25 UTC (Sun) by ssmith32 (subscriber, #72404) [Link]

But a hurdle to enter the market isn't a bad thing - especially if you're not ready or willing to cover the long-term effects you might have on society. If you're not willing to pay a price to help protect society against the damages you may cause if you fail, I see a hurdle as a good thing, not a bad.

Externalities are a real thing.

Not Insurance, Liability

Posted Oct 19, 2017 16:09 UTC (Thu) by kh (guest, #19413) [Link] (5 responses)

Product Liability law is the real fix. If you sell hardware that cannot get security updates, you should be held liable.

https://blog.valbonne-consulting.com/2015/07/24/cybersecu...

Dan Greer's talk on software liability - excerpt, quoted text below:

-----------------[Quoting]--------------

"[Software vendors]... must live with normal product liability, just like manufactures of cars, blenders, chain-saws and hot coffee.

How dire the consequences, and what constitutes "used normally" is for your legislature and courts to decide, but let us put up a strawman example:

A sales-person from one of your long time vendors visits and delivers new product documentation on a USB key, you plug the USB key into your computer and copy the files onto the computer.

This is "used normally" and it should never cause your computer to become part of a botnet, transmit your credit card number to Elbonia, or copy all your design documents to the vendor. If it does, your computer's operating system is defective."

------------------
3. Source code liability -- CHOICE

Nat Howard said that "Security will always be exactly as bad as it can possibly be while allowing everything to still function," but with each passing day, that "and still function" clause requires a higher standard. As Ken Thompson told us in his Turing Award lecture, there is no technical escape; in strict mathematical terms you neither trust a program nor a house unless you created it 100% yourself, but in reality most of us will trust a house built by a suitably skilled professional, usually we will trust it more than one we had built ourselves, and this even if we have never met the builder, or even if he is long since dead.

The reason for this trust is that shoddy building work has had that crucial "or else ..." clause for more than 3700 years:

If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death.
-- Code of Hammurabi, approx 1750 B.C.

Today the relevant legal concept is "product liability" and the fundamental formula is "If you make money selling something, then you better do it well, or you will be held responsible for the trouble it causes." For better or poorer, the only two products not covered by product liability today are religion and software, and software should not escape for much longer. Poul-Henning Kamp and I have a strawman proposal for how software liability regulation could be structured....

Not Insurance, Liability

Posted Oct 20, 2017 13:45 UTC (Fri) by jospoortvliet (guest, #33164) [Link] (4 responses)

Liability is useless if the company goes bankrupt. And bankruptcy is an often used way to get out of liability that even bigger companies use - put the liability on a small subsidiary, and done.

So it would help, a bit, against Microsoft and other large companies, though THEY of course can extend court cases far beyond what a small business or home user could sustain - again leaving those without recourse.

Last but not least, it is becoming common practice to put enforced arbitrage in contracts and unless the courts step up against that (most don't) this kills any serious liability risks.

I don't disagree that adding liability to software is a good idea. I just don't think it solves all problems ;-)

Not Insurance, Liability

Posted Oct 22, 2017 1:29 UTC (Sun) by ssmith32 (subscriber, #72404) [Link] (2 responses)

Yeah, but that's just because the way the law is structured, you can avoid all kinds of personal responsibility by incorporating. The solution would be personal liability, not corporate liability.

Not Insurance, Liability

Posted Dec 14, 2017 0:46 UTC (Thu) by immibis (subscriber, #105511) [Link] (1 responses)

That's dangerous territory too.

Personal liability means that, if the damages work out to many hundreds of thousands of dollars, the government can take away my house to pay them. Under those conditions you'll find a lot less people willing to release software. Or the price will massively increase to cover the required insurance. Free software would not be a thing either.

Not Insurance, Liability

Posted Dec 14, 2017 15:51 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> Personal liability means that ... you'll find a lot less people willing to release software ... Free software would not be a thing

There would have to be standards and licencing, so that there would be clear expectations on _both_ sides of what is acceptable practice, but if you are responsible for causing someone harm is it really a bad thing to have liability for your actions. The devils are in the details though because nothing is without boundaries, you can't have infinite liability and the user has some responsibility to use the tools properly, just like in Civil Engineering practice. Free software may not be impossible in that environment but it depends on the exact rules and policies which make that environment happen.

Not Insurance, Liability

Posted Oct 26, 2017 8:35 UTC (Thu) by Wol (subscriber, #4433) [Link]

> Last but not least, it is becoming common practice to put enforced arbitrage in contracts and unless the courts step up against that (most don't) this kills any serious liability risks.

In the UK (and Europe) this is one-sided :-) The company *must* abide by the arbitrage, unless the customer decides to sue instead. (And we've also got "unfair terms and conditions" so if the arbitrager or Judge thinks the arbitrage is loaded in favour of the company they can just ignore the contract ... :-)

Cheers,
Wol

KRACK, ROCA, and device insecurity

Posted Oct 28, 2017 10:05 UTC (Sat) by ras (subscriber, #33059) [Link] (5 responses)

Interestingly, we have a law in Australia that says - well I'm not sure what it says, but it boils down to manufactures can't sell you a defective product. Warranty doesn't come into it - if it is defective, the manufacturer has to repair or replace it, no matter how old.

There are obviously blurry lines, but to give an example if a battery stop holding charge outside of it warranty period that's your problem. But if it swells and looks like it might explode, it's the manufacturers problem - even if it's outside of the warranty period. You don't have to sue a supplier to enforce this - the government does it for you.

I've never heard of it being applied to software, but I imagine it's just a question of time.

KRACK, ROCA, and device insecurity

Posted Oct 28, 2017 22:55 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (4 responses)

How's that work with things that are licensed, not sold? Or is that practice illegal down there too?

KRACK, ROCA, and device insecurity

Posted Oct 29, 2017 12:02 UTC (Sun) by ras (subscriber, #33059) [Link]

I don't know for certain.

My guess is if you talking about a yearly licence for software like say Microsoft Office, it doesn't apply. If you are talking free software it doesn't apply because the expectation of quantity is determined by the price (a $2000 monitor is expected to last longer than a $200 one) [0] . But f you talking about manufacturer selling you a router, then claiming the router isn't covered by this provision because you don't own the software or the software inside is open source - I'd say they don't have a hope.

This isn't as radical as it sounds. For example, Dell just contacted me to say they are replacing the battery in my laptop because it may have a manufacturing defect. Car manufacturers regularly do out of warranty recalls. Yubico is replacing the broken Yubikey 4's. In other words: companies that care about their reputation do this without prodding. The difference in Australian is all companies have to behave like they plan to be in business in 10 years time.

It does change your perspective. It obviously doesn't apply when say you purchase on ebay from an overseas seller who is beyond the reach of Australian law. Back in the day, it used to be fashionable to brag about the great deals you got that way. (Australians can get things cheaply doing that because Asia is on our doorstep). But the wheel has turned - most people who buy online regularly have been bitten by overseas sellers and now "Australian Seller, with an Australian Business Number" can now can happily command a price premium. You know it will do what it says on the box, and if it is at the upper end of the price range it will be at the upper and of the quality spectrum too. Simple assurances like this really does help in making commerce frictionless.

[0] http://www.news.com.au/finance/e806700959101b117f16d7c265...

KRACK, ROCA, and device insecurity

Posted Nov 15, 2017 4:09 UTC (Wed) by ras (subscriber, #33059) [Link] (2 responses)

It's a bit late now for anyone to notice, but this is an example of Australia's consumer protection laws and government agencies in action. This is a home page of a computer retailer (like newegg I guess). It will have the government mandated notice you can see there displayed for a few months:

http://www.msy.com.au/

It doesn't stop people from shopping there as obviously they aren't going to make the same mistake again in a hurry. A long while ago HP made the same mistake of not honouring their warranties in Australia. Seeing that notice on HP's main page is something I will never forget.

KRACK, ROCA, and device insecurity

Posted Nov 18, 2017 3:48 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

Interesting. The list of claims isn't loading here, but that is an interesting notice (especially with it loading sans JS). That's still hardware though. Has anyone been able to get it for software that was prematurely EOL'd? Android manufacturers? IoT crap (or is it still too early for that)?

KRACK, ROCA, and device insecurity

Posted Nov 18, 2017 7:52 UTC (Sat) by ras (subscriber, #33059) [Link]

> Has anyone been able to get it for software that was prematurely EOL'd? Android manufacturers? IoT crap (or is it still too early for that)?

Not that I know of. But we haven't have the equivalent of Samsung bricking all their new TV's here, yet alone that followed by someone making that mistake and then refusing to fix it.

In reality it will have to be something expensive before the ACCC steps in, a $100 router it unlikely to trigger their interest. My guess is IoT is safe until they are actually become dangerous.

KRACK, ROCA, and device insecurity

Posted Oct 22, 2017 15:32 UTC (Sun) by NAR (subscriber, #1313) [Link]

"selling network connected devices that cannot be easily updated (either automatically or manually)"

I see one problem here: do I want to care about upgrading the software in my WiFi-enabled "smart" light bulb? Although I don't actually have one, but my guess is most users would absolutely not want to care about this. I think they want to install it, then forget that there's WiFi in that gadget, just enjoy the "magic". Even I don't want to care about the software in my WiFi router. So I don't think manual upgrade would solve this. Automatic upgrades (i.e. devices "calling home") on the other hand would cause outrage in the privacy-conscious population - and these can have their own security problems. A smart bulb can't even notify the user with a popup that "hey, upgrade me!" - maybe should morse-code this message after each time it's turned on?

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 4:36 UTC (Thu) by eternaleye (guest, #67051) [Link] (4 responses)

> The ROCA vulnerability affects keys that have been generated on keycards

Note that it's not just keycards - Infineon-made TPMs, such as are in many Linux laptops, are also affected.

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 4:38 UTC (Thu) by eternaleye (guest, #67051) [Link] (3 responses)

...well, many laptops _period_ really. Incidentally, Windows BitLocker uses the TPM to seal the disk encryption key...

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 15:23 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Chromebooks also use it for the platform key. Fixing the weak keys on Chromebooks requires losing all your personal data. God knows how (or even if) you can fix a BitLocker-encrypted drive encrypted with a weak key.

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 15:24 UTC (Thu) by nix (subscriber, #2304) [Link]

Obviously I meant all your *locally-stored* personal data. (On Chromebooks that's a fairly important distinction!)

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 15:34 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Depends on your threat model. If nobody's had a chance to extract key material from your system, simply re-encrypt the aes key with a good rsa key and shred the old key blob.

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 7:05 UTC (Thu) by pabs (subscriber, #43278) [Link]

This website is a great resource for device/firmware security news, especially around UEFI:

https://firmwaresecurity.com/

KRACK, ROCA, and device insecurity

Posted Oct 19, 2017 7:06 UTC (Thu) by pabs (subscriber, #43278) [Link]

Incidentally, there is an Ask Slashdot on this topic just posted:

https://ask.slashdot.org/story/17/10/18/212252/ask-slashd...