Live data from Hacker News

Making QUIC Quicker with NIC Offload

dl.acm.org

11–20 of 31 posts

Re: Making QUIC Quicker with NIC Offload

#11
post #10
post #9

Earlier quoted context omitted.

Since NIC is used to encrypt the traffic, it can purposefully have vulnerability that NSA knows about? Fixing NIC is not as easy as fixing software.

Software - eg the Linux kernel - can also contain vulnerability only NSA knows about. In any case, security track record of crypto offload NICs is pretty good.

> Software - eg the Linux kernel - can also contain vulnerability only NSA knows about.

But when it is found, it can be easily fixed

> In any case, security track record of crypto offload NICs is pretty good.

Maybe because the only way to see what it does is to use an electron microscope?

Re: Making QUIC Quicker with NIC Offload

#13
post #12

This gets reinvented as a system matures, I think. IBM mainframes had TCP offload in the early 90's at least. (The NIC in that case was a PC running PS/2 plus some routing software. Worked great.)

and they surely weren't the first to do that either, I assume now.

Re: Making QUIC Quicker with NIC Offload

#14
post #13
post #12

This gets reinvented as a system matures, I think. IBM mainframes had TCP offload in the early 90's at least. (The NIC in that case was a PC running PS/2 plus some routing software. Worked great.)

and they surely weren't the first to do that either, I assume now.

FYI, it's possible to edit comments to add further thoughts. :)

Re: Making QUIC Quicker with NIC Offload

#15
post #9
post #8

Earlier quoted context omitted.

How do you imagine this wiretapping works? This NIC is installed in your servers, and is fed AEAD keys that are derived from key exchange with a client by your TLS stack (and so private keys exist on the host, not on the NIC). This allows the NIC to decrypt/encrypt flows that pass through it and free up CPU cycles. QUIC requires forward secrecy for key exchange, so every flow will use a different AEAD key already, me…

Since NIC is used to encrypt the traffic, it can purposefully have vulnerability that NSA knows about? Fixing NIC is not as easy as fixing software.

To make this vulnerable to third parties not physically in control of the hardware (in which case the PCI bus could just be sniffed for the key, or have it grabbed from RAM). Pretty much the only option is side channels.

They can't change the algorithm or other NICs that don't offload the encryption/decryption wouldn't be able to successfully decrypt it. They couldn't send "extra" packets with the key somewhere else without someone very easily detecting that anomalous traffic not being generated by the system itself.

With QUIC there are almost no-unencrypted fields by design, and those have very firm well defined meanings, so to inject steganographic hidden copies of the key in the packets themselves is infeasible. Maybe you could sneak something out by changing source ports but that's risky, and liable to be detected as well.

So that leaves side channels, which is basically only a timing channel for remote attackers in this case. At the speeds and packet throughput where hardware acceleration of the crypto matters, any buffers in the first switch and/or router that packet hits will remove the precision required for any level of intentional timing attack that could be introduced without detection.

So no it almost certainly couldn't have a vulnerability like that unless the crypto algorithms themselves are broken, in that case this whole discussion is moot as it doesn't matter if its accelerated or not.

> Fixing NIC is not as easy as fixing software

This kind of thing is frequently implemented in FPGAs which can be updated with firmware. The firmware will likely be closed source, but that hasn't stopped people before from fixing firmwares without the original manufacturers knowledge or consent.

It's a lot more work but turns out the people that would be targeted by an attack fall into two categories, those who have the financial ability to pay for a security team to handle these kinds of vulnerabilities in house (or at least mitigate them) and normal people who couldn't bear the brunt of a nation state targeting them even if this one vulnerability didn't exist.

The NSA has been caught doing some seriously shady things we all know that, and no one is going to seriously argue they've stopped trying and developing new things, but it's not even close to reasonable to assume that any paper that has "crypto" present in it is a conspiracy from the NSA or any other intelligence agency.

Re: Making QUIC Quicker with NIC Offload

#16
post #9
post #8

Earlier quoted context omitted.

How do you imagine this wiretapping works? This NIC is installed in your servers, and is fed AEAD keys that are derived from key exchange with a client by your TLS stack (and so private keys exist on the host, not on the NIC). This allows the NIC to decrypt/encrypt flows that pass through it and free up CPU cycles. QUIC requires forward secrecy for key exchange, so every flow will use a different AEAD key already, me…

Since NIC is used to encrypt the traffic, it can purposefully have vulnerability that NSA knows about? Fixing NIC is not as easy as fixing software.

Okay, but I'm asking what does it look like? What kind of vulnerability? They presumably aren't using SuperDuper Secret Wifi to mirror data wirelessly to the moon, right? There are a limited number of outcomes at some point. They can't exactly change the encryption algorithms, otherwise clients fail to connect, and modern TLS (and QUIC) are designed to reduce algorithm agility in the name of preventing downgrade attacks and insecure suites. And they can't just break AES with an alien computer, because if so, why bother with the NIC at all? And again: How do they escrow the data they want out of the network, considering the extremely variable (and potentially secured, unknown, hostile) network conditions? If they can do that with some kind of host exploit or whatever, why not just take private keys in the first place? They could just snip ground cables then and be done with it, which is exactly how they got Google. (The most realistic case I can think of is somehow compromising entropy generation, perhaps.)

And finally, why do any of this when you can almost definitely just issue a gag order to a legal council, or behind-the-door threats to a foreign government agency to tow the line, or any number of things? You're dealing with governments who have immense global influence, not scrappy hackers who only have their wits and old laptops about them.

I'm not saying agencies don't have exploits, or they don't use them, or they don't spy on a lot of data, or that even some backdoors aren't real. But if you're looking a NIC offload device, immediately claim "Wiretapping", and can't actually explain how it wiretaps anything or what the attack model is, it's really just random speculation and fear mongering.

Re: Making QUIC Quicker with NIC Offload

#17
post #9

Earlier quoted context omitted.

Since NIC is used to encrypt the traffic, it can purposefully have vulnerability that NSA knows about? Fixing NIC is not as easy as fixing software.

To make this vulnerable to third parties not physically in control of the hardware (in which case the PCI bus could just be sniffed for the key, or have it grabbed from RAM). Pretty much the only option is side channels. They can't change the algorithm or other NICs that don't offload the encryption/decryption wouldn't be able to successfully decrypt it. They couldn't send "extra" packets with the key somewhere else…

> They couldn't send "extra" packets with the key somewhere else without someone very easily detecting that anomalous traffic not being generated by the system itself.

Why would it matter if the traffic is detected? The companies owning the hardware are usually working with the NSA or compelled to do so, so the extra traffic is expected: https://archive.nytimes.com/www.nytimes.com/interactive/2013...

You can see part of the budget is straight out putting the backdoors in the VPN/web encryption chips design.

Re: Making QUIC Quicker with NIC Offload

#18
post #8

Earlier quoted context omitted.

Wiretapping has been done for years, yes. NOBUS encryption compromise has a long history, and speeds things up a lot. (for the NSA)

How do you imagine this wiretapping works? This NIC is installed in your servers, and is fed AEAD keys that are derived from key exchange with a client by your TLS stack (and so private keys exist on the host, not on the NIC). This allows the NIC to decrypt/encrypt flows that pass through it and free up CPU cycles. QUIC requires forward secrecy for key exchange, so every flow will use a different AEAD key already, me…

If a special packet from the network -- maybe even just an innocuous-looking magic string in plaintext! – ran some undisclosed software on the NIC, how would you know?

If that software then exfiltrated valuable info – session keys, or a digest of hotwords seen, or every string typed into targeted HTML form fields – how would you know? Ask the NIC for a record of all its communication? Do you own separate forensic decryption of every session with every possible-surveillance host it's ever connected to? Monitor the local RF spectrum for intentional leakage to other nearby compromised devices?

I think attempted backdoors in motherboards, OS, and CPU are worth considering, too! Why not all of the above, if the budget & cleverness of your staff allows it?

But proprietary NIC firmware/chips are an especially arcane, independent, essentially-network-connected part of the system. It's a per-machine 'high ground' for observing all traffic, especially if entrusted with all network encryption/decryption, much like how routers and telecom switching centers have also been especially interesting to surveillance hackers.

Re: Making QUIC Quicker with NIC Offload

#19
post #16
post #9

Earlier quoted context omitted.

Since NIC is used to encrypt the traffic, it can purposefully have vulnerability that NSA knows about? Fixing NIC is not as easy as fixing software.

Okay, but I'm asking what does it look like? What kind of vulnerability? They presumably aren't using SuperDuper Secret Wifi to mirror data wirelessly to the moon, right? There are a limited number of outcomes at some point. They can't exactly change the encryption algorithms, otherwise clients fail to connect, and modern TLS (and QUIC) are designed to reduce algorithm agility in the name of preventing downgrade atta…

While I don't think it's likely, it's not hard to conceive a scenario where the NIC purposely weakens the security for attackers in the know.

Purely theoretical (and I'm not a crypto guy, so please do correct me if this is nonsense), but imagine a scheme whereby the IV is chosen to be the first few bytes of the private key xor the port tuple.

This could reduce the difficulty of brute forcing the key, and no extra traffic need be generated - we already know that the NSA operates passive observers, and has even placed such systems inside corporate networks in the past.

EDIT: As to why they'd do this instead of getting a gag order - because they can? Because there's less oversight? Safest to assume that any technical capability will be abused sooner or later.

Post reply on HN