Implementing SSL/TLS Using Cryptography and PKI

Real-world cryptography SSL/TLSJoshua DaviesDirector of Architecture 2XofficeAuthor of Implementing SSL/TLS Using Cryptography and PKIOutlineCryptographic conceptsSymmetric CryptographyPublic-key cryptographyDigital SignaturesCertificatesSSL/TLSHandshakeAdvanced/optional componentsDigital SecurityPrivacyIntegrityAuthenticationAuthorizationNon-repudiation (I can prove you did it)Privacy - EncryptionC = Ek(P), P = Dk(C); K is a secret parameterCiphers: standard algorithms such as DES, 3DES, AES, RC4, Blowfish, IDEA hundreds moreSSL/TLS provisionally supports any cipherMost implementations support DES, 3DES, AES and RC4Called symmetric because the same key is used for encryption and decryptionDESOldest digital cipher still in useDeveloped by IBM for the NSA in 1974Fixed 56-bit key sizeDES High level

DES One round

3DESTriples DES key size by running the DES algorithm three timesEncryptDecryptEncryptK1K2K3Rijndael/AESNIST started looking for a replacement for DES in 2001Rijndael supports 128, 192 and 256-bit keysAES Encryption

Block Ciphers and PaddingBlock ciphers require exactly n bytes of input if the plaintext is shorter, it must be paddedPadding must be done securely to avoid giving away keying materialBlock Ciphers and CBC modeIf the plaintext block P is encrypted twice with the same key, C will be identicalGives attacker some information on the structure of PCBC mode XORs each block with the output of the previous block (first block is XORed with a special value called the initialization vector)RC4Stream, rather than a block, cipherGenerates a single keystream as long as the plaintextNo need for CBC or paddingRC4 Encryption

The problem with encryption key exchangeKeys must be managed securely, but a secure channel cant be established without a keyPublic-key cryptography creates two separate keys one for encryption, one for decryptionPublic-key cryptography - RSAThree numbers e, d, n such that (me)d%n=me and n are the public key, d is the private keyc = me%nm = cd%n (distributivity of modulus operator)e, d, and n are long at least 512 bitsSlow runtime - generally used to exchange symmetric keysDiffie-Hellman Key ExchangeVirtually unused, but TLS 1.0 mandates it be supportedCan only be used for secret exchange, not for general encryptionDiffie-HellmanClientgenerate random aYc = (ga%p)Z = Ysa%pServergenerate random bYs=(gb%p)Z = Ycb%pElliptic-Curve CryptographyRelatively new, not much commercial supportBased on operations on the curve y2=x3+ax+bSimilar to Diffie-Hellman, but replaces exponentiation with elliptic curve operationsProvides similar security to Diffie-Hellman and RSA with far smaller numbers

Adding Points on an elliptic curve

Computing P3 from P1 and P2x3=2-x1-x2y3=(x1-x3)-y1=(y2-y1)/(x2-x1)Unless P1=P2=3x12+a/2y1

Large Number ArithmeticPublic key cryptography requires arbitrary precision mathFloating point decimals arent good enough, because they lose precisionLarge number arithmetic takes a long time and uses a lot of memoryLarge Number Multiplication 123 x456 738+ 6150+49200 56088[(4x103)+(5x102)+6(101)]123(4x103)123+(5x102)123+6(101)123

Binary Multiplication double and add1101x101011010000000001101000001101000110100110101101001110000010Binary Exponentiation square and multiplyx10xxxxxxxxxx(xxxxx)(xxxxx)(xxxxx)2((xx)(xx)x)2((xx)2x)2(((x2)2x)2Efficient, but leads to timing attacksEach operation takes long enough that it can be measured Missing multiplication operations allow an attacker to measure how many 1s are in the exponentSolution is to perform the multiplication at each step and throw the results awayKey exchange over an insecure channelServerClientsend public key pubEpub(K)C = Ek(M)Man-in-the middle attackServerClientsend public key pubEpub(K)C = Ek(M)Attackersend public key pubC = Ek(M)Epub(Dpriv(K))Prove Identity through digital signaturesUpside-down public key cryptographys = md%nm = se%nDocument surrogates with secure hashesPublic-key cryptography is slowSign secure hashes of original documentsMD5 (128-bit)SHA (-1=160-bit, -256, -384, -512)DSA Signature generationNIST standard for document signatures; doesnt actually encrypt anythingk = (c%(q-1)) + 1r = (gk % p) % qz = secure message hashs = ((k-1%q)(z+xr))%qr and s are the signature, g, p & q are shared and publicDSA Signature Verificationw = s-1%qz = hash(message)u1 = (zw) % qu2 = (rw) % qv = (( gu1yu2)%p)%qif v r, signature is rejectedCan replace exponentiation with Elliptic Curve operations to create ECDSAProviding Message Integrity with HMACCan secure hashes be used symmetrically?

X.509 Certificates distribution of public keysPublic keys are distributed in x.509 certificate filesX.509 certificates are signed by a certificate authority (CA)CA public keys are in turn distributed as x.509 certificate filesCertificate-Related Browser errors:Certificate Expired

Certificate-Related Browser errors:Domain-name mismatch

Certificate-Related Browser errors:Untrusted Signer

What do all of these actually mean?A certificate serves two primary purposes:1) Provide a public key by which the browser and the server may exchange data securely over a public medium2) Prove correct ownership of a websiteCertificate Format - Issuer

Certificate Trust Chains

Trusted Certificate AuthoritiesKeep a mapping of public keys of trusted CAsLook up public key and validate signature on each certificate

Certificate Format Validity Period

Certificate Format - Subject

Must match domainnameRoles and ResponsibilitiesCASenderReceiverGenerate Key Pair, self signGenerate Key PairWrap in CSRDistribute certificateStore CA keyVerify Info, Sign CertificateDistribute Signed CertValidate CA SignatureSign with private keyVerify SignatureMust be done out of bandMust be done out of bandPutting it all together SSL handshakeServerClientServer Hello (select a cipher suite)Client Hello (supported suites)Server CertificateDoneEpub(Key Exchange)Change Cipher SpecChange Cipher SpecVulnerable to replay attacksThis works, but an attacker can record an exchange and replay it again and againIn order to guard against replay attacks, work a variable state into the handshake and authenticate the entire handshakeThe finished messages contain a hash of all messagesServerClientServer Hello (select a cipher suite)Client Hello (supported suites)Server CertificateDoneEpub(Key Exchange)Change Cipher SpecEk(Finished)Change Cipher SpecEk(Finished)hashhashClient Hello

Server Hello

Keys arent exchange directlyClient Key Exchange includes a premaster secretThis is passed to the Pseudo-Random function, which is based on secure hashes, to generate the master secretThe master secret is split into cryptography and HMAC keys

Bleichenbacher AttackTry to deduce the private key by returning an invalid key exchange messageIf the server responds with a handshake completion error rather than an invalid message error, one bit of private key information is leakedSolution: ignore malformed key exchange and complete the handshakeComputing master secret

Server Name ExtensionTLS has no notion of host namesProblematic with shared sites which certificate to respond with?SNI client hello extension allows the client to specify which host its trying to connect toSession ResumptionKey exchange is time-consumingHTTP is based around a lot of short transactionsSession resumption allows both sides to remember keying material to be reusedEphemeral Key ExchangeCertificate-less key exchangeMust be based on Diffie-HellmanNo authentication of server, vulnerable to man-in-the middle attacksMutual AuthenticationThe server can insist that the client verify itself as wellClient and server may have a different list of trusted certificate authoritiesClient doesnt have an identity to validateSession RenegotiationDiscard keying material, negotiate new keysEither side can initiate client initiates by sending new client hello, server initiates by sending explicit renegotiation request (called a hello request)Renegotiation handshake is encrypted using previously negotiated key materialPrefix attacksServerClientconnectAttackerhandshake completeconnectrenegotiateprepend some datasend dataExtension 0xFF01Simple solution reject renegotiation attemptsRFC 5746 describes a client and server extension that allows one session to be securely tied back to anotherHistory of SSL/TLS1995: Netscape releases a browser with SSLv21996: SSLv2 is found to be flawed, SSLv3 is specified1999: IETF takes over SSL, renames it TLS, blesses version 1.02006: TLS 1.1 is released, minor revisions2008: TLS 1.2 is released, major revisionsMore Information

L0

R0

K1

Feistel Function

L1=R0

R1=L0 xor f(R0, K1)

K2

Feistel Function

L2=R1

R2=L1 xor f(R1, K2)

K3

Feistel Function

L3=R2

R3=L2 xor f(R2, K2)

...

L15=R14

R15=L14 xor f(R14,K15)

K16

Feistel Function

L16=R15

R16=L15 xor f(R15, K16)