Application Layer Transport Security Cesar Ghali, Adam Stubblefield, - PowerPoint PPT Presentation

Application Layer Transport Security Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt, Julien Boeuf Real World Crypto, 2019 January 9-11, 2019

Introduction Design Trust Model Protocols Tradeoffs Application Layer Transport Security - Google

Introduction ● Distributed systems rely on secure communication protocols to protect data in transit ● Google uses Application Layer Transport Security (ALTS) to secure Remote Procedure Calls (RPCs) ○ Google production network issues roughly 10 billion RPCs per second ● ALTS provides transport security protection with zero configuration ALTS is friendly to service replication, load balancing, and rescheduling across ● production machines Application Layer Transport Security - Google

Why Not TLS? ● ALTS development began in 2007 ○ TLS did not fit well with Google security model TLS and its implementations seemed complex, due to support for legacy flow and ○ protocols ● TLS could be modified and adopted … developing from scratch seemed more advantageous ● Key differences: TLS with HTTPs and ALTS have fundamentally different trust models ○ ○ ALTS is simpler in its design and implementation ■ Easier to analyze for bugs and security vulnerabilities ○ ALTS uses Protocol Buffers, more suitable for Google production services Application Layer Transport Security - Google

Introduction Design Trust Model Protocols Tradeoffs Application Layer Transport Security - Google

Design “ Highly reliable, trusted system that allows for service-to-service authentication and ” security with minimal user involvement Application Layer Transport Security - Google

Design - Guiding Principles ● Transparency: ○ All RPCs are ALTS-secured by default No need to worry about credential management or security configurations ○ ○ Peer information propagated to application for authorization ● State-of-the-art cryptography: AES-GCM with auto-rekeying ○ ○ Google controls ALTS: crypto protocols are easily upgraded and deployed ● Identity model: Authentication by identity rather than host name ○ ○ All communications are mutually authenticated Application Layer Transport Security - Google

Design - Guiding Principles ● Key distribution: ○ Identities have corresponding “managed” credentials Deployed and periodically refreshed automatically for each workload without ○ application developer involvement ● Scalability: Efficient session resumption ○ ● Long-lived connections: ○ Accommodate the scale of Google’s infrastructure Simplicity: ● ○ Tailored for service-to-service communication pattern ○ No support for legacy protocols Application Layer Transport Security - Google

Introduction Design Trust Model Protocols Tradeoffs Application Layer Transport Security - Google

Trust Model ● Authenticate application identities, not hosts ● Every network entity has an associated identity ○ Embedded in certificates ○ Used for peer authentication ● Model pursued: ○ Major production services run as identity managed by SREs ○ Development versions run as test identity managed by SREs and developers ● Authorization policy is based on service identities ● Policy example: ○ Production services do not trust the development versions of the services Application Layer Transport Security - Google

Trust Model - Credentials ● Three types, expressed in Protocol Buffers: master certificates, handshaker certificates and resumption keys Application Layer Transport Security - Google

Trust Model - Credentials ● Three types, expressed in Protocol Buffers: master certificates, handshaker certificates and resumption keys Master certificates: ○ Signed by a remote Signing Service ○ Contains RSA public key ○ Associated (master) private key signs handshaker certificates ○ Usually issued for production machines and schedulers of containerized workloads Application Layer Transport Security - Google

Trust Model - Credentials ● Three types, expressed in Protocol Buffers: master certificates, handshaker certificates and resumption keys Handshaker certificates: ○ Signed by master private key ■ Created locally for system services Created and provisioned by scheduler for containerized workloads ■ ○ Contains parameters used in ALTS handshake ○ Contains the master certificate that verifies it Application Layer Transport Security - Google

Trust Model - Credentials ● Three types, expressed in Protocol Buffers: master certificates, handshaker certificates and resumption keys ALTS certificate chain Application Layer Transport Security - Google

Trust Model - Credentials ● Three types, expressed in Protocol Buffers: master certificates, handshaker certificates and resumption keys Resumption keys: ○ Secret used to encrypt resumption tickets ○ Identified by a Resumption ID ○ Resumption ID unique for workloads running with the same identity and in the same datacenter cell Application Layer Transport Security - Google

Trust Model - Certificate Issuance ● To participate in ALTS secure handshake, entities need handshake certificates ○ First: issuer obtains a master certificate Application Layer Transport Security - Google

Trust Model - Certificate Issuance ● To participate in ALTS secure handshake, entities need handshake certificates ○ First: issuer obtains a master certificate Application Layer Transport Security - Google

Trust Model - Certificate Categories ● Three certificate categories, based on what they’re issued for: Human certificates: ○ RPCs issued by humans to production services are ALTS-secured ○ Humans obtain handshake certificates from internal CA ■ Provisioning requests authenticated using username, password and 2FA Valid for less than a day ○ Application Layer Transport Security - Google

Trust Model - Certificate Categories ● Three certificate categories, based on what they’re issued for: Machine certificates: ○ Production machines have machine master certificates issued by internal CA ○ Corresponding private key creates handshake certificates for core daemons ○ Machine master certificates rotated every few months ○ Machine handshake certificates rotated every few hours Application Layer Transport Security - Google

Trust Model - Certificate Categories ● Three certificate categories, based on what they’re issued for: Workload certificates: ○ Handshake certificates issued to production workloads running on Borg ○ Used by application for ALTS handshake ○ Rotated every two days on average Application Layer Transport Security - Google

Trust Model - Certificate Categories Application Layer Transport Security - Google

Introduction Design Trust Model Protocols Tradeoffs Application Layer Transport Security - Google

Protocols ALTS uses two protocols Handshake protocol Record protocol ● Session key and peer identity exchange ● Provides data confidentiality and integrity ● Automatic rekeying Application Layer Transport Security - Google

Protocols - Handshake ● Diffie-Hellman-based authentication key exchange protocol ● ALTS infrastructure ensures all entities have certificate with ○ Their identities ○ Elliptic Curve DH (ECDH) keys rotated frequently Supports Perfect Forward Secrecy (PFS) with additional ephemeral ECDH keys and ● session resumption Clients and servers negotiate ● ○ Shared session encryption key ○ Record protocol to use Application Layer Transport Security - Google

Protocols - Handshake 1. Client sends ClientInit containing ● Client handshake certificate List of handshake-related ciphers ● ● Record protocols ● (Optional) Resumption ID and ticket Application Layer Transport Security - Google

Protocols - Handshake 2. Server ● Verifies client certificate Chooses protocols to use ● ● Computes DH exchange result and derives (using the session transcript): ○ Record protocol secret, M ○ Resumption secret, R ○ Authenticator secret, A Sends ServerInit containing: ● ○ Server handshake certificate Chosen protocols ○ ○ (Optional) resumption ticket Application Layer Transport Security - Google

Protocols - Handshake 3. Server sends ● ServerFinished containing authenticator HMAC over pre-defined bit string ○ ○ Using secret A Application Layer Transport Security - Google

Protocols - Handshake 4. Client receives ServerInit ● Verifies server certificate Derives the same M , R and A ● Application Layer Transport Security - Google

Protocols - Handshake 5. Client receives ServerFinished ● Uses A to verify its authenticator Application Layer Transport Security - Google

Protocols - Handshake 5. Client receives ServerFinished ● Uses A to verify its authenticator Client can start sending data encrypted with M Application Layer Transport Security - Google

Protocols - Handshake 6. Client sends ● ClientFinished containing authenticator HMAC over pre-defined bit string ○ ○ Using secret A ● (Optional) Resumption ticket Application Layer Transport Security - Google

Protocols - Handshake 7. Server receives ClientFinished ● Verifies the authenticator Application Layer Transport Security - Google