TLS Cryptography In-Depth E-Book

Dr. Paul Duplys

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 878

Veröffentlichungsjahr: 2024

Beschreibung

TLS is the most widely used cryptographic protocol today, enabling e-commerce, online banking, and secure online communication. Written by Dr. Paul Duplys, Security, Privacy & Safety Research Lead at Bosch, and Dr. Roland Schmitz, Internet Security Professor at Stuttgart Media University, this book will help you gain a deep understanding of how and why TLS works, how past attacks on TLS were possible, and how vulnerabilities that enabled them were addressed in the latest TLS version 1.3. By exploring the inner workings of TLS, you’ll be able to configure it and use it more securely.
Starting with the basic concepts, you’ll be led step by step through the world of modern cryptography, guided by the TLS protocol. As you advance, you’ll be learning about the necessary mathematical concepts from scratch. Topics such as public-key cryptography based on elliptic curves will be explained with a view on real-world applications in TLS. With easy-to-understand concepts, you’ll find out how secret keys are generated and exchanged in TLS, and how they are used to creating a secure channel between a client and a server.
By the end of this book, you’ll have the knowledge to configure TLS servers securely. Moreover, you’ll have gained a deep knowledge of the cryptographic primitives that make up TLS.

Leseprobe

Contents

TLS Cryptography In-Depth

TLS Cryptography In-Depth

Contributors

About the authors

About the reviewers

Preface

Who is this book for

What this book covers

To get the most out of this book

Conventions used

Get in touch

Share Your Thoughts

Download a free PDF copy of this book

Part I Getting Started

Chapter 1: The Role of Cryptography in the Connected World

1.1 Evolution of cryptography

1.2 The advent of TLS and the internet

1.3 Increasing connectivity

1.4 Increasing complexity

1.5 Example attacks

1.6 Summary

Chapter 2: Secure Channel and the CIA Triad

2.1 Technical requirements

2.2 Preliminaries

2.3 Confidentiality

2.4 Integrity

2.5 Authentication

2.6 Secure channels and the CIA triad

2.7 Summary

Chapter 3: A Secret to Share

3.1 Secret keys and Kerckhoffs’s principle

3.2 Cryptographic keys

3.3 Key space

3.4 Key length

3.5 Crypto-agility and information half-life

3.6 Key establishment

3.7 Randomness and entropy

3.8 Summary

Chapter 4: Encryption and Decryption

4.1 Preliminaries

4.2 Symmetric cryptosystems

4.3 Information-theoretical security (perfect secrecy)

4.4 Computational security

4.5 Pseudorandomness

4.6 Summary

Chapter 5: Entity Authentication

5.1 The identity concept

5.2 Authorization and authenticated key establishment

5.3 Message authentication versus entity authentication

5.4 Password-based authentication

5.5 Challenge-response protocols

5.6 Summary

Chapter 6: Transport Layer Security at a Glance

6.1 Birth of the World Wide Web

6.2 Early web browsers

6.3 From SSL to TLS

6.4 TLS overview

6.5 TLS version 1.2

6.6 TLS version 1.3

6.7 Major differences between TLS versions 1.3 and 1.2

6.8 Summary

Part II Shaking Hands

Chapter 7: Public-Key Cryptography

7.1 Preliminaries

7.2 Groups

7.3 The Diffie-Hellman key-exchange protocol

7.4 Security of Diffie-Hellman key exchange

7.5 The ElGamal encryption scheme

7.6 Finite fields

7.7 The RSA algorithm

7.8 Security of the RSA algorithm

7.9 Authenticated key agreement

7.10 Public-key cryptography in TLS 1.3

7.11 Hybrid cryptosystems

7.12 Summary

Chapter 8: Elliptic Curves

8.1 What are elliptic curves?

8.2 Elliptic curves as abelian groups

8.3 Elliptic curves over finite fields

8.4 Security of elliptic curves

8.5 Elliptic curves in TLS 1.3

8.6 Summary

Chapter 9: Digital Signatures

9.1 General considerations

9.2 RSA-based signatures

9.3 Digital signatures based on discrete logarithms

9.4 Digital signatures in TLS 1.3

9.5 Summary

Chapter 10: Digital Certificates and Certification Authorities

10.1 What is a digital certificate?

10.2 X.509 certificates

10.3 Main components of a public-key infrastructure

10.4 Rogue CAs

10.5 Digital certificates in TLS

10.6 Summary

Chapter 11: Hash Functions and Message Authentication Codes

11.1 The need for authenticity and integrity

11.2 What cryptographic guarantees does encryption provide?

11.3 One-way functions

11.4 Hash functions

11.5 Message authentication codes

11.6 MAC versus CRC

11.7 Hash functions in TLS 1.3

11.8 Summary

Chapter 12: Secrets and Keys in TLS 1.3

12.1 Key establishment in TLS 1.3

12.2 TLS secrets

12.3 KDFs in TLS

12.4 Updating TLS secrets

12.5 TLS keys

12.6 TLS key exchange messages

12.7 Summary

Chapter 13: TLS Handshake Protocol Revisited

13.1 TLS client state machine

13.2 TLS server state machine

13.3 Finished message

13.4 Early data

13.5 Post-handshake messages

13.6 OpenSSL s_client

13.7 Summary

Part III Off the Record

Chapter 14: Block Ciphers and Their Modes of Operation

14.1 The big picture

14.2 General principles

14.3 The AES block cipher

14.4 Modes of operation

14.5 Block ciphers in TLS 1.3

14.6 Summary

Chapter 15: Authenticated Encryption

15.1 Preliminaries

15.2 Authenticated encryption – generic composition

15.3 Security of generic composition

15.4 Authenticated ciphers

15.5 Counter with cipher block chaining message authentication code (CCM)

15.6 AEAD in TLS 1.3

15.7 Summary

Chapter 16: The Galois Counter Mode

16.1 Preliminaries

16.2 GCM security

16.3 GCM performance

16.4 Summary

Chapter 17: TLS Record Protocol Revisited

17.1 TLS Record protocol

17.2 TLS record layer

17.3 TLS record payload protection

17.4 Per-record nonce

17.5 Record padding

17.6 Limits on key usage

17.7 An experiment with the OpenSSL s_client

17.8 Summary

Chapter 18: TLS Cipher Suites

18.1 Symmetric cipher suites in TLS 1.3

18.2 Long-term security

18.3 ChaCha20

18.4 Poly1305

18.5 ChaCha20-Poly1305 AEAD construction

18.6 Mandatory-to-implement cipher suites

18.7 Summary

Part IV Bleeding Hearts and Biting Poodles

Chapter 19: Attacks on Cryptography

19.1 Preliminary remarks

19.2 Passive versus active attacks

19.3 Local versus remote attacks

19.4 Interactive versus non-interactive attacks

19.5 Attacks on cryptographic protocols

19.6 Attacks on encryption schemes

19.7 Attacks on hash functions

19.8 Summary

Chapter 20: Attacks on the TLS Handshake Protocol

20.1 Downgrade attacks

20.2 Logjam

20.3 SLOTH

20.4 Padding oracle attacks on TLS handshake

20.5 Bleichenbacher attack

20.6 Improvements of Bleichenbacher’s attack

20.7 Insecure renegotiation

20.8 Triple Handshake attack

20.9 Summary

Chapter 21: Attacks on the TLS Record Protocol

21.1 Lucky 13

21.2 POODLE

21.3 BEAST

21.4 Sweet32

21.5 Compression-based attacks

21.6 Summary

Chapter 22: Attacks on TLS Implementations

22.1 SMACK

22.2 FREAK

22.3 Truncation attacks

22.4 Heartbleed

22.5 Insecure encryption activation

22.6 Random number generation

22.7 BERserk attack

22.8 Cloudbleed

22.9 Timing attacks

22.10 Summary

Bibliography

Index

Other Books You Might Enjoy

Packt is searching for authors like you

Share Your Thoughts

Download a free PDF copy of this book

Landmarks

Title Page

Cover

Table of Contents

TLS Cryptography In-Depth

TLS Cryptography In-Depth

Explore the intricacies of modern cryptography and theinner workings of TLS

Dr. Paul Duplys

Dr. Roland Schmitz

TLS Cryptography In-Depth

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Neha Sharma

Senior Editor: Arun Nadar

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Project Coordinator: Ashwini Gowda

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Vijay Kamble

Marketing Coordinator: Marylou De Mello

First published: December 2023

Production reference: 203012024

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square Birmingham B3 1RB, UK

ISBN 978-1-80461-195-1

www.packtpub.com

Contributors

About the authors

Dr. Paul Duplys is chief expert for cybersecurity at the department for technical strategies and enabling within the Mobility sector of Robert Bosch GmbH, a Tier-1 automotive supplier and manufacturer of industrial, residential, and consumer goods. Previous to this position, he spent over 12 years with Bosch Corporate Research, where he led the security and privacy research program and conducted applied research in various fields of information security. Paul’s research interests include security automation, software security, security economics, software engineering, and AI. Paul holds a PhD degree in computer science from the the University of Tübingen, Germany.

Dr. Roland Schmitz has been a professor of internet security at the Stuttgart Media University (HdM) since 2001. Prior to joining HdM, from 1995 to 2001, he worked as a research engineer at Deutsche Telekom, with a focus on mobile security and digital signature standardization. At HdM, Roland teaches courses on internet security, system security, security engineering, digital rights management, theoretical computer science, discrete mathematics, and game physics. He has published numerous scientific papers in the fields of internet and multimedia security. Moreover, he has authored and co-authored several books. Roland holds a PhD degree in mathematics from Technical University Braunschweig, Germany.

Writing this book has been an amazing journey, and it is our great pleasure to thank the people who have accompanied and supported us during this time: our project coordinators at Packt Publishing, Ashwini Gowda and Arun Nadar, and our meticulous technical reviewers, Andreas Bartelt, Simon Greiner, and Christos Grecos.

About the reviewers

Andreas Bartelt holds a diploma in computer science (bioinformatics) and has specialized in cybersecurity topics for more than 20 years. He works at Robert Bosch GmbH as an expert in the field of cryptography and secures the deployment of cryptographic protocols such as TLS, IPsec, and SSH. Andreas is also a BSD enthusiast and has acquired extensive practical experience in securing POSIX-based operating systems (e.g., Linux) as well as their secure integration with hypervisors (e.g., Xen).

Dr. Christos Grecos (SM IEEE 2006, FSPIE 2023) is the chair and professor of the CS department at Arkansas State University. He was vice dean of PG research at NCI Ireland, chair of the CS department at Central Washington University (US), and dean of FCIT at Sohar University (Oman). He also has 13 years of experience in the UK as a professor, head of school, and associate dean for research. His research interests include image/video compression standards, processing and analysis, networking, and computer vision. He is on the editorial board of many international journals and has been invited to give talks at various international conferences. He has obtained significant funding for his research from several agencies, such as the UK EPSRC, UK TSB, the EU, and the Irish HEC.

Simon Greiner has been working as an automotive security expert for Robert Bosch GmbH, one of the largest automotive suppliers, for more than five years. He works in the lead engineering team for security and supports projects on different topics regarding security engineering, such as threat and risk analysis, security concepts, testing, and implementation security. He also supports pre-development projects on security topics, mainly in the context of autonomous driving. Before joining Robert Bosch GmbH, Simon obtained his PhD in computer science with a specialization in information security from the Karlsruhe Institute of Technology, Germany.

Table of Contents

I Getting Started

The Role of Cryptography in the Connected World

1.1 Evolution of cryptography

1.2 The advent of TLS and the internet

1.3 Increasing connectivity

1.3.1 Connectivity versus security – larger attack surface

1.3.2 Connectivity versus marginal attack cost

1.3.3 Connectivity versus scaling attacks

1.4 Increasing complexity

1.4.1 Complexity versus security – features

1.4.2 Complexity versus security – emergent behavior

1.4.3 Complexity versus security – bugs

1.5 Example attacks

1.5.1 The Mirai botnet

1.5.2 Operation Aurora

1.5.3 The Jeep hack

1.5.4 Commonalities

1.6 Summary

Secure Channel and the CIA Triad

2.1 Technical requirements

2.2 Preliminaries

2.3 Confidentiality

2.4 Integrity

2.5 Authentication

2.5.1 Message authentication

2.5.2 Entity authentication

2.6 Secure channels and the CIA triad

2.7 Summary

A Secret to Share

3.1 Secret keys and Kerckhoffs’s principle

3.2 Cryptographic keys

3.2.1 One key for each task

3.2.2 Key change and session keys

3.3 Key space

3.4 Key length

3.5 Crypto-agility and information half-life

3.6 Key establishment

3.6.1 Key transport

3.6.2 Key agreement

3.7 Randomness and entropy

3.7.1 Information-theoretic definition of entropy

3.7.2 Entropy in cryptography

3.7.3 True randomness and pseudo-randomness

3.8 Summary

Encryption and Decryption

4.1 Preliminaries

4.2 Symmetric cryptosystems

4.3 Information-theoretical security (perfect secrecy)

4.3.1 A first example

4.3.2 The one-time pad

4.4 Computational security

4.4.1 Asymptotic approach and efficient computation

4.4.2 Negligible probabilities

4.5 Pseudorandomness

4.5.1 Stream ciphers

4.5.2 RC4

4.5.3 Pseudorandom functions and chosen-plaintext attacks

4.6 Summary

Entity Authentication

5.1 The identity concept

5.1.1 Basic principles of identification protocols

5.1.2 Basic factors for identification

5.2 Authorization and authenticated key establishment

5.3 Message authentication versus entity authentication

5.4 Password-based authentication

5.4.1 Brief history of password-based authentication

5.4.2 Storing passwords

5.4.3 Disadvantages of password-based authentication

5.5 Challenge-response protocols

5.5.1 Ensuring freshness

5.5.2 Challenge-response using symmetric keys

5.5.3 Challenge-response using (keyed) one-way functions

5.5.4 Challenge-response using public-key cryptography

5.6 Summary

Transport Layer Security at a Glance

6.1 Birth of the World Wide Web

6.2 Early web browsers

6.3 From SSL to TLS

6.4 TLS overview

6.4.1 TLS terminology

6.4.2 CIA triad in TLS

6.4.3 TLS within the internet protocol stack

6.5 TLS version 1.2

6.5.1 Subprotocols in TLS version 1.2

6.5.2 A typical TLS 1.2 connection

6.5.3 Session resumption

6.6 TLS version 1.3

6.6.1 Handshake protocol

6.6.2 Error handling in the TLS 1.3 handshake

6.6.3 Session resumption and PSKs

6.6.4 Zero round-trip time mode

6.7 Major differences between TLS versions 1.3 and 1.2

6.8 Summary

II Shaking Hands

Public-Key Cryptography

7.1 Preliminaries

7.2 Groups

7.2.1 Examples of groups

7.2.2 The discrete logarithm problem

7.3 The Diffie-Hellman key-exchange protocol

7.4 Security of Diffie-Hellman key exchange

7.4.1 Discrete logarithm problem

7.4.2 The Diffie-Hellman problem

7.4.3 Authenticity of public keys

7.5 The ElGamal encryption scheme

7.6 Finite fields

7.6.1 Fields of order p

7.6.2 Fields of order pk

7.7 The RSA algorithm

7.7.1 Euler’s totient function

7.7.2 Key pair generation

7.7.3 The encryption function

7.7.4 The decryption function

7.8 Security of the RSA algorithm

7.8.1 The factoring problem

7.8.2 The RSA problem

7.8.3 Authenticity of public keys

7.9 Authenticated key agreement

7.9.1 The Station-to-Station (STS) protocol

7.10 Public-key cryptography in TLS 1.3

7.10.1 Client key shares and server key shares

7.10.2 Supported groups

7.10.3 Finite Field Diffie-Hellman in TLS

7.11 Hybrid cryptosystems

7.11.1 High-level description of hybrid cryptosystems

7.11.2 Hybrid encryption

7.11.3 Example – Hybrid Public Key Encryption

7.11.4 Hybrid cryptosystems in modern cryptography

7.12 Summary

Elliptic Curves

8.1 What are elliptic curves?

8.1.1 Reduced Weierstrass form

8.1.2 Smoothness

8.1.3 Projective coordinates

8.2 Elliptic curves as abelian groups

8.2.1 Geometrical viewpoint

8.2.2 Explicit formulae

8.3 Elliptic curves over finite fields

8.3.1 Elliptic curves over 𝔽p

8.3.2 Elliptic curves over 𝔽2k

8.3.3 Discrete logarithms and Diffie-Hellman key exchange protocol

8.4 Security of elliptic curves

8.4.1 Generic algorithms for finding discrete logarithms

8.4.2 Algorithms for solving special cases of ECDLP

8.4.3 Secure elliptic curves – the mathematical perspective

8.4.4 A potential backdoor in Dual_EC_DRBG

8.4.5 Secure elliptic curves: security engineering perspective

8.5 Elliptic curves in TLS 1.3

8.5.1 Curve secp256r1

8.5.2 Curve secp384r1

8.5.3 Curve secp521r1

8.5.4 Curve 25519

8.5.5 Curve 448

8.5.6 Elliptic curve Diffie-Hellman in TLS 1.3

8.5.7 ECDH parameters in TLS 1.3

8.5.8 Example: ECDH with curve x25519

8.6 Summary

Digital Signatures

9.1 General considerations

9.2 RSA-based signatures

9.3 Digital signatures based on discrete logarithms

9.3.1 Digital Signature Algorithm (DSA)

9.3.2 Elliptic Curve Digital Signature Algorithm (ECDSA)

9.4 Digital signatures in TLS 1.3

9.4.1 RSASSA-PKCS1-v1_5 algorithms

9.4.2 RSASSA-PSS algorithms

9.4.3 ECDSA algorithms

9.4.4 EdDSA algorithms

9.4.5 Legacy algorithms

9.5 Summary

Digital Certificates and Certification Authorities

10.1 What is a digital certificate?

10.2 X.509 certificates

10.2.1 Minimum data fields

10.2.2 X.509v3 extension fields

10.2.3 Enrollment

10.2.4 Certificate revocation lists

10.2.5 Online Certificate Status Protocol (OCSP)

10.2.6 X.509 trust model

10.3 Main components of a public-key infrastructure

10.4 Rogue CAs

10.5 Digital certificates in TLS

10.5.1 TLS extensions

10.5.2 Encrypted extensions

10.5.3 Certificate request

10.5.4 Signature algorithms in TLS certificates

10.5.5 Certificates and TLS authentication messages

10.5.6 The Certificate message

10.5.7 The CertificateVerify message

10.5.8 Server certificate selection

10.5.9 Client certificate selection

10.5.10 OID filters

10.5.11 Receiving a Certificate message

10.5.12 The certificate_authorities extension

10.6 Summary

Hash Functions and Message Authentication Codes

11.1 The need for authenticity and integrity

11.2 What cryptographic guarantees does encryption provide?

11.3 One-way functions

11.3.1 Mathematical properties

11.3.2 Candidate one-way functions

11.4 Hash functions

11.4.1 Collision resistance

11.4.2 One-way property

11.4.3 Merkle-Damgard construction

11.4.4 Sponge construction

11.5 Message authentication codes

11.5.1 How to compute a MAC

11.5.2 HMAC construction

11.6 MAC versus CRC

11.7 Hash functions in TLS 1.3

11.7.1 Hash functions in ClientHello

11.7.2 Hash Functions in TLS 1.3 signature schemes

11.7.3 Hash functions in authentication-related messages

11.7.4 Transcript hash

11.7.5 Hash functions in TLS key derivation

11.8 Summary

Secrets and Keys in TLS 1.3

12.1 Key establishment in TLS 1.3

12.2 TLS secrets

12.2.1 Early secret

12.2.2 Binder key

12.2.3 Bob’s client early traffic secret.

12.2.4 Exporter secrets

12.2.5 Derived secrets

12.2.6 Handshake secret

12.2.7 Handshake traffic secrets

12.2.8 Master secret

12.2.9 Application traffic secrets

12.2.10 Resumption master secret

12.3 KDFs in TLS

12.3.1 HKDF-Extract

12.3.2 HKDF-Expand

12.3.3 HKDF-Expand-Label

12.3.4 Derive-Secret

12.4 Updating TLS secrets

12.5 TLS keys

12.5.1 Exporter values

12.5.2 Generation of TLS keys

12.5.3 Key update

12.6 TLS key exchange messages

12.6.1 Cryptographic negotiation

12.6.2 ClientHello

12.6.3 ServerHello

12.6.4 HelloRetryRequest

12.7 Summary

TLS Handshake Protocol Revisited

13.1 TLS client state machine

13.2 TLS server state machine

13.3 Finished message

13.4 Early data

13.5 Post-handshake messages

13.5.1 The NewSessionTicket message

13.5.2 Post-handshake authentication

13.5.3 Key and initialization vector update

13.6 OpenSSL s_client

13.6.1 Installing OpenSSL

13.6.2 Using openssl-s_client

13.6.3 TLS experiments with openssl-s_client

13.7 Summary

III Off the Record

Block Ciphers and Their Modes of Operation

14.1 The big picture

14.2 General principles

14.2.1 Advantages and disadvantages of block ciphers

14.2.2 Confusion and diffusion

14.2.3 Pseudorandom functions

14.2.4 Pseudorandom permutations

14.2.5 Substitution-permutation networks and Feistel networks

14.2.6 Constants in cryptographic algorithms

14.2.7 DES S-boxes

14.2.8 Nothing-up-my-sleeves numbers

14.3 The AES block cipher

14.3.1 Overall structure

14.3.2 Round function

14.3.3 Key scheduling

14.4 Modes of operation

14.4.1 ECB mode

14.4.2 CBC mode

14.4.3 CBC-MAC

14.4.4 OFB mode

14.4.5 CTR mode

14.4.6 XTS mode

14.5 Block ciphers in TLS 1.3

14.6 Summary

Authenticated Encryption

15.1 Preliminaries

15.1.1 Indistinguishability under a chosen-plaintext attack

15.1.2 Indistinguishability under a chosen-ciphertext attack

15.1.3 Non-malleability under a chosen-plaintext attack

15.1.4 Plaintext integrity

15.1.5 Ciphertext integrity

15.2 Authenticated encryption – generic composition

15.2.1 Encrypt-and-MAC

15.2.2 MAC-then-encrypt

15.2.3 Encrypt-then-MAC

15.3 Security of generic composition

15.4 Authenticated ciphers

15.4.1 Authenticated encryption with associated data

15.4.2 Avoiding predictability with nonces

15.5 Counter with cipher block chaining message authentication code (CCM)

15.5.1 Authenticated encryption with CCM

15.5.2 Authenticated decryption with CCM

15.6 AEAD in TLS 1.3

15.7 Summary

The Galois Counter Mode

16.1 Preliminaries

16.1.1 The Galois field 𝔽2128

16.1.2 GHASH function

16.1.3 The AES-GCM authenticated cipher

16.2 GCM security

16.3 GCM performance

16.4 Summary

TLS Record Protocol Revisited

17.1 TLS Record protocol

17.2 TLS record layer

17.3 TLS record payload protection

17.4 Per-record nonce

17.5 Record padding

17.6 Limits on key usage

17.7 An experiment with the OpenSSL s_client

17.7.1 Getting started

17.7.2 Retrieving a website via TLS

17.7.3 Analyzing the TLS record

17.8 Summary

TLS Cipher Suites

18.1 Symmetric cipher suites in TLS 1.3

18.2 Long-term security

18.2.1 Advances in cryptanalysis

18.2.2 Cryptographic agility

18.2.3 Standby ciphers

18.3 ChaCha20

18.3.1 ChaCha20 quarter round

18.3.2 The ChaCha20 block function

18.3.3 ChaCha20 encryption algorithm

18.4 Poly1305

18.4.1 Generating the Poly1305 key using ChaCha20

18.5 ChaCha20-Poly1305 AEAD construction

18.6 Mandatory-to-implement cipher suites

18.7 Summary

IV Bleeding Hearts and Biting Poodles

Attacks on Cryptography

19.1 Preliminary remarks

19.2 Passive versus active attacks

19.3 Local versus remote attacks

19.3.1 The scalability of local and remote attacks

19.4 Interactive versus non-interactive attacks

19.5 Attacks on cryptographic protocols

19.5.1 Impersonation attacks

19.5.2 Man-in-the-middle attacks

19.5.3 Replay attacks

19.5.4 Interleaving attacks

19.5.5 Reflection attacks

19.6 Attacks on encryption schemes

19.6.1 Brute-force attack

19.6.2 Forward search attack

19.6.3 Ciphertext-only attack

19.6.4 Known-plaintext attack

19.6.5 Chosen-plaintext attack

19.6.6 Padding oracle attacks

19.6.7 Adaptive chosen-plaintext attack

19.6.8 Chosen-ciphertext attack

19.6.9 Adaptive chosen-ciphertext attack

19.7 Attacks on hash functions

19.7.1 Birthday attack

19.7.2 Dictionary attack

19.7.3 Rainbow tables

19.8 Summary

Attacks on the TLS Handshake Protocol

20.1 Downgrade attacks

20.1.1 Taxonomy of downgrade attacks

20.1.2 Cipher suite downgrade attacks

20.1.3 The Downgrade Dance

20.2 Logjam

20.3 SLOTH

20.4 Padding oracle attacks on TLS handshake

20.5 Bleichenbacher attack

20.5.1 The attack

20.5.2 Countermeasures

20.6 Improvements of Bleichenbacher’s attack

20.6.1 Bad version oracles

20.6.2 Side channel attacks

20.6.3 DROWN

20.6.4 ROBOT

20.7 Insecure renegotiation

20.8 Triple Handshake attack

20.8.1 The attack

20.8.2 Countermeasures in TLS 1.3

20.9 Summary

Attacks on the TLS Record Protocol

21.1 Lucky 13

21.1.1 The encryption process

21.1.2 The timing signal

21.1.3 The attack

21.2 POODLE

21.2.1 Attacker model

21.2.2 The attack

21.3 BEAST

21.3.1 The attack

21.3.2 Countermeasures

21.4 Sweet32

21.4.1 The attack

21.4.2 Countermeasures in TLS 1.3

21.5 Compression-based attacks

21.5.1 Lossless compression algorithms

21.5.2 The compression side channel

21.5.3 Brief history of compression in TLS

21.5.4 CRIME

21.5.5 TIME

21.5.6 BREACH

21.5.7 HEIST

21.6 Summary

Attacks on TLS Implementations

22.1 SMACK

22.2 FREAK

22.3 Truncation attacks

22.4 Heartbleed

22.4.1 TLS Heartbeat extension

22.4.2 The Heartbleed bug

22.4.3 The bugfix

22.5 Insecure encryption activation

22.6 Random number generation

22.7 BERserk attack

22.8 Cloudbleed

22.8.1 Details of the the Cloudbleed bug

22.9 Timing attacks

22.9.1 Side channel attacks

22.9.2 Raccoon

22.10 Summary

Part I Getting Started

In this part, we set the scene for the Transport Layer Security (TLS) protocol. After discussing the history of the internet and TLS, we introduce the three basic security services provided by TLS, namely, confidentiality, integrity and authenticity, and give a first, high-level overview of TLS.

More specifically, we look at the role of cryptography in the modern connected world and highlight the reasons why Secure Sockets Layer (SSL), a predecessor of TLS, was invented in the early 1990s. Next, we explain why connectivity and complexity are the main drivers of cybersecurity and, in turn, cryptography in the modern connected world. We then introduce two cryptographic concepts: the secure channel and the CIAtriad. We then show what cryptographic keys are, how the confidentiality of information transmitted between two parties can be protected using encryption and decryption, and how these parties can ensure that they are actually talking to each other rather than to an attacker. Finally, we give a high-level overview of the TLS protocol to illustrate how the theoretical concepts of cryptography are applied in TLS.

This part contains the following chapters:

Chapter 1, The Role of Cryptography in the Connected World

Chapter 2, Secure Channel and the CIA Triad

Chapter 3, A Secret to Share

Chapter 4, Encryption and Decryption

Chapter 5, Entity Authentication

Chapter 6, Transport Layer Security at a Glance

1

The Role of Cryptography in the Connected World

In this introductory chapter, we try to provide some answers to the following questions:

Why are there so many insecure IT systems?

How can cryptography help to mitigate our security problems?

Our core argument is that the simultaneous growth of connectivity and complexity of IT systems has led to an explosion of the attack surface, and that modern cryptography plays an important role in reducing that attack surface.

After a brief discussion of how the field of cryptography evolved from an exotic field appreciated by a select few to an absolutely critical skill for the design and operation of nearly every modern IT product, we will look at some recent real-world security incidents and attacks in order to illustrate our claim. This will allow you to understand why cryptography matters from a higher strategic perspective.

1.1 Evolution of cryptography

Over the past four decades or so, cryptography has evolved from an exotic field known to a select few into a fundamental skill for the design and operation of modern IT systems. Today, nearly every modern product, from the bank card in your pocket to the server farm running your favorite cloud services, requires some form of cryptography to protect it and its users against cyberattacks. Consequently, it has found its way into mainstream computer science and software engineering.

Figure 1.1: Number of publications at IACR conferences on cryptology over the years

Cryptography and its counterpart cryptanalysis were basically unknown outside of military and intelligence services until the mid 1970s. According to [172], Cryptography is the practice and study of techniques for secure communication inthe presence of adversaries; it deals with the development and application of cryptographic mechanisms. Cryptanalysis is the study of cryptographic mechanisms’ weaknesses, aimed at finding mathematical ways to render these mechanisms ineffective. Taken together, cryptography and cryptanalysis form what’s called cryptology.

In 1967, David Kahn, an American historian, journalist, and writer, published a book titled The Codebreakers – The Story of Secret Writing, which is considered to be the first extensive treatment and a comprehensive report of the history of cryptography and military intelligence from ancient Egypt to modern times [93]. Kahn’s book introduced cryptology to a broader audience. Its content was, however, necessarily restricted to symmetric cryptography. In symmetric cryptography, the sender and receiver of a message share a common secret key and use it for both encrypting and decrypting. The problem of how sender and receiver should exchange the secret in a secure way was considered out of scope.

This changed in 1976, when the seminal paper New Directions in Cryptography by Whitfield Diffie and Martin Hellman appeared in volume IT-22 of IEEE Transactions on Information Security [49]. In that publication, Diffie and Hellman described a novel method for securely agreeing on a secret key over a public channel based on the so-called discrete logarithm problem. Moreover, they suggested for the first time that the sender and receiver might use different keys for encrypting (the public key) and decrypting (the private key) and thereby invented the field of asymmetric cryptography.

Figure 1.2: From left to right: Ralph Merkle, Martin Hellman, Whitfield Diffie [69]

While there were scientific works on cryptography dating back to the early 1970s, the publication by Diffie and Hellman is the first publicly available paper in which the use of a private key and a corresponding public key is proposed. This paper is considered to be the start of cryptography in the public domain. In 2002, Diffie and Hellman suggested their algorithm should be called Diffie-Hellman-Merkle key exchange because of Ralph Merkle’s significant contribution to the invention of asymmetric cryptography [185].

In 1977, the three MIT mathematicians Ron Rivest, Adi Shamir, and Len Adleman took up the suggestion by Diffie and Hellman and published the first asymmetric encryption algorithm, the RSA algorithm [151], which is based on yet another well-known mathematical problem, the factoring problem for large integers.

Figure 1.3: From left to right: Adi Shamir, Ron Rivest, Len Adleman [152]

The invention of asymmetric cryptography did not make symmetric cryptography obsolete. On the contrary, both fields have complementary strengths and weaknesses and can be efficiently combined in what is today called hybridcryptosystems. The Transport Layer Security (TLS) protocol is a very good example of a hybrid cryptosystem.

Today, cryptography is a well-known (albeit mostly little understood in depth) topic in the IT community and an integral part of software development. As an example, as of July 2022, the OpenSSL library repository on GitHub contains over 31,500 commits by 686 contributors. Cryptography is also an integral part of numerous computer science and information security curricula, and numerous universities all over the world offer degrees in information security.

Why did this happen, and which factors led to this development and popularized cryptography within a comparably short period of time? To a large extent, this paradigm shift is a result of three—arguably still ongoing—developments in information technology that radically changed the role of cryptography in the modern connected world:

The advent of the internet and the ever increasing need to transfer large amounts of data over untrusted channels, which also fostered the development of TLS

The introduction of connectivity into nearly every new product, from toothbrushes to automobiles

The ever increasing complexity of IT systems, specifically increasing hardware and software complexity

We will now discuss each of these factors in turn.

1.2 The advent of TLS and the internet

We’ll now turn to the original theme of this book, TLS and the cryptographic tools it is made of. TLS is a protocol designed to protect data sent over the internet, so we’ll start with a brief look into the early history of the internet.

Despite its origins as a research project financed by the Defense AdvancedResearch Projects Agency (DARPA), the research agency of the Department of Defence of the United States, most of the main physical components of the internet, such as cables, routers, gateways, and so on, can be (and are) accessed by untrusted third parties. In the early days of the internet, this was not considered a problem, and very few (if any) security measures were introduced into TCP and IP, the internet’s main protocol workhorses, and none of them involved cryptography. However, with more and more people using the internet, and the ever increasing available bandwidth, more and more services kept appearing on the internet, and it was quickly realized that to do real business over the internet, a certain amount of trust was needed that sensitive data such as credit card numbers or passwords did not fall into the wrong hands. Cryptography provides the answer to this problem, because it can guarantee confidentiality (i.e., no one can read the data in transit) and authenticity (i.e., you can verify that you are talking to the right party). TLS and its predecessor SSL are the protocols that implement cryptography on the internet in a secure, usable way.

Starting in 1995, SSL was shipped together with Netscape Navigator to clients. While server-side adoption of SSL was slow at first, by the end of 2021, according to the Internet Security Research Group (ISRG), 83% of web pages loaded by Firefox globally used HTTPS, that is HTTP secured via TLS [87].

Figure 1.4: Percentage of web pages loaded by Firefox using HTTPS [88]

This is a huge success for TLS and the field of cryptography in general, but with it also comes a huge responsibility: we need to constantly monitor whether the algorithms, key lengths, modes of operations, and so on used within TLS are still secure. Moreover, we need to understand how secure algorithms work and how they can interact with each other in a secure way so that we can design secure alternatives if needed.

Maybe we should already stress at this early stage that TLS is not a remedy for all the problems mentioned here. TLS provides channel-based security, meaning that it can only protect data in transit between a client and a server. TLS is very successful in doing so, and how in detail TLS uses cryptography to achieve this goal is the main theme of this book. However, once the data leaves the secure channel, it is up to the endpoints (i.e., client and server) to protect it.

Moreover, cryptography by itself is useless in isolation. To have any practical effect, it has to be integrated into a much larger system. And to ensure that cryptography is effectively protecting that system, there must be no security holes left that would allow an attacker to circumvent its security.

There is a well-known saying among cybersecurity professionals that the security of a system is only as strong as its weakest link. Because there are so many ways to circumvent security – especially in complex systems – cryptography, or rather the cryptographic primitives a system uses, is rarely the weakest link in the chain.

There is, however, one important reason why cryptography is fundamental for the security of information systems, even if there are other security flaws and vulnerabilities. An attacker who is able to break cryptography cannot be detected because a cryptanalytic attack, that is, the breaking of a cryptographic protocol, mechanism or primitive, in most cases leaves no traces of the attack.

If the attacker’s goal is to read the communication, they can simply passively listen to the communication, record the messages and decrypt them later. If the attacker’s goal is to manipulate the target system, they can simply forge arbitrary messages and the system will never be able to distinguish these messages from benign ones sent by legitimate users.

While there are many other sources of insecurity (e.g., software bugs, hardware bugs, and social engineering), the first line of defense is arguably secure communication, which in itself requires a secure channel. And cryptography as a scientific discipline provides the building blocks, methods, protocols, and mechanisms needed to realise secure communication.

1.3 Increasing connectivity

Connectivity allows designers to add novel, unique features to their products and enables new business models with huge revenue potential that simply would not exist without it.

At the same time, connectivity makes it much harder to build secure systems. Similar to Ferguson and Schneier’s argument on security implications of complexity, one can say that there are no connected systems that are secure. Why? Because connecting systems to large, open networks like the internet exposes them to remote attacks. Remote attacks – unlike attacks that require physical access – are much more compelling from the attacker’s perspective because they scale.

1.3.1 Connectivity versus security – larger attack surface

While connectivity enables a multitude of desired features, it also exposes products to remote attacks carried out via the internet. Attacks that require physical access to the target device can only be executed by a limited number of attackers who actually have access to that device, for example, employees of a company in the case of devices in a corporate network. In addition, the need for physical access generally limits the attacker’s window of opportunity.

Connectivity, in contrast, exposes electronic devices and IT systems to remote attacks, leading to a much higher number of potential attackers and threat actors. Moreover, remote attacks – unlike attacks that require physical access to the target – are much more compelling from the attacker’s perspective because they scale.

Another aspect that makes remote attacks practical (and, to a certain extent, rather easy) is the fact that the initial targets are almost always the network-facing interfaces of the devices, which are implemented in software. As we have seen, complex software is almost guaranteed to contain numerous implementation bugs, a number of which can be typically exploited to attack the system. Thus, the trend of increasing software and system complexity inadvertently facilitates remote attacks.

1.3.2 Connectivity versus marginal attack cost

Remote attacks are easy to launch – and hard to defend against – because their marginal cost is essentially zero. After a newly discovered security vulnerability is initially translated into a reliably working exploit, the cost of replicating the attack an additional 10, 100, or 100,000 devices is essentially the same, namely close to zero.

This is because remote attacks are implemented purely in software, and reproducing software as well as accessing devices over public networks effectively costs close to nothing. So, while businesses need to operate large – and costly – internal security organizations to protect their infrastructure, services, and products against cybersecurity attacks, any script kiddie can try to launch a remote attack on a connected product, online service, or corporate infrastructure essentially for free.

1.3.3 Connectivity versus scaling attacks

To summarize, connectivity exposes devices and IT systems to remote attacks that target network-facing software (and, thus, directly benefit from the continuously increasing software complexity), are very cheap to launch, can be launched by a large number of threat actors, and have zero marginal cost.

In addition, there exists a market for zero-day exploits [190] that allows even script kiddies to launch highly sophisticated remote attacks that infest target systems with advanced malware able to open a remote shell and completely take over the infested device.

As a result, connectivity creates an attack surface that facilitates cybersecurity attacks that scale.

1.4 Increasing complexity

While it can be argued that the problem of increasing complexity is not directly mitigated by modern cryptography (in fact, many crypto-related products and standards suffer from this problem themselves), there is no doubt that increasing complexity is in fact a major cause of security problems. We included the complexity problem in our list of crucial factors for the development of cryptography, because cryptography can help limitthe damage caused by attacks that were in turn caused by excessive complexity.

Following Moore’s law [191], a prediction made by the co-founder of Fairchild Semiconductor and Intel Gordon Moore in 1965, the number of transistors in an integrated circuit, particularly in a microprocessor, kept doubling roughly every 2 years (see Figure 1.5).

Figure 1.5: Increasing complexity of hardware: Transistors. Data is taken from https://github.com/barentsen/tech-progress-data

Semiconductor manufacturers were able to build ever bigger and ever more complex hardware with ever more features. This went so far that in the late 1990s, the Semiconductor Industry Association set off an alarm in the industry when it warned that productivity gains in Integrated Circuit (IC) manufacturing were growing faster than the capabilities of Electronic DesignAutomation (EDA) tools used for IC design. Entire companies in the EDA area were successfully built on this premise.

Continuously growing hardware resources paved the way for ever more complex software with ever more functionality. Operating systems became ever more powerful and feature-rich, the number of layers in software stacks kept increasing, and software libraries and frameworks used by programmers became ever more comprehensive. As predicted by a series of software evolution laws formulated by early-day computer scientists Manny Lehman and Les Belady, software exhibited continuing growth and increasing complexity [181] (see also Figure 1.6).

Figure 1.6: Increasing complexity of software: Source Lines of Code (SLOC) in operating systems. Data is taken from https://github.com/barentsen/tech-progress-data

Why should increasing complexity be a problem? According to leading cybersecurity experts Bruce Schneier and Niels Ferguson [65], ”Complexity is theworst enemy of security, and it almost always comes in the form of features oroptions”.

While it might be argued whether complexity really is the worst enemy of security, it is certainly true that complex systems, whether realized in hardware or software, tend to be error-prone. Schneier and Ferguson even claim that thereare no complex systems that are secure.

Complexity negatively affects security in several ways, including the following:

Insufficient testability due to a combinatorial explosion given a large number of features

Unanticipated—and unwanted—behavior that emerges from a complex interplay of individual features

A high number of implementation bugs and, potentially, architectural flaws due to the sheer size of a system

1.4.1 Complexity versus security – features

The following thought experiment illustrates why complexity arising from the number of features or options is a major security risk. Imagine an IT system, say a small web server, whose configuration consists of 30 binary parameters (that is, each parameter has only two possible values, such as on or off). Such a system has more than a billion possible configurations. To guarantee that the system is secure under all configurations, its developers would need to write and run several billion tests: one test for each relevant type of attack (e.g., Denial-of-Service, cross-site scripting, and directory traversal) and each configuration. This is impossible in practice, especially because software changes over time, with new features being added and existing features being refactored. Moreover, real-world IT systems have significantly more than 30 binary parameters. As an example, the NGINX web server has nearly 800 directives for configuring how the NGINX worker processes handle connections.

1.4.2 Complexity versus security – emergent behavior

A related phenomenon that creates security risks in complex systems is the unanticipated emergent behavior. Complex systems tend to have properties that their parts do not have on their own, that is, properties or behaviors that emerge only when the parts interact [186]. Prime examples for security vulnerabilities arising from emergent behavior are time-of-check-to-time-of-use (TOCTOU) attacks exploiting concurrency failures, replay attacks on cryptographic protocols where an attacker reuses an out-of-date message, and side-channel attacks exploiting unintended interplay between micro-architectural features for speculative execution.

1.4.3 Complexity versus security – bugs

Currently available software engineering processes, methods, and tools do not guarantee error-free software. Various studies on software quality indicate that, on average, 1,000 lines of source code contain 30-80 bugs [174]. In rare cases, examples of extensively tested software were reported that contain 0.5-3 bugs per 1,000 lines of code [125].

However, even a rate of 0.5-3 bugs per 1,000 lines of code is far from sufficient for most practical software systems. As an example, the Linux kernel 5.11, released in 2021, has around 30 million lines of code, roughly 14% of which are considered the ”core” part (arch, kernel, and mm directories). Consequently, even with extensive testing and validation, the Linux 5.11 core code alone would contain approximately 2,100-12,600 bugs.

And this is only the operating system core without any applications. As of July 2022, the popular Apache HTTP server consists of about 1.5 million lines of code. So, even assuming the low rate of 0.5-3 bugs per 1,000 lines of code, adding a web server to the core system would account for another 750-4,500 bugs.

Figure 1.7: Increase of Linux kernel size over the years

What is even more concerning is the rate of bugs doesn’t seem to improve significantly enough over time to cope with the increasing software size. The extensively tested software having 0.5-3 bugs per 1,000 lines of code mentioned above was reported by Myers in 1986 [125]. On the other hand, a study performed by Carnegie Mellon University’s CyLab institute in 2004 identified 0.17 bugs per 1,000 lines of code in the Linux 2.6 kernel, a total of 985 bugs, of which 627 were in critical parts of the kernel. This amounts to slightly more than halving the bug rate at best – over almost 20 years.

Clearly, in that same period of time from 1986 to 2004 the size of typical software has more than doubled. As an example, Linux version 1.0, released in 1994, had about 170,000 lines of code. In comparison, Linux kernel 2.6, which was released in 2003, already had 8.1 million lines of code. This is approximately a 47-fold increase in size within less than a decade.

Figure 1.8: Reported security vulnerabilities per year

1.5 Example attacks

The combination of these two trends – increase in complexity and increase in connectivity – results in an attack surface explosion. The following examples shall serve to illustrate this point.

1.5.1 The Mirai botnet

In late 2016, the internet was hit by a series of massive DistributedDenial-of-Service (DDoS) attacks originating from the Mirai botnet, a large collection of infected devices (so-called bots) remote-controlled by attackers.

The early history of the Mirai botnet can be found in [9]: the first bootstrap scan on August 1 lasted about two hours and infected 834 devices. This initial population continued to scan for new members and within 20 hours, another 64,500 devices were added to the botnet. The infection campaign continued in September, when about 300,000 devices were infected, and reached its peak of 600,000 bots by the end of November. This corresponds to a rate of 2.2-3.4 infected devices per minute or 17.6-27.2 seconds to infect a single device.

Now contrast this with a side-channel or fault attack. Even if we assume that the actual attack – that is, the measurement and processing of the side-channel traces or the injection of a fault – can be carried out in zero time, an attacker would still need time to gain physical access to each target. Now suppose that, on average, the attacker needs one hour to physically access a target (actually, this is a very optimistic assumption from the attacker’s perspective, given that the targets are distributed throughout the globe). In that case, attacking 200,000-300,000 devices would take approximately 22-33 years or 270 to 400 months (as opposed to 2 months in the case of Mirai).

Moreover, any remote attack starts at a network interface of the target system. So the first (and, oftentimes, the only) thing the attacker interacts with is software. But software is complex by nature.

1.5.2 Operation Aurora

In mid-December 2009, Google discovered a highly sophisticated, targeted attack on their corporate infrastructure that resulted in intellectual property theft [73]. During their investigation, Google discovered that at least 20 other large companies from a wide range of businesses had been targeted in a similar way [193].

This series of cyberattacks came to be known as Operation Aurora [193] and were attributed to APT groups based in China. The name was coined by McAfee Labs security researchers based on their discovery that the word Aurora could be found in a file on the attacker’s machine that was later included in malicious binaries used in the attack as part of a file path. Typically, such a file path is inserted by the compiler into the binary to indicate where debug symbols and source code can be found on the developer’s machine. McAfee Labs therefore hypothesized that Aurora could be the name of the operation used by the attackers [179].

According to McAfee, the main target of the attack was source code repositories at high-tech, security, and defense contractor companies. If these repositories were modified in a malicious way, the attack could be spread further to their client companies. Operation Aurora can therefore be considered the first major attack on software supply chains [193].

In response to Aurora, Google shut down its operations in China four months after the incident and migrated away from a purely perimeter-based defenseprinciple. This means devices are not trusted by default anymore, even if they are located within a corporate LAN [198].

1.5.3 The Jeep hack

At the BlackHat 2015 conference, security researchers Charlie Miller and Chris Valasek demonstrated the first remote attack on an unaltered, factory passenger car [120]. In what later became known as the Jeep hack, the researchers demonstrated how the vehicle’s infotainment system, Uconnect, which has both remote connectivity as well as the capability to communicate with other electronic control units within the vehicle, can be used for remote attacks.

Specifically, while systematically examining the vehicle’s attack surface, the researchers discovered an open D-Bus over an IP port on Uconnect, which is essentially an inter-process communication and remote procedure call mechanism. The D-Bus service accessible via the open port allows anyone connected to the infotainment system to execute arbitrary code in an unauthenticated manner.

Miller and Valasek also discovered that the D-Bus port was bound to all network interfaces on the vulnerable Uconnect infotainment system and was therefore accessible remotely over the Sprint mobile network that Uconnect uses for telematics. By connecting to the Sprint network using a femtocell or simply a regular mobile phone, the researchers were able to send remote commands to the vehicle.

From that entry point, Miller and Valasek attacked a chip in the vehicle’s infotainment system by re-writing its firmware to be able to send arbitrary commands over the vehicle’s internal CAN communication network, effectively giving them the ability to completely take over the vehicle.

1.5.4 Commonalities

What do these examples have in common and how does it relate to cryptography? In a nutshell, these examples illustrate what happens in the absence of appropriate cryptography. In all three cases discussed, there was no mechanism in place to verify that the systems were talking to legitimate users and that the messages received were not manipulated while in transit.

In the Mirai example, anyone with knowledge of the IoT devices’ IP addresses would have been able to access their login page. This information can be easily collected by scanning the public internet with tools such as nmap. So the designers’ assumption that the users would change the default device password to a strong individual one was the only line of defense. What the security engineers should have done instead is to add a cryptographic mechanism to give access to the login procedure only to legitimate users, for example, users in possession of a digital certificate or a private key.