 | This articlemay rely excessively on sourcestoo closely associated with the subject, potentially preventing the article from beingverifiable andneutral. Please helpimprove it by replacing them with more appropriatecitations toreliable, independent sources.(April 2024) (Learn how and when to remove this message) |
Application Layer Transport Security (ALTS) is aGoogle-developedauthentication and transportencryption system used for securingremote procedure call (RPC) within Google machines.[1] Google started its development in 2007, as a tailored modification ofTLS.[2]
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 dominantApplication layer protocols were SSL and TLS 1.1 (TLS 1.2 was only published as anRFC in 2008[5]), those supported many legacy algorithms and had poor security standards. AsGoogle 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 differenttrust models:inTLS, the server side is committed to its owndomain 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.
The ALTShandshake protocol is based on authenticatedDiffie–Hellman key exchange scheme, and supports bothperfect 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 acertificate proving their respective identities. The certificate chains to a trusted signing service verification key, with the leaf being anElliptic-curve Diffie–Hellman key, that is eventually used for key exchange. Theelliptic curve used in the key exchange isCurve25519.[6]
The handshake protocol consists of four messages, sent in plaintext:
Once both parties computed the session key (record protocol in the whitepaper), they can start encrypting traffic with the symmetric encryption algorithm 128-bitAES, using mostlyGCM as itsmode of operation. On older machines, a Google developed VCM[7] was used.[8]
The handshake protocol was verified using theProVerif formal verification tool.[9]
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 aresumption identifier.Theresumption secret is used to derive the next session key, authenticator and encapsulated (independent) resumption ticket/identifier.
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 ( 20, or 48 minutes; see[8]). Moreover, if PFS is enabled, it is also enabled for session resumption, by deriving the encryption keys from the resumption ticket using apseudorandom function.
