application layer transport security
play

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


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

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

  3. 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

  4. 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

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

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

  7. 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

  8. 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

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

  10. 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

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

  12. 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

  13. 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

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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. Trust Model - Certificate Categories Application Layer Transport Security - Google

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

  23. 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

  24. 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

  25. 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

  26. 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

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

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

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

  30. 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

  31. 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

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

Recommend


More recommend