Google Details How It Protects Data Within Its Infrastructure
14.12.2017 securityweek Krypto
Google has decided to share detailed information on how it protects service-to-service communications within its infrastructure at the application layer and the the system it uses for data protection.

Called Application Layer Transport Security (ALTS), the technology was designed to authenticate communication between Google services and keep data protected while in transit. When sent to Google, data is protected using secure communication protocols such as TLS (Transport Layer Security).

According to the Web search giant, it started development of ALTS in 2007, when TLS was bundled with support protocols that did not satisfy the company’s minimum security standards. Thus, the company found it more suitable to design its own security solution than patch an existing system.

More secure than older TLS, Google describes ALTS as “a highly reliable, trusted system that provides authentication and security for […] internal Remote Procedure Call (RPC) communications,” that ensures security within the company’s infrastructure.

The system, Google explains, requires minimal involvement from the services themselves, as data is protected by default. All RPCs issued or received by a production workload are protected by ALTS by default, as long as they stay within a physical boundary controlled by or on behalf of Google.

According to Google, the ALTS configuration is transparent to the application layer; all cryptographic primitives and protocols used by ALTS are up-to-date with current known attacks; ALTS performs authentication primarily by identity rather than host name; the system relies on each workload having an identity, which is expressed as a set of credentials; after an initial ALTS handshake, connections can be persisted for a longer time to improve overall system performance; ALTS is considerably simpler than TLS as Google controls both clients and servers, the company also says.

Benefits of ALTS also include more precise security. Workloads that run on the same machine can authenticate using their own identity rather than the machine’s identity, Google explains in a whitepaper detailing the system. Overhead of potentially expensive cryptographic operations is reduced with ALTS.

ALTS also offers improved scalability, courtesy of an efficient resumption mechanism embedded in its handshake protocol. The system can also accommodate authentication and encryption needs for a large number of RPCs (services on Google production systems collectively issue on the order of O(1010) RPCs per second), the company says.

The system also includes a wide array of features designed to ensure security and scalability, and features a flexible trust model suited for different types of entities on the network (physical machines, containerized workloads, and even human users).

Within Google’s infrastructure, all scheduled production workloads are initialized with a certificate that is securely delivered and which asserts their identity. The remote peer identity and certificate are verified when a workload is involved in an ALTS handshake. Certificates have a relatively short lifespan.

ALTS uses a Diffie-Hellman (DH) based authenticated key exchange protocol for handshakes and provides applications with an authenticated remote peer identity that can be used for fine-grained authorization policies at the application layer, the company explains.

“After a handshake is complete and the client and server negotiate the necessary shared secrets, ALTS secures RPC traffic by forcing integrity, and optional encryption, using the negotiated shared secrets. We support multiple protocols for integrity guarantees, e.g., AES-GMAC and AES-VMAC with 128-bit keys,” Google says.

When traffic leaves a physical boundary controlled by or on behalf of Google, protocols are automatically upgraded to ensure encryption and integrity. AES-GCM and AES-VCM protocols with 128-bit keys are employed in such cases, the company also explains.