TLS

  • Most popular encryption protocol
  • Encrypts from a client (browser) to a server (such as a Facebook server in the example below)
  • HTTPS uses TLS
  • Where can backdoors happen?

In browsers:

  • Root store of trusted public keys
  • For example, geotrust
  • Comes baked into browser
  • For the most part not tampered with (Avast does though)

How TLS works:

Website doesn’t know who you are But we know who the certificate authorities are When connecting to a server, establish session key, which we can use to do symmetric crypto We use a key exchange protocol called Key Establishment = TLS Handshake

TLS Handshake/Key Establishment

Start by knowing public key of geotrust <- cert authority Set up session key k

Must negotiate what cipher to use. Server has PKf, SKf

Client Hello sends:

  • Ciphersuites it can use
  • client random (cr) Server Hello sends:
  • Returns lots of stuff
  • Cipher suite it wants to use
  • Server random (sr)
  • Random a
  • Computes g^a with generator g
  • Also sends generator g
  • and signature

If client and server agree that they want to speak DH (Diffehelman)

  • Group G generator g
  • Easy to find g^x given g and x
  • Hard to find x such that g^x = y given g and y

Client needs to know PKf but can’t just get it from server, in this case Facebook Also don’t want geotrust’s public key Facebook must use SKf to SignSKf(g, g^a, cr, sr) Also sends certificate (PKf, Facebook, issuer:geotrust)

What does Certificate look like? (cert1):

  • Cert(PKf, Facebook, issuer:geotrust)
  • Subject: Facebook
  • Public key: PKf
  • Issuer: geotrust
  • Above 3 (cert1) are signed with geotrust’s secret key SKgeotrust: SignSKgeotrust-short(cert1)

cert2:

  • Subject: geotrust shorterm key
  • PK: PKgeotrust-short
  • Issue: geotrust
  • SignSKgeotrust(cert2)

Now client must verify signature from Facebook:

  • Uses PKf pulled out of cert1, and checks if it corresponds with cr and sr
  • Verifies signature of cert1, using cert2’s PKgeotrust-short
  • Verify cert2 using root store in browser
  • Browser cuts you off if not secure

Must now get session key

Client chooses random b Computes g^b Sends to server

Client grabs g^a, computes g^{ab} (Secret number only known to alice and bob) Server grabs g^b and raises it to the a to compute g^{ab} One sided because client doesn’t have a certificate, only servers do

Computes tuple with ms, key1, key2 using PRF:

  • ms = master secret
  • (ms, k1, k2) = PRFg^{ab}(cr   sr)
  • The PRF is defined in the cipher suite

You MAC transcript1 and 2 to make sure all previous steps were seen by client and server: Client MACms(transcript1)

  • Transcript1 = all previous steps as seen by client Server: MACms(transcript2)
  • Transcript2 = all previous steps as seen by server Server verifies client MAC with ms generated from the PRF with g^{ab} and (cr,sr)

If the MACs check out, client uses session key k1 to encrypt, k2 to decrypt, and server uses session key k2 to encrypt, k1 to decrypt

  • Authenck1(message)
  • Authensk2(message)

Keys are very short lived (deleted after communication) Makes it very hard to decrypt all these newly generated keys Forward secrecy because even if you steal secret key of Facebook, still can’t decrypt past messages. You could forge signatures for all future communications, but can’t decrypt past communications.

Clipper chip protocol

Session key: k1 Golden key: k* c = Enck1(m) Deck1(c) = m Deck*(c) = m Could therefore decrypt all past communication Would be terrible for security world-wide!!!

Other backdoors of TLS

Consider threat of SKf being compromised

  • Can not decrypt past communications (forward secrecy)
  • Impersonate FB in future communications If SKgeotrust was stolen
  • You could impersonate anyone
  • Still have forward secrecy though