Google open sourced PSP (hardware cryptographic offload)

https://cloud.google.com/blog/products/identity-security/announcing-psp-security-protocol-is-now-open-source

by 0123456 • 4 years ago

144 45 4 years ago

cloud.google.com

SEJeff• 4 years ago

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

remus• 4 years ago

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

hujun3• 4 years ago

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.

cmeacham98• 4 years ago

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).

aaaaaaaaata3• 4 years ago

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

mjevans• 4 years ago

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.

ikiris• 4 years ago

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

aaaaaaaaata3• 4 years ago

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

joshuamorton• 4 years ago

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

cglong• 4 years ago

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

01234562• 4 years ago

Done.

wmf2• 4 years ago

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

deadmutex• 4 years ago

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

matthewaveryusa• 4 years ago

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?

sophacles2• 4 years ago

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.

allanrbo• 4 years ago

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?

01234562• 4 years ago

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.

yakak• 4 years ago

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?

hujun3• 4 years ago

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

Thorrez3• 4 years ago

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.

nimbius• 4 years ago

"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?

sophacles2• 4 years ago

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.

KennyBlanken2• 4 years ago

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.

mattZhang3• 4 years ago

It's UDP style, so is it reliable?

Thorrez3• 4 years ago

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.

mattZhang3• 4 years ago

Thanks a lot.

KennyBlanken2• 4 years ago

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...

vitus• 4 years ago

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.

kccqzy• 4 years ago

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?

hujun3• 4 years ago

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

sanxiyn• 4 years ago

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

Nursie2• 4 years ago

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.

lxgr2• 4 years ago

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).

Nursie2• 4 years ago

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.

oxplot• 4 years ago

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.

Thorrez3• 4 years ago

SSL Added and removed here! :-)

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

spinaltap• 4 years ago

Am I the only one thinking "PlayStation Portable"?

mattZhang3• 4 years ago

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

TruePath• 4 years ago

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?

musicale• 4 years ago

I was hoping it was Sony.

Google open sourced PSP (hardware cryptographic offload)

Related Stories