Secure Industrial Device Connectivity with Low-Overhead TLS

Slide 1

Slide 1 text

Secure Industrial Device Connectivity with Low-Overhead TLS Tuesday, October 3, 2017 1:10PM-2:10PM

Slide 2

Slide 2 text

Chris Conlon - Engineering Manager, wolfSSL - B.S. from Montana State University (Bozeman, MT) - Software engineer at wolfSSL (7 years) Contact Info: - Email: chris@wolfssl.com - Twitter: @c_conlon

Slide 3

Slide 3 text

A. – B. – C. – D. – E. F.

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

● ● ● ○ ● ○

Slide 7

Slide 7 text

● ○

Slide 8

Slide 8 text

● Original Image Encrypted using ECB mode Modes other than ECB

Slide 9

Slide 9 text

● ○

Slide 10

Slide 10 text

● ○

Slide 11

Slide 11 text

● ● ● ● ○

Slide 12

Slide 12 text

● ● ● ● ○

Slide 13

Slide 13 text

● ○ ○ ○ ○ ● ○

Slide 14

Slide 14 text

● ● ● ● ○

Slide 15

Slide 15 text

● ● ○ By Original schema: A.J. Han Vinck, University of Duisburg-EssenSVG version: Flugaal - A.J. Han Vinck, Introduction to public key cryptography, p. 16, Public Domain, https://commons.wikimedia.org/w/index.php?curid=17063048

Slide 16

Slide 16 text

● ○ ● ○ ■ ■ ■

Slide 17

Slide 17 text

● ○ ■

Slide 18

Slide 18 text

● ● ●

Slide 19

Slide 19 text

● ● ○ ● ●

Slide 20

Slide 20 text

● ● ●

Slide 21

Slide 21 text

● ● ○ ○ ○ ○

Slide 22

Slide 22 text

● “Progressive” is a subjective term ● These slides talk about crypto algorithms that are: ○ New, modern ○ Becoming widely accepted ○ Have been integrated into SSL/TLS with cipher suites

Slide 23

Slide 23 text

● ChaCha20 ● Poly1305 ● Curve25519 ● Ed25519 Created by Daniel Bernstein a research professor at the University of Illinois, Chicago Chacha20-Poly1305 AEAD used in Google over HTTPS Ed25519 and ChaCha20-Poly1305 AEAD used in Apple’s HomeKit (iOS Security)

Slide 24

Slide 24 text

● Fast stream cipher ● Based from Salsa20 stream cipher using a different quarter-round process giving it more diffusion ● Can be used for AEAD encryption with Poly1305 ● Was published by Bernstein in 2008 Used by ● Google Chrome ● TinySSH ● Apple HomeKit ● wolfSSL

Slide 25

Slide 25 text

● To provide authenticity of messages (MAC) ● Extremely fast in comparison to others ● Introduced by a presentation given from Bernstein in 2002 ● Naming scheme from using polynomial-evaluation MAC (Message Authentication Code) over a prime field Z/(2^130 - 5)

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Used by ● Tor ● Google Chrome ● Apple iOS ● wolfSSL Generic Montgomery curve. Reference 5

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Used by ● Tera Term ● GnuPG ● wolfSSL Generic Twisted Edwards Curve. Reference 6

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

1. Privacy + Prevent eavesdropping 2. Authentication + Prevent impersonation 3. Integrity + Prevent modification

Slide 33

Slide 33 text

● Current SSL / TLS / DTLS versions ● ● ● ● ● ● ● RFC 6101 RFC 2246 RFC 4346 RFC 5246

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

● Most TLS implementations run on top of a BSD socket API ● Since TLS sits ON TOP of the transport layer, you can theoretically run it on top of ANY transport medium: ○ Serial connection (RS-232) ○ Proprietary transport layer ○ Memory buffers ○ etc.

Slide 36

Slide 36 text

● Uses variety of crypto algorithms ● A common CIPHER SUITE is negotiated during TLS Handshake Protocol_keyexchange_WITH_bulkencryption_mode_messageauth TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA Hash Functions SHA, SHA-256, ... Block and Stream Ciphers 3DES, AES, Camellia, ... Public Key Algorithms RSA, ECC, NTRU, ...

Slide 37

Slide 37 text

● Four sub-protocols: 1. Handshake Protocol 2. Change Cipher Spec Protocol 3. Alert Protocol 4. Record Protocol ● Responsible for negotiating a session, includes: ○ Session identifier ○ Authentication (one-way or mutual) ○ Using compression ○ Agreeing on set of algorithms ○ Calculation of master secret

Slide 38

Slide 38 text

● Four sub-protocols: 1. Handshake Protocol 2. Change Cipher Spec Protocol 3. Alert Protocol 4. Record Protocol ● Signals transitions in ciphering strategies ● Sent by client and server ● Notifies receiving party that subsequent records will be protected under newly negotiated CipherSpec and keys

Slide 39

Slide 39 text

● Four sub-protocols: 1. Handshake Protocol 2. Change Cipher Spec Protocol 3. Alert Protocol 4. Record Protocol ● Convey severity and description of alert ● Either “warning” or “fatal” ● Fatal results in immediate termination of connection ● Encrypted and compressed as per CipherSpec

Slide 40

Slide 40 text

● Four sub-protocols: 1. Handshake Protocol 2. Change Cipher Spec Protocol 3. Alert Protocol 4. Record Protocol

Slide 41

Slide 41 text

● TLS Record Header Format

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

● Handshake Protocol Format

Slide 44

Slide 44 text

● Client Hello ○ ○ ■ ■ ■ ■ ■ ■ Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request

Slide 45

Slide 45 text

● Client Hello Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request

Slide 46

Slide 46 text

Client Hello Server Hello Certificate Server Key Exchange Certificate Request Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Server Hello Done Hello Verify Request ● Hello Verify Request ○ ○ ○

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

● Hello Extensions ○ ■ ○ ■ ○

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

● X.509 is a standard for PKI (public key infrastructure) ● Some things specified by it include: ○ Public key certificates ○ Certificate revocation lists ○ Certificate path validation algorithm (CA / cert chain structure) ● Structure is expressed in ASN.1 syntax

Slide 68

Slide 68 text

● Filename Extensions: ○ .pem ■ “Privacy-enhanced Electronic Mail” ■ Base64-encoded DER certificate ○ .der, .cer, .crt ■ Binary DER form ● Others include ○ .p7b, .p7c (PKCS#7) – standard for signing/encrypting data ○ .p12 (PKCS#12) – bundle certs and private keys ○ .pfx (predecessor to .p12)

Slide 69

Slide 69 text

● Structure of X.509v3 certificate is as follows: ● Certificate ○ Version ○ Serial Number ○ Algorithm ID ○ Issuer ○ Validity ■ Not Before ■ Not After ○ Subject ○ Subject Public Key Info ■ Public Key Algorithm ■ Subject Public Key ○ Issuer Unique Identifier (optional) ○ Subject Unique Identifier (optional) ○ Extensions (optional) ○ … ● Certificate Signature Algorithm ● Certificate Signature

Slide 70

Slide 70 text

● A list of certificates followed by one or more CA certificates, where: ○ The Issuer of each certificate matches the Subject of the next ○ Each cert is signed by the private key of the following cert ○ The last cert in the chain (although not sent in the SSL/TLS handshake) is the “root CA”

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

August 2013 - Work on TLS 1.3 begins April 17, 2014 - Draft 00, 01 July 7, 2014 - Draft 02 October 27, 2014 - Draft 03 January 3, 2015 - Draft 04 March 9, 2015 - Draft 05 June 29, 2015 - Draft 06 July 8, 2015 - Draft 07 August 28, 2015 - Draft 08 October 5, 2015 - Draft 09 October 19, 2015 - Draft 10 December 28, 2015 - Draft 11 February 2016 - TLS Working Group Workshop to analyze TLS 1.3 designs March 21, 2016 - Draft 12 May 22, 2016 - Draft 13 July 11, 2016 - Draft 14 August 17, 2016 - Draft 15 September 22, 2016 - Draft 16 October 20, 2016 - Draft 17 October 26, 2016 - Draft 18 March 10, 2017 - Draft 19 April 28, 2017 - Draft 20 July 3, 2017 - Draft 21 ● In development for over 4 years now ● 21 drafts so far

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Algorithm Changes ● Symmetric algorithm list has been pruned of all “legacy” algorithms ● Remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) ● Ciphersuite concept has changed to separate authentication and key exchange mechanisms from the record protection algorithm and a hash to be used with key derivation function and HMAC

Slide 75

Slide 75 text

Zero-RTT Mode ● Performance enhancement ● Saves a round-trip at connection setup for some application data ● At the cost of some security properties

Slide 76

Slide 76 text

More Encrypted Handshake Messages ● All handshake messages after the ServerHello are now encrypted ● New EncryptedExtension allows extensions previously sent in the clear in ServerHello to also be encrypted

Slide 77

Slide 77 text

Redesigned Key Derivation Functions ● Allows for easier analysis by cryptographers due to improved key separation properties ● HMAC-based Extract-and-Expand Key Derivation Function (HKDF) used

Slide 78

Slide 78 text

ECC is Included ● Now included in the base spec ● Includes new signature algorithms (ex: ed25519, ed448) ● Point format negotiation removed in favor of single point format per curve

Slide 79

Slide 79 text

Other Crypto Improvements ● Removed ○ Compression ○ Custom DHE groups ○ DSA ● RSA padding changed to use PSS

Slide 80

Slide 80 text

Version Negotiation Removed ● TLS 1.2 included version negotiation mechanism ● TLS 1.3 removes this in favor of a version list in an extension ● Increases compatibility with servers which incorrectly implemented version negotiation

Slide 81

Slide 81 text

Session Resumption ● Session resumption with and without server-side state removed ● PSK-based ciphersuites of earlier TLS versions removed ● Replaced by a single new PSK exchange

Slide 82

Slide 82 text

Supports 3 basic key exchange modes: a. (EC)DHE (both finite field and elliptic curve varieties) b. PSK-only c. PSK with (EC)DHE

Slide 83

Slide 83 text

Using wolfSSL as a demonstration

Slide 84

Slide 84 text

● Make sure your application is compiled with the SAME preprocessor defines as the TLS library. ● When using Autoconf, simply include #include int main() { return 0; }

Slide 85

Slide 85 text

● The main wolfSSL header for SSL/TLS is #include #include int main() { return 0; }

Slide 86

Slide 86 text

● wolfSSL has two main structures: ○ WOLFSSL - SSL/TLS session ○ WOLFSSL_CTX - SSL/TLS context #include #include int main() { WOLFSSL_CTX* ctx; WOLFSSL* ssl; return 0; }

Slide 87

Slide 87 text

● Initialize wolfSSL library ● Optionally, enable debug output (also define DEBUG_WOLFSSL) /* initialize wolfSSL library */ wolfSSL_Init(); /* enable wolfSSL debug output */ wolfSSL_Debugging_ON();

Slide 88

Slide 88 text

● Create wolfSSL context (ex: using TLS 1.2) ● Enable (or set) peer verification WOLFSSL_CTX* ctx; ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method()); /* turn on peer verification, register verify callback */ wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, myVerify);

Slide 89

Slide 89 text

● Load trusted root CA certificate, from DER-formatted buffer ● Or from PEM or DER formatted file int ret; ret = wolfSSL_CTX_load_verify_buffer(ctx, ca_cert_der_2048, sizeof(ca_cert_der_2048), SSL_FILETYPE_ASN1); int ret; ret = wolfSSL_CTX_load_verify_locations(ctx, verifyCert, 0);

Slide 90

Slide 90 text

● After socket has been created and connect()’ed, create wolfSSL session: ● Pass established socket file descriptor to wolfSSL WOLFSSL* ssl; if ((ssl = wolfSSL_new(ctx)) == NULL) /* error out */ wolfSSL_set_fd(ssl, sockfd);

Slide 91

Slide 91 text

● Initiate SSL/TLS connection, do handshake with peer ● Write data using: /* client side */ ret = wolfSSL_connect(ssl); if (ret != SSL_SUCCESS) /* error out */ /* server side */ ret = wolfSSL_accept(ssl); if (ret != SSL_SUCCESS) /* error out */ ret = wolfSSL_write(ssl, msg, msgSz);

Slide 92

Slide 92 text

● And read data using: ● Shutdown SSL/TLS session: ret = wolfSSL_read(ssl, reply, sizeof(reply)); wolfSSL_shutdown(ssl);

Slide 93

Slide 93 text

● And finally, free resources: wolfSSL_free(ssl); wolfSSL_CTX_free(ctx); wolfSSL_Cleanup();

Slide 94

Slide 94 text

● PKI and X.509 Optimizations ● Algorithm Choices and Performance ● Footprint Optimization ● TLS Session Cache ● Hardware Crypto and Assembly Optimizations ● Stack vs. Heap Usage ● Math Library Selection ● TLS Record Size

Slide 95

Slide 95 text

● Use appropriate Key Sizes ○ Smaller = faster, less memory usage ○ Larger = more secure ● Remain conscious of algorithm selection ○ Some algorithms are more performant than others ○ Some algorithms require more/less memory ● Certificate formats affect footprint size (DER vs. PEM) ● Keep certificate chain lengths in mind when designing PKI

Slide 96

Slide 96 text

Ref: NIST SP800-57 Part 1

Slide 97

Slide 97 text

keylength.com Recommended key lengths across several organization recommendations.

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

No content

Slide 100

Slide 100 text

● Take advantage of hardware cryptography ○ Reduces the footprint size by eliminating software algorithms ○ Increases performance vs. software crypto

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

● Take Advantage of Assembly Optimizations ○ Currently Available defines in wolfSSL: TFM_X86 TFM_X86_64 TFM_SSE2 TFM_ARM TFM_PPC32 TFM_PPC64 TFM_AVR32 TFM_ASM

Slide 103

Slide 103 text

● Optimize footprint (FLASH usage) of library ○ Compile out unneeded algorithms ■ Example: “./configure --disable-arc4 --disable-sha” ○ Disable error strings ■ Remove strings corresponding to error codes ○ Disable debug symbols ■ Example: “./configure --disable-debug”

Slide 104

Slide 104 text

● Adjust the Session Cache ○ TLS Session Cache sizes are configurable (wolfSSL defaults to 33 sessions, about 3k RAM) ■ NO_SESSION_CACHE ● Save ~3kB ■ SMALL_SESSION_CACHE ● 6 sessions (less than 500 bytes RAM) ■ MEDIUM_SESSION_CACHE ● 1055 sessions (200 sessions/minute) ■ BIG_SESSION_CACHE ● 20,027 sessions ■ HUGE_SESSION_CACHE ● 65,791 sessions (13,000 sessions/minute or over 200/second)

Slide 105

Slide 105 text

● Preference between stack vs heap allocation? ○ Different math library choices ○ Different compile-time build options ○ Performance of memory on stack vs heap

Slide 106

Slide 106 text

● RSA Cipher Suites (wolfSSL) Math Library Key Size Peak Stack Use Peak Heap Use fastmath 1024 10k 9k fastmath 2048 13k 11k normal 1024 6k 14k normal 2048 7k 17k

Slide 107

Slide 107 text

● ECC Cipher Suites (wolfSSL) Math Library Key Size Peak Stack Use Peak Heap Use fastmath 256 7k 12k normal 256 6k 15k

Slide 108

Slide 108 text

● wolfSSL fastmath notes ○ FP_MAX_BITS should be set to twice the maximum key size if key is modable by 32 ■ For 2048-bit RSA keys, should be set to 4096 ■ For 256-bit ECC keys, should be set to 512 ■ Non-32 multiple sizes should be (keysize * 2) + size of digit bit (32 typically) ○ TFM_TIMING_RESISTANT ■ Reduces stack usage ○ ECC_TIMING_RESISTANT ■ Reduces heap usage, but slower

Slide 109

Slide 109 text

● TLS Record Size ○ RFC specified maximum as 2^14 bytes (plus some overhead) ○ Can be reduced in two ways: ■ Manually lowering the buffer size on client and server ● Must control both client and server ■ Using the TLS Maximum Fragment Length Extension ● Server must support, otherwise ignores