Cryptography Three methods: Symmetric key Asymmetric key Hashing

Symmetric Key Encryption Encryption of almost everything Data at rest: disk encryption, files, data bases Data in motion: SSL/TLS, IPsec Today’s standards Advanced Encryption Standard: AES-128 and AES-256 Processor hardware acceleration for Galois/Counter Mode (GCM) < 1% performance impact SDP/PA use AES-256 for Single Packet Authorization mutual TLS communication Shared key encryption The same key used to encrypt, also decrypts Must be kept secret !!! Very difficult to transmit a secret across an untrusted network ShiftRows SubBytes MixColumns AddRoundKey The quick brown fox jumps over the lazy dog Encrypt The quick brown fox jumps over the lazy dog Decrypt 9e107d9d372bb6826bd81d3542a419d6

Asymmetric Key (a.k.a. Public Key) Cryptography Purpose Exchange secrets over an untrusted network Secretly (encrypted) and with integrity (signed) Only encrypts small pieces of data Message must be smaller than the asymmetric key Only used for 2 things Encrypt symmetric keys (common for data at rest) Encrypt hashes (together known as a “signature”) Today’s standards Diffie-Hellman, RSA (PKCS#1), Digital Signature Standard (DSS) SDP/PA use asymmetric key encryption for: Encrypting keys on disk Exchanging symmetric keys during the TLS handshake Generating and validating X.509 certificates Hash Asymmetric Key Signature David Kravitz subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert

Hash (a.k.a. Message Authentication Code or MAC) Converts an arbitrarily long message into a single number The number is “Unique”– typical values are 2256, 2384, 2512 2256 = 1157920892373160000000000000000000000000000000000000000000000000000000000000000 Approx. # atoms in observable universe Cannot be reversed Once converted to a hash, cannot be convert back into the message Re-hash the message and compare hashes Same hash means same message Today’s standards Secure Hash Algorithm 1 (SHA-1) – widely used, considered insecure SHA-2 family of hashes, typical use: 256, 384, 512-bit SHA-3 released Aug 5, 2015 Message Digest 5 (MD5) – considered cryptographically broken SDP/PA use hashing for: One Time Password (OTP) and GMAC of Single Packet Authorization (SPA) Integrity of TLS handshake X.509 certificates (prior to being encrypted with asymmetric keys) Derivation of TLS symmetric keys and Initialization Vectors (IV) message Hash Equal ? Hash Key Derivation Function (KDF) Km = create master key K1 = H[Km] K2 = H[K1] K3 = H[K2] K4 = H[K3]

Cryptography TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Only 3 methods Symmetric key encryption Asymmetric key encryption Hashing (MAC) Almost always used in combination Example Method for SSL/TLS connection Generate asymmetric keys Exchange asymmetric keys Symmetric key encryption Symmetric key & hashing Hash (KDF) TLS cypher suite Authentication via asymmetric & hashing TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Symmetric Key Encryption with Message Authentication

Symmetric Key Encryption Untrusted Network Cypher Text (CT) PT Ek Dk PT

Symmetric Key Encryption & Block Cyphers Ek PT Untrusted Network Dk Cypher Text (CT) 1 2 3 1 PT 1 XOR 1 CT 6 3 5

Symmetric Key Encryption & Block Cyphers Ek PT Untrusted Network Dk Cypher Text (CT) 1 2 3 6 3 5 1 PT 1 CT 1 XOR 1 XOR 1 CT 1 CT 1 PT 6 3 5 1 2 3

Symmetric Key Encryption & Message Authentication Ek PT Untrusted Network Dk Cypher Text (CT) 1 2 3 XOR CT 6 5 Ek PT Untrusted Network Dk Cypher Text (CT) 1 CT 6 3 5

Symmetric Key Encryption & Message Authentication Ek PT Untrusted Network Dk Cypher Text (CT) 6 6 3 5 6 3 5 1 CT 1 CT Input XOR out Hash Input XOR Hash Hi Hi-1 Func Function 6 7 6 6 6 7 3 4 2 1 5 6 3 4 7 3 4 5 6 7 XOR 5 6 7 6 1 5 5 6 6 1 5 7

Galois/Counter Mode (GCM) and GMAC

Galois/Counter Mode (GCM) and GMAC Ek 0128 GHASH0 IV || 1 1 n IV || n Ek IV || 032 TAG Ek PTn CTn Ek PT1 CT1 ADm GHASHm AD1 GHASH1 len(AD) || len(PT) len(PT) GHASH GHASHm+1 GHASHm+n Ek is the encryption algorithm and key, which is AES 256 PT is Plain Text that gets encrypted into Cypher Text (CT) All blocks are 128 bits in length IV is a 96-bit Initialization Vector, which is a nonce 1st counter block is the IV followed by the 32-bit number “1” The output is the Cypher Text and the Tag AD is Additional Data (that does not get encrypted)

Asymmetric Key Cryptography (Public Key)

Asymmetric Key Cryptography Algorithms generate 2 keys Private key is kept private, public key is shared Elliptic curve keys are hundreds of bits RSA keys are thousand bits Message smaller than the key 2 uses Encrypt a symmetric key Alice encrypt the symmetric key with Bob’s public key So Bob can decrypt with his private key Encrypt a hash (MAC) Alice encrypt the hash with Alice’s private key So Bob can decrypt it with Alice’s public key Concerns: 1. How does Alice know it’s Bob’s key? Answer: Public Key Infrastructure 2. If the conversation is recorded And if Bob’s private key is compromised Then attacker can decrypt message Solution: Perfect Forward Secrecy Math Example (RSA) Untrusted Network m Message For example: Symmetric key me mod n Encryption “e” is Bob’s public key c Cypher Text cd mod n Decryption “d” is Bob’s Private key m Message Alice Bob (me)d ≡ me*d ≡ m1 ≡ m (mod n)

Perfect Forward Secrecy Compromise of long term key Does not compromise past keys Thought exercise/analogy Diffie-Hellman Ephemeral (DHE) But with buckets of paint* Thought exercise/small numbers Also from Wikipedia Remember this is not RSA math Perfect Forward Secrecy Not encrypted key sent to another Random keys, neither knows both Alice Bob g = common # = 5 p = modulus = 23 Both agree on a common color Each separately blends their secret color with the common color + = Both choose a secret color a = 6 b = 15 A = 5^6 mod 23 = 8 B = 5^15 mod 23 = 19 Exchange Blends Each now has the other’s blended color 19 8 + = Each separately blends their secret color with the other’s blended color Both arrive at the same common blended color (a common secret) * Wikipedia “Diffie–Hellman key exchange” https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange 19^6 mod 23 = 2 8^15 mod 23 = 2

Asymmetric Key Summary 2 uses of asymmetric key Encrypt symmetric key (using receiver’s public) Encrypt hashes (using sender’s private) RSA math (me)d ≡ me*d ≡ m1 ≡ m (mod n) Crypto of symmetric keys and hashes Diffie-Hellman analogy Paint buckets (ga)b (mod n) ≡ (gb)a (mod n) Perfect Forward Secrecy Becomes basis for pre-master key

Public Key Infrastructure (PKI)

Public Key Infrastructure (PKI) What is it used for? Create and distribute digital certificates Acts as a trusted 3rd party Enables authentication over an untrusted network SDP/PA use it for Mutual Authentication of: Clients to Controllers Clients to Gateways Gateways to Controllers Basically, all trust Mutual trust, not just single-ended How does it work? Certificate Authority (Trusted 3rd Party) Untrusted Network Mutual Authentication Private Key Public key / Certificate Trusted Root certificate Private Key Public key / Certificate Trusted Root certificate

Initialization of PKI Certificate Authority (CA) subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert Root Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public subj: Vidder issuer: Vidder Hash CA CRL OCSP ---------------- Signature Vidder Public

Server Gets a Private Key and Certificate subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Server issuer: Vidder ---------------- Signature Server Public Server Cert Server Cert Hash subj: Server issuer: Vidder CA OCSP CRL ---------------- Signature Server Public subj: Server issuer: Vidder ---------------- Signature Server Public Server Cert

PKI Part of TLS Hash Hash Hash Valid certifacate Not expired subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert Serial # Validity Time ---------------- Signature Good OCSP Response OCSP Response CA OCSP CRL Serial # Validity Time Hash Valid certifacate Not expired Good ---------------- Signature Not revoked Cert is trusted !!! subj: Server issuer: Vidder ---------------- Signature Server Public Server Cert Hash Hash Serial # Equal ? Equal ? Original Hash Original Hash subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert

Client Certificate Rest of Cert Client Universal ID Pinned to SDP Subject Hash for Signature Issuer Serial # Public Key Key Usage see RFC 5280 pg. 29 Signature (not Hashed)

Certificate Authority Is PKI Broken? Is it broken? No The technology is sound Is it broken in some other way? Yes The hundreds of certificate authorities should not be trusted DigiNotar compromised – Google’s email service was compromised in Iran Root cert injection creates additional trusted websites Sophisticated attack that undermines trust Certificate subject is a name, not an IP address DNS spoofing can fool PKI Requires revocation checking Enables DoS attack of the infrastructure Does Vidder fix it? Yes Dedicated PKI means only the SDP’s certificate authority is trusted Additional root certs cannot be injected – the one and only root is encrypted on disk Certificate subject is an IP address, not a name – spoofing is not possible OCSP responses are “stapled” – defeating DoS attacks Untrusted Network Private Key Public key / Certificate Trusted Root certificate Mutual Authentication Certificate Authority (Trusted 3rd Party)

Certificate Authority PKI Summary PKI’s purpose is to Create and distribute digital certificates Act as a trusted 3rd party Enables authentication over an untrusted network PKI consists of a root cert and certs derived from it Everyone inherently trusts the root Certificates can be cryptographically proven Signing proves the certificated hasn’t been altered Signature: encrypts the hash with issuer’s private key Creates a chain of trust that must be validated The public implementation of PKI is “broken” But the technology is not SDP’s implementation fixes the breakage Untrusted Network Private Key Public key / Certificate Trusted Root certificate Mutual Authentication Certificate Authority (Trusted 3rd Party)

keyed-Hash Message Authentication Code (HMAC)

HMAC Prove the integrity of a message Hash alone will not work Send message over an untrusted network Message: encrypted or not Prove it has not been altered Hash alone will not work Attacker can alter the message Compute the hash for it Solutions GMAC – shared secret key using Galois field hash Signature – encrypt hash with private key HMAC – shared secret key with SHA hash Untrusted Network Message Message Altered Untrusted Network Message Hash Message Hash Altered New Hash

HMAC Algorithm Minor changes to message create major hash differences SHA-2 of “abcedf” is 99afa43d51c4800bae04c2afb4a4aa97c548cba5d61b938cd1935bdc4cb93915 SHA-2 of “abcdefg” is 34541528206d252e76bb2597687112b53aff7f70dd1da1d763dab4c59095bf89 Appending “g” completely changes the hash But, in theory, susceptible to length extension attacks Therefore the algorithm is defined to be HMAC[K,m] = H[K 0x5C5C… || H[K 0x3636… || m]] Where: K is a secret key, m is the message to be hashed, H is a hash function (e.g., SHA-1, SHA-2) is the XOR function, || is concatenation Key = 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef XOR = 36363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636363636 XOR’d key = 37157351bf9dfbd937157351bf9dfbd937157351bf9dfbd937157351bf9dfbd937157351bf9dfbd937157351bf9dfbd937157351bf9dfbd937157351bf9dfbd9 message = 00000000000000000000000000000000 1st hash = 27160c985407f5131478c099d73032cf32bd8a3f866a0cb1bf96c08a04940517594fe0e9eed02a83accb4286c9537a12d35e9d576c17b7d87836533b8a41959b XOR = 5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c5c XOR’d key = 5d7f193bd5f791b35d7f193bd5f791b35d7f193bd5f791b35d7f193bd5f791b35d7f193bd5f791b35d7f193bd5f791b35d7f193bd5f791b35d7f193bd5f791b3 HMAC = 26fecd895f4fbbfe3e3d2a74e2f545624d3e5889e8e10df41fbb1628a0a7c9dac73ad34064df40904623fb2f3cd64890b63f6d033309eac1e47bf591bd6e964f

HMAC in the Software Defined Perimeter (SDP) Used in Single Packet Authorization (SPA) SPA = UID, CTR, HOTP, GMAC Based on RFC 4226 HOTP = HMAC[K, CTR] Untrusted Network CTR, HOTP HOTP = HMAC[K, CTR] CTR, HOTP HOTP ?= HMAC[K, CTR]

HMAC and SDP/PA Single Packet Authorization RFC 4226 specifies HMAC for Hashed One-Time Password (HOTP)

SDP Device Authentication SPA Mutual TLS Fingerprint

SDP Device Authentication Single Packet Authorization (SPA)

Attacks on SSL/TLS Name Date Attack Unauthorized Authorized Users SSLstrip Feb 2009 http to https SPA No http DigiNotar Sept 2011 MitM forged certs Pinned certs THC-SSL-DOS Oct 2011 DoS attack on SSL Device deleted BEAST Apr 2012 Java Applet oracle Client-based CRIME Sept 2012 MitM SPDY compressing oracle No compression Lucky 13 Feb 2013 MitM CBC padding oracle GCM TIME Mar 2013 Browser JavaScript timing oracle RC4 biases MitM RC4 oracle No cypher negotiation BREACH Aug 2013 Website redirect, compression No redirect or compression goto fail Feb 2014 MitM counterfeit key via coding error Pinned dedicated cert Triple Handshake Mar 2014 Server MitM on client cert Heartbleed Apr 2014 OpenSSL bug Not single-ended SSL BERserk Sept 2014 MitM PKCS#1.5 padding Not Mozilla NSS Poodle Oct 2014 MitM SSLv3 oracle Poodle++ Dec 2014 MitM JavaScript timing oracle FREAK Mar 2015 MitM negotiation 512 bit key No key negotiation Bar-mitzvah View RC4 No RC4 logjam May 2015 MitM downgrade to 512 bit key No suite negotiation PrecisionAccess defeats all recent attacks on SSL/TLS by both Unauthorized and Authorized users

Single Packet Authorization (SPA) History: Invented >10 years ago Commonly used for super user ssh access to servers Mitigates attacks by unauthorized users SPA in the Software Defined Perimeter Spec Based on RFC 4226, "HOTP” HMAC-based One-Time Password Used for hardware/software one time password tokens SPA occurs before TLS (SSL) connection Mitigates DoS & other TLS attacks by unauthorized users SPA = UID, CTR, OTP, GMAC Each client has a UID, Seed, CTR, and EK UID = Universal ID of SDP Client CTR = hashed with seed to create OTP OTP = One-Time Password GMAC = signature of UID, CTR, and OTP for data authentication Seed = shared secret for OTP EK = shared key for GMAC AES-256 OTP = HMAC[seed || CTR] GMAC = EK [UID || OTP || CTR] UID, OTP, CTR, & GMAC are sent as clear text. Counter is increment to mitigate playback attacks Highly efficient rejection Defeats DoS & other attacks on SSL UID OTP Counter GMAC 32-bit 64-bit 128-bit

SDP Device Authentication mutual TLS

Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Elliptic Curve cryptography Smaller keys / faster math than RSA cryptography DHE: Diffie-Hellman key exchange algorithm Generates the pre-master keys of GCM Ephemeral keys per session for Perfect Forward Secrecy But not client or server authentication RSA: Public/private key pair with an X.509 certificate Client and server authentication Vidder’s implementation: Certificates “pinned” to a trusted root certificate Not the hundreds of (possibly compromised) roots browsers trust Employs OCSP stapling (RFC 6066) Forwards the OCSP response with TLS Server hello Reduces the load on the OCSP responder Mitigates a DoS attack of the OCSP responder Mutual TLS Authentication of the client to server & server to client AES256-GCM: Advanced Encryption Standard (NIST FIPS 197) Symmetric key encryption 256-bit key, 128-bit cipher block size Galois/Counter Mode Encryption with simultaneously data authentication PC’s and servers implement GCM in hardware Negligible performance impact SHA384: Secure Hash Algorithm (member of SHA-2) Generates a 384 bit hash Key Derivation Function (KDF) for generating keys from master

SDP Device Authentication Single Packet Authorization and mutual TLS Handshake Deep Dive for: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Controller’s PKI Certificate Authority (CA) Initialization subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert Root Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public subj: Vidder issuer: Vidder Hash CA CRL OCSP ---------------- Signature Vidder Public PA

Controller Initialization subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert Controller Cert Hash subj: Ctrl issuer: Vidder CA OCSP CRL ---------------- Signature Ctrl Public PA subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert

Mutual TLS: Client Initialization subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert Hash subj: Client issuer: Vidder CA OCSP CRL ---------------- Signature Client Public PA subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert Private key put in Certificate Store as Non-Exportable

Single Packet Authorization subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert CA OCSP CRL SYN/ACK PA subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert ACK SYN Client Hello Highest SSL version, Ciphers supported, Session Id = 0, SPA Client RND subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert

Mutual TLS: Client Hello subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert CA OCSP CRL PA subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert Client Hello Highest SSL version, Ciphers supported, Session Id = 0, Client RND OCSP status subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert

Mutual TLS: Server Hello subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert Serial # Validity Time ---------------- Signature Good OCSP Response OCSP Response Server Hello Selected SSL version, Selected Cipher, Session Id = RND, Server RND CA OCSP CRL Hash Serial # Validity Time Good ---------------- Signature PA Certificate request (Vidder root only) Server Done Server Key Exchange Server Key Exchange βG --------------- Cr, Sr, βG Signature Random starting point “β” Calculate βG βG --------------- Cr, Sr, βG Hash subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert Serial # subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert

Mutual TLS: Client Verifies Server Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert CA OCSP CRL Valid cert chain Not expired Not revoked Controller’s cert is trusted !!! PA βG Serial # Validity Time ---------------- Signature Good OCSP Response subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert Hash Hash Equal ? Equal ? Original Hash Original Hash Server Hello Selected SSL version, Selected Cipher, Session Id = RND, Server RND Certificate request (Vidder root only) Server Done Server Key Exchange βG --------------- Cr, Sr, βG Signature subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert Hash Cr, Sr, βG Hash Equal ?

Mutual TLS: Client Key, Client Cert, Verify Client Serial # Validity Time ---------------- Signature Good OCSP Response OCSP Response subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert CA OCSP CRL Hash Serial # Validity Time Hash Valid cert chain Not expired Equal ? Serial # Good ---------------- Signature Not revoked Original Hash Client’s cert is trusted !!! PA Serial # Validity Time ---------------- Signature Good OCSP Response Client is trusted !!! Hash Certificate Verify Hash All text Signature Hash αG Equal ? Equal ? Original Hash subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert Random starting point “α” Calculate αG αG Certificate Verify Hash All text Signature subj: Vidder issuer: Vidder ---------------- Signature Vidder Public Root Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert

Mutual TLS: Calculate Final ECDH Key, Derive Session Keys OCSP CRL subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert subj: Vidder Vidder Public Root Cert subj: Client Client Public Client Cert Find point ECDH on the elliptic curve Premaster key (Kpm) = x coord of ECDH Master Key (Km) = PRF(Kpm, "master secret", Cr, Sr) Iterate PRF(Km, "key expansion", Sr, Cr) for AES keys: Client Key, Server Key, Client IV, Server IV Created β Received αG ECDH = β(αG) PA Created α Received βG ECDH = α(βG)

Mutual TLS: Client Change Cipher Spec, Server Integrity Check subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert CA OCSP CRL subj: Ctrl Ctrl Public Controller Cert subj: Vidder Vidder Public Root Cert PA Certificate Verify Hash All text Signature Hash Equal ? Equal ? Change Cypher Spec Certificate Verify Hash All text Signature

Mutual TLS: Server Change Cipher Spec, Client Integrity Check subj: Client issuer: Vidder ---------------- Signature Client Public Client Cert CA OCSP CRL subj: Ctrl Ctrl Public Controller Cert subj: Vidder Vidder Public Root Cert Change Cypher Spec Certificate Verify Signature Hash All text subj: Ctrl issuer: Vidder ---------------- Signature Ctrl Public Controller Cert PA Certificate Verify Hash All text Hash Signature Equal ?

Security Assertion Markup Language (SAML)

Security Assertion Markup Language SAML Open standard for browser-based Single Sign-On Typically, extends Active Directory Widely adopted enterprise solution Business-to-business apps & SaaS Service of AD (ADFS) and, soon, Azure Defines 3 rolls Principle – the user or device Service Provider (SP) – the app to accessed Identity Provider (IdP) – authenticates and authorizes the Principle to the SP

Typical Operation Website with SAML SP plugin Web Server (e.g., Apache) Identity Provider (IdP) Active Directory (AD) Website with SAML SP plugin IdP connected to AD: read access Valid Web page Read Access Port 584 Groups Client wants access to website Member of AD Domain Server cookie Intercepted by SP, no valid cookie SP Plugin Signed Session XML Username Password IdP cookie http 302 redirect to IdP Signed Auth’n Request IdP requests credentials (can be MFA) User provides credentials Call made to AD 2 things returned: Cookie to the IdP Session XML file to the server SP validates signature get URL Completes request to web server Client receives web page, cookie Name x5hwotb