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

Application Layer Transport Security - Google

• 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

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

Application Layer Transport Security - Google

Introduction

Design

Trust Model Protocols Tradeoffs

Application Layer Transport Security - Google

Highly reliable, trusted system that allows for service-to-service authentication and security with minimal user involvement

“ ”

Design

Application Layer Transport Security - Google

• 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

Design - Guiding Principles

Application Layer Transport Security - Google

• 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

Design - Guiding Principles

Application Layer Transport Security - Google

Introduction Design

Trust Model

Protocols Tradeoffs

Trust Model

Application Layer Transport Security - Google

• 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

Trust Model - Credentials

Application Layer Transport Security - Google

• Three types, expressed in Protocol Buffers: master certificates, handshaker

certificates and resumption keys

Trust Model - Credentials

Application Layer Transport Security - Google

• 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

Trust Model - Credentials

Application Layer Transport Security - Google

• 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

Trust Model - Credentials

Application Layer Transport Security - Google

• Three types, expressed in Protocol Buffers: master certificates, handshaker

certificates and resumption keys ALTS certificate chain

Trust Model - Credentials

Application Layer Transport Security - Google

• 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

Trust Model - Certificate Issuance

Application Layer Transport Security - Google

• To participate in ALTS secure handshake, entities need handshake certificates

○ First: issuer obtains a master certificate

Trust Model - Certificate Issuance

Application Layer Transport Security - Google

• To participate in ALTS secure handshake, entities need handshake certificates

○ First: issuer obtains a master certificate

Trust Model - Certificate Categories

Application Layer Transport Security - Google

• 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

Trust Model - Certificate Categories

Application Layer Transport Security - Google

• 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

Trust Model - Certificate Categories

Application Layer Transport Security - Google

• 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

Trust Model - Certificate Categories

Application Layer Transport Security - Google

Application Layer Transport Security - Google

Introduction Design Trust Model

Protocols

Tradeoffs

Protocols

Application Layer Transport Security - Google

ALTS uses two protocols

Handshake protocol

• Session key and peer identity exchange

Record protocol

• Provides data confidentiality and integrity
• Automatic rekeying

Protocols - Handshake

Application Layer Transport Security - Google

• 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

Protocols - Handshake

Application Layer Transport Security - Google

• 1. Client sends ClientInit containing
• Client handshake certificate
• List of handshake-related ciphers
• Record protocols
• (Optional) Resumption ID and ticket

Protocols - Handshake

Application Layer Transport Security - Google

• 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

• 3. Server sends
• ServerFinished containing authenticator

○ HMAC over pre-defined bit string ○ Using secret A

Protocols - Handshake

Application Layer Transport Security - Google

Protocols - Handshake

Application Layer Transport Security - Google

• 4. Client receives ServerInit
• Verifies server certificate
• Derives the same M, R and A

• 5. Client receives ServerFinished
• Uses A to verify its authenticator

Protocols - Handshake

Application Layer Transport Security - Google

• 5. Client receives ServerFinished
• Uses A to verify its authenticator

Client can start sending data encrypted with M

Protocols - Handshake

Application Layer Transport Security - Google

Protocols - Handshake

Application Layer Transport Security - Google

• 6. Client sends
• ClientFinished containing authenticator

○ HMAC over pre-defined bit string ○ Using secret A

• (Optional) Resumption ticket

Protocols - Handshake

Application Layer Transport Security - Google

• 7. Server receives ClientFinished
• Verifies the authenticator

Protocols - Handshake

Application Layer Transport Security - Google

• 7. Server receives ClientFinished
• Verifies the authenticator

Server can start sending data encrypted with M

Protocols - Record

Application Layer Transport Security - Google

• Suite of encryption schemes, different key sizes and features
• Client sends its supported schemes, sorted by preference
• Server chooses the first that matches its local configuration
• Advantages:

○ Allows clients and servers to have different preferences ○ Allows us to phase in (or remove) encryption schemes

Session Resumption

Application Layer Transport Security - Google

• Used to resume connection without expensive asymmetric crypto
• ALTS handshake allows clients and servers to exchange resumption tickets

○ Indexed by Resumption ID ○ Resumption ID is unique to all workloads running with same identity in same datacenter cell

• Tickets are encrypted using symmetric keys associated with Resumption ID

○ Keys are distributed and refreshed automatically with the workload credentials

• Two types: stored server-side tickets and stored client-side tickets

Application Layer Transport Security - Google

Introduction Design Trust Model Protocols

Tradeoffs

Tradeoffs

Application Layer Transport Security - Google

• Key Compromise Impersonation

○ ALTS is susceptible to KCI attacks ○ Compromising workload DH private key or resumption key allows adversary to impersonate other workloads to victim workload ○ Part of our resumption threat model ○ Variant of ALTS that protects against KCI exists, but works in environment with no resumption

• Privacy for handshake messages

○ ALTS not designed to disguise identities of peers ○ Handshake messages are not encrypted

Lessons Learned

Application Layer Transport Security - Google

• Changing authentication system in production is hard
• Changing trust model of production system is even harder …
• Diverging from a standard is a delicate balance
• Key exchange and record protocol are only a small part of the stack:

○ Identifying the security boundaries and adversary models ○ Key management, rotation and revocation

Thank you!! Questions? https://cloud.google.com/security/encryption-in- transit/application-layer-transport-security/

Application Layer Transport Security - Google