ALTS

Last updated

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]

Contents

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:

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

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed it primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

In computing, a handshake is a signal between two devices or programs, used to, e.g., authenticate, coordinate. An example is the handshaking between a hypervisor and an application in a guest virtual machine.

Password Authentication Protocol (PAP) is a password-based authentication protocol used by Point-to-Point Protocol (PPP) to validate users. PAP is specified in RFC 1334.

In cryptography and computer security, a man-in-the-middle, monster-in-the-middle, machine-in-the-middle, monkey-in-the-middle, meddler-in-the-middle, manipulator-in-the-middle (MITM), person-in-the-middle (PITM) or adversary-in-the-middle (AiTM) attack is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within the reception range of an unencrypted Wi-Fi access point could insert themselves as a man-in-the-middle. As it aims to circumvent mutual authentication, a MITM attack can succeed only when the attacker impersonates each endpoint sufficiently well to satisfy their expectations. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, TLS can authenticate one or both parties using a mutually trusted certificate authority.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

A security protocol is an abstract or concrete protocol that performs a security-related function and applies cryptographic methods, often as sequences of cryptographic primitives. A protocol describes how the algorithms should be used and includes details about data structures and representations, at which point it can be used to implement multiple, interoperable versions of a program.

FTPS is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer cryptographic protocols.

The Protected Extensible Authentication Protocol, also known as Protected EAP or simply PEAP, is a protocol that encapsulates the Extensible Authentication Protocol (EAP) within an encrypted and authenticated Transport Layer Security (TLS) tunnel. The purpose was to correct deficiencies in EAP; EAP assumed a protected communication channel, such as that provided by physical security, so facilities for protection of the EAP conversation were not provided.

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and is updated by RFC 5247. EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor-specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages.

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

Mutual authentication or two-way authentication refers to two parties authenticating each other at the same time in an authentication protocol. It is a default mode of authentication in some protocols and optional in others (TLS).

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

Transport Layer Security pre-shared key ciphersuites (TLS-PSK) is a set of cryptographic protocols that provide secure communication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys shared in advance among the communicating parties.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its now-deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

The Internet Assigned Numbers Authority (IANA) officially assigned port 4605 to the SixChat End2End Direct secure messaging protocol created by Sixscape Communications, Pte. Ltd. The assignment was issued by IANA on 11 September 2014, and is listed in the official IANA resource registry at https://www.iana.org/assignments/service-names-port-numbers

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. Retrieved 2022-12-11.
  5. Rescorla, Eric; Dierks, Tim (August 2008). "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. 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.