Google open sourced PSP (hardware cryptographic offload) | Hacker News Reader

Google open sourced PSP (hardware cryptographic offload)

cloud.google.com

144 points012345645 comments

> Almost a decade ago, we started encrypting traffic between our data centers to help protect user privacy.

That should be around mid 2013 after Ed Snowden revelations. I remember some frustrated Google engineers on G+ commenting on the leaked slides from NSA where a packet capture of Google cross data center traffic was shown.

SSL Added and removed here! :-)

https://www.washingtonpost.com/world/national-security/nsa-i...

"To support this, we are making PSP open source to encourage broader adoption by the community and hardware implementation by additional NIC vendors. "

...so...no nic vendors mentioned?...what are we supposed to do with PSP but wait for a private company to build a PSP nic?

You don't have an in house ASIC team?! That's ok -- just call your HW provider and have them whip something up to include it when building out your next round of datacenters.

https://www.phoronix.com/scan.php?page=news_item&px=Google-P...

> They have published their architecture specification, a reference software implementation, and a suite of test cases.

Presumably at least one network card manufacturer has already made hardware (or firmware) for google and would be close to making a product for general sale. Now that the spec is out, others can follow.

> it took ~0.7% of Google's processing power to encrypt and decrypt RPCs

This figure is lower than I thought. Granted, I deal a lot with memcache style workloads, where each RPC basically just does some hash table lookup/insert and a memcpy of hundreds of kilobytes. I personally see up to 5% of CPU time spent on cryptographic operations (mainly AES-NI instructions). If you aren't Google and can't afford custom silicon to do hardware offload, but you can't drop the encryption-in-transit requirement either, what would you do to improve performance?

there are off-shelf hardware could do IPsec offload, like intel's QAT, or certain types of NICs (like mellanox cx6).

If you aren't using Linux kernel TLS support already, try it. Obviously it won't help with AES-NI instructions, but it is not rare to see 5% saving by enabling it.

https://www.kernel.org/doc/html/latest/networking/tls.html

TLS uses certificate authorities and a public key infrastructure to ensure the authenticity of a peer. Is authenticity also something PSP provides, or is it focused on confidentiality and integrity?

Great question. The master key of PSP is stored in the NIC and shipped with the device. That's how authenticity is provided. Other than that, it's focused on confidentiality and integrity.

This sounds like literally THE one master key? If google was ever made aware one device was lost or potentially compromised they would replace all devices?

I doubt there's one. Probably each NIC has a separate master key. And they could reduce chance of compromise by loading the key at runtime and making it write-only.

As the PSP arch spec said, it seems each NIC has two master key.

> each NIC has two 256-bit AES keys, called master keys, not shared with any hosts including its own, or with any other NICs. The master keys are "critical security parameters",which are kept ephemerally in on-NIC RAM, and must not be stored on any persistent medium.

I think psp seems to be data center use case only, not really a general VPN tech, so I guess authenticity is not the focus here

>PSP is intentionally designed to meet the requirements of large-scale data-center traffic. It does not mandate a specific key exchange protocol

I take that to mean you do the asymmetric key stuff outside of PSP, then the symmetric key stuff is offloaded to PSP. Assuming you send a lot of data per connection, the symmetric key part will be much larger, so the expensive part is offloaded.

Before anyone gets too excited, this provides a 0.5% reduction in processing power: https://www.phoronix.com/scan.php?page=news_item&px=Google-P...

The number of organizations that this is relevant for is very, very small.

For most organizations, buying slightly more hardware is likely going to make far more sense than the amount of engineering effort required to implement something like this, if only because it's a much simpler, safer bet.

It's a little unfortunate that they chose a name that was already proposed as a L2 encryption method, Packet Security Protocol (one of the first hits I got when I tried searching for any analysis or prior discussion):

https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=938...

To be fair, this is 0.5% of all processing that Google does, not just encryption / decryption.

> it took ~0.7% of Google's processing power to encrypt and decrypt RPCs, along with a corresponding amount of memory.

> As of 2022, PSP cryptographic offload saves 0.5% of Google's processing power.

> TLS also does not support non-TCP transport protocols

eh?

TLS is a record based protocol and you can use it over bits of paper transported by pigeon if you like, can't you? I've looked into it extensively (though not for a few years I'll admit), and I've seen TLS implementations that don't include any transport mechanism - that bit it left to the application. I know that it must receive things in-order, and perhaps that does rule out UDP... but there's DTLS :)

That doesn't mean this isn't interesting, and I have no idea how 'offloadable' TLS or DTLS might be. This scheme seems to use derivable keys, so that packet sequence isn't important, but it looks also like we have a mac-then-encrypt scheme. I presume it's been analysed properly...

Definitely worth digging into.

TCP does not support non-TCP protocols efficiently (since any type of tunneling or encapsulation necessarily enforces at least some TCP semantics on whatever is being tunneled).

> I know that it must receive things in-order

TCP? No, it can handle dropped, duplicated and even reordered packets, but doing so is problematic for many applications (either due to real-time requirements or adverse network conditions that a given TCP implementation doesn‘t handle well).

I feel there's some acronym substitution going on there!

> TCP does not support non-TCP protocols efficiently

I'm going to assume you meant TLS for the first of those :)

> TCP? No, it can handle dropped, duplicated and even reordered packets

And TLS is what I meant here, it generally doesn't like things being out of sequence, and TCP usually at least hides that from the application layer where TLS lives. Which I guess is why it is mostly dependent on TCP, but can be implemented (albeit less efficiently) over other reliable, in-order comms mechanisms.

I did in fact mean TCP/non-TCP over TCP (or more correctly, datagram semantics over TCP)! While this is possible, it usually removes all the performance benefits of using datagrams over streams in the first place.

That's presumably what Google is referring to with their statement about TLS not working well for non-TCP (more precisely: non-stream-semantics) traffic: Encapsulation of datagrams in streams is possible, but very inefficient. That's why VPNs using TCP generally suck for performance sensitive operations. (They usually also do TCP-over-TCP, which is even worse than stream-over-TCP.)

TLS does require stream semantics to work efficiently; its security guarantees don't break in the presence of reordering, duplication or datagram loss, but all of these would be interpreted as active attacks or severe uncorrected lower-layer failures and probably either cause abysmal performance or even application-level errors due to unexpected/unhandled alerts.

And why go through the effort if there is already DTLS, which is to UDP (and other datagram layers) what TLS is to TCP?

Is the ICV the same thing as the authtag? (rhetorical question, I looked at the code: yes it is) I've never seen the authtag/mac for aes-gcm referred to as ICV -- any context on why it's used here? is it a more general term cryptographers use, or is it the new way (or old way) to refer to authtags ?

wrt IV reuse the protocol doc says the NICs use a picosecond timestamp counter -- do NICs really have picosecond resolution clocks, or is it nanoseconds + monotonically increasing counter within the nanosecond?

IPsec calls the tag an ICV too. (see RFC 7296 ss 3.3 for example) It's short for Integrity Check Value.

edit: an even better RFC for this question is 4106 which is about aes-gcm in ESP, it calls the tag an ICV also.

Maybe I'm missing something, but seems pretty brittle to me. From what I can tell, since the decryption key is entirely derived from the information in the PSP header (SA/SPI) a bad actor who observes PSP encrypted packets from some other sender can simply copy that inner packet and the target machine will decrypt it as if it came from that sender.

The document acknowledges this but basically leaves it to other aspects of the network stack to defend against this (maybe there is some extra protection provided by the ICV check). Google's stack seems carefully designed to be secure in this way but it feels brittle.

Wouldn't it have been better to require a checksum of some of the exterior headers (source IP??) inside the encrypted section to block attempts to repackage the same encrypted content inside another packet. Or is that somewhere in there and I'm missing it?

It is a real shame that they couldn't have made this work with/for wireguard.

It sounds like they were working on this before wireguard would have been a viable option.

according to the blog, one key driver for inventing a new protocol is Google wants to do per-connection encryption, (e.g. using different keys for each TCP/UDP connection), I don't think wireguard (which is interface based model) could be easily modified to support that.

I don't see why it couldn't, both sides just need some way to get the key to use for each connection (which is a problem their current solution already has to solve somehow).

That's...exactly how I'd describe Wireguard's paradigm to someone!

Wireguard has different keys for different tunnels/routes (which might be considered virtualized layer 2 interfaces), not per connection (which would be layer 4- or 5-ish).

I'm gonna say if it's a different keypair, and a different origin/endpoint, it's a different connection.

Sharing a config file doesn't make it the same connection — in fact, the whole security model is that it's an easily grouped, but cryptographically ensured separate connection — no?

From the description summary you provided alone, it seems likely that each Connection could get it's own virtual Interface, which would be dynamically created and destroyed and the Session keys exchanged initially with the primary Interface key.

I think what you meant is that its a real shame that wireguard completely refuses to use any common standards, or actual proper networking.

Yeah. Why can't they be just like OpenVPN? Who needs reduced attack surface?

Am I the only one thinking "PlayStation Portable"?

I wonder if this is being released now because it's in Mount Evans.

For others, Mount Evans is a programmable network device: https://www.intel.com/content/www/us/en/products/platforms/d...

It's UDP style, so is it reliable?

>A PSP packet starts with the original IP header, followed by a UDP header on a prespecified destination port, followed by a PSP header containing the PSP information, followed by the original TCP/UDP packet

So it looks like the inner data can be either TCP or UDP. So you have the option of making it reliable or not.

Thanks a lot.

It's UDP style, so is it reliable? Am i wrong?

I was hoping it was Sony.

Title should probably be "cryptographic" to disambiguate from something cryptocurrency related, unfortunately.

Considering emailing the mods about this, since it's (IMO) misleading, as well as heavily editorialized.

Done.

Reply on news.ycombinator.com