Application Layer Transport Security (ALTS) is a Google-developed authentication and transport encryption system used for securing Remote Procedure Call (RPC) within Google machines.[1] Google started its development in 2007, as a tailored modification of TLS.[2]

Background

ALTS, similar to TLS, was designed specifically for Google’s data centers and relies on two protocols, Handshake and Record.[3] Google began developing ATLS in 2007 in order to create a security system solution for the company’s infrastructure.[4]

The ALTS whitepaper[2] was published in December 2017. At that time the dominant Application layer protocols were SSL and TLS 1.1 (TLS 1.2 was only published as an RFC in 2008[5]), those supported many legacy algorithms and had poor security standards. As Google was in full control over the machines that needed secure transport of RPCs, deployment of systems was relatively easy, and so Google developers could afford designing their own system from scratch.

Another requirement that deemed a new system necessary is different trust models: in TLS, the server side is committed to its own domain name (and corresponding naming scheme), while Google needed the same identity (i.e. RPC) to be used with multiple naming schemes, in order to simplify microservice replication, load balancing and rescheduling between hosts.

Details

Handshake protocol

The ALTS handshake protocol is based on authenticated Diffie-Hellman key exchange scheme, and supports both perfect forward secrecy (access to current keys does not compromise future security) and session resumption (noticeable speedups in the protocol after the first session between the parties).

Unlike TLS, in ALTS both parties — server and client — have a certificate proving their respective identities. The certificate chains to a trusted signing service verification key, with the leaf being an Elliptic curve Diffie-Hellman key, that is eventually used for key exchange. The elliptic curve used in the key exchange is Curve25519.[6]

The handshake protocol consists of four messages, sent in plaintext:

  • ClientInit, initiated by the client, and contains the client's certificate, list of available cipher suites, and a session resumption attempt;
  • ServerInit, sent by the server as a response, and contains its own certificate, chosen cipher suite, and optionally an encrypted resumption ticket;
  • ServerFinished, sent by the server (concatenated to the previous message in ALTS default implementation), and contains a handshake authenticator, i.e. HMAC over a known bitstring using the calculated session key;
  • ClientFinished, sent by the client, and contains a handshake authenticator, similarly to the one in ServerFinished.

Once both parties computed the session key (record protocol in the whitepaper), they can start encrypting traffic with the symmetric encryption algorithm 128-bit AES, using mostly GCM as its mode of operation. On older machines, a Google developed VCM[7] was used.[8]

The handshake protocol was verified using the ProVerif formal verification tool.[9]

Session resumption

In order to avoid repeating computationally expensive operations, ALTS supports session resumption. The resumption tickets are created by either the server or the client, and may be used in the handshake protocol, if both parties hold the same resumption ticket, indexed by a resumption identifier. The resumption secret is used to derive the next session key, authenticator and encapsulated (independent) resumption ticket/identifier.

Perfect forward secrecy

Perfect forward secrecy (PFS) is not enabled by default in ALTS; however, it is supported. Instead of using an inherent PFS algorithm, ALTS achieves PFS by frequently rotating the certificates, which have a short lifespan (6, 20, or 48 hours; see [8]). Moreover, if PFS is enabled, it is also enabled for session resumption, by deriving the encryption keys from the resumption ticket using a pseudorandom function.

See also

References

  1. ↑ "ALTS authentication". gRPC. Retrieved 2022-10-23.
  2. 1 2 "Application Layer Transport Security". Google Cloud. Retrieved 18 November 2019.
  3. ↑ Sheridan, Kelly (2017-12-13). "Google Sheds Light on Data Encryption Practices". Dark Reading. Retrieved 2022-12-11.
  4. ↑ "Google Details How It Protects Data Within Its Infrastructure | SecurityWeek.Com". www.securityweek.com. 14 December 2017. Retrieved 2022-12-11.
  5. ↑ Rescorla, Eric; Dierks, Tim (August 2008). "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. doi:10.17487/RFC5246. Retrieved 18 November 2019.
  6. ↑ "Service-to-service authentication, integrity, and encryption § ALTS Protocol". Google Cloud. Retrieved 18 November 2019.
  7. ↑ Knapp, Ed (2017). "AES-VCM, an AES-GCM Construction Using an Integer-based Universal Hash Function". ai.google. Retrieved 18 November 2019.
  8. 1 2 "Encryption in Transit in Google Cloud". Google Cloud. Retrieved 18 November 2019.
  9. ↑ "ProVerif: Cryptographic protocol verifier in the formal model". prosecco.gforge.inria.fr. Retrieved 18 November 2019.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.