Securing Data in Transit -

SECURING DATA IN TRANSIT
Using TLS in Constrained Devices
Copyright 2015 wolfSSL Inc.1

Session Presenters
Chris Conlon
wolfSSL Inc.
chris@wolfssl.com
Jacob Barthelmeh
wolfSSL Inc.
jacob@wolfssl.com

What We’re Covering Today
1. Introduction and History of wolfSSL (5 min)
2. Overview of SSL/TLS, and Crypto (15 min)
3. TLS Enabling a Simple HTTP Client (10 min)
4. Emerging Ciphers and Algorithms (10 min)
5. Time-Permitting Q & A (5 min)

wolfSSL Inc
History, Introduction, and Products
4 Copyright 2015 wolfSSL Inc.

wolfSSL History

About wolfSSL
Founded: 2004
Locations: Bozeman, MT
Seattle, WA
Portland, OR
Our Focus: Open Source Embedded Security
(Apps, Devices, IoT, and Cloud)
Products: - wolfSSL
- wolfSSL FIPS
- wolfCrypt
- wolfSSH
- wolfSCEP
- wolfSSL Inspection
- yaSSL

One Billion Endpoints!
Factory Automation
Automotive / Smart Car
Smart Grid
Cloud Services
Routers
Databases
Connected Home
SensorsBattlefield Communication
Smart Energy Machine-to-Machine
Games
Appliances
Internet of Things
Mobile / Smartphones

Strategic Partnerships

History and Goals
SSL / TLS

SSL/TLS - History and Protocols
● SSL / TLS / DTLS versions
Notes:
● SSL 2.0 is insecure
● SSL = “Secure Sockets Layer”
● TLS = “Transport Layer Security”
● DTLS = “Datagram TLS”

SSL/TLS - Goals
● Enable secure CLIENT / SERVER communication
Privacy + Prevent eavesdropping
Authentication + Prevent impersonation
Integrity + Prevent modification

SSL/TLS - Simplified Analogy
Goals:
A. Talk to the desired person
B. Talk privately (securely)
Alice Bob
? ?

Goals:
Alice Bob

● Goals:
○ Talk to the desired peer
■ X.509 certificates (RSA, ECC)
○ Talk privately (securely)
■ Encryption, Integrity checks

MITM Attacks
● Man in the Middle Attacks
● One of the most prominent attacks TLS tries to prevent

RFC and Protocols
SSL / TLS

TLS - Protocol Specs
● Protocol Specifications
○ RFC 6101: SSL 3.0
○ RFC 2246: TLS 1.0
○ RFC 4346: TLS 1.1
○ RFC 5246: TLS 1.2
○ “Draft”: TLS 1.3

TLS - Protocols and Location

TLS - Sub Protocols
Handshake Protocol
● Responsible for negotiating a session,
includes:
○ Session identifier
○ Peer certificate
○ Compression method
○ Cipher spec
○ Master secret
○ “is resumable”
1
2
3
4(A)
(B)

TLS - Sub Protocols
1
2
3
4(A)
(B)

TLS - Sub Protocols
Change Cipher Spec Protocol
● Signals transitions in ciphering strategies
● Sent by both client and server
● Notifies receiving party that subsequent records
will be protected under newly negotiated
CipherSpec and keys
1
2
3
4(A)
(B)

TLS - Sub Protocols
Alert Protocol
● Convey severity and description of alert
● Either “warning” or “fatal”
● Fatal results in immediate termination of
connection
● Encrypted and compressed as per CipherSpec
1
2
3
4(A)
(B)

TLS - Sub Protocols
Record Protocol
● Layered protocol (Sending Side)
○ Fragments input data into blocks
○ (optionally) compresses data
○ Applies MAC
○ Encrypts
○ Transmits the result
1
2
3
4(A)
(B)

TLS - Sub Protocols
Record Protocol
● Layered protocol (Receiving Side)
○ Decrypts received data
○ Verifies data (using MAC)
○ Decompresses
○ Reassembles
○ Delivers result to higher level
1
2
3
4(A)
(B)

Cipher Suites
SSL / TLS

Cipher Suites: Structure
● Combination of algorithms:
Hash Functions: MD5, SHA-1, SHA-256, ..
Block and Stream Ciphers: AES, 3DES, ChaCha20, ...
Public Key Algorithms: RSA, ECC, NTRU, ...
CIPHER SUITE

Cipher Suites: Structure
Protocol_keyexchange_WITH_bulkencryption_mode_messageauth
Examples:
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

X.509 Certs and Keys
SSL / TLS

Making Sense of X.509
● 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

X.509v3 Certificates
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

X.509v3 Certificates
● 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)
-----BEGIN CERTIFICATE-----
…
…
-----END CERTIFICATE-----

Certificate Chain
● 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”

Certificate Chain

SSL / TLS on Devices
Securing a simple HTTP client with TLS

wolfSSL Library
Features
● C-language based SSL/TLS library
● Standards up to TLS 1.2 and DTLS 1.2
● Focused on size and speed optimization, progressive
● Minimum footprint size of 20-100 kB
● Minimum RAM usage: 1-36kB
● Web server integration (NGINX, Lighttpd, Mongoose, GoAhead)
● OpenSSL Compatibility Layer
● Hardware Crypto Support
● Suite-B Compatible, FIPS 140-2 (Level 1) in process
● Dual Licensed (GPLv2 and Commercial)

wolfSSL + FRDM-K64F
Using wolfSSL in a Simple Embedded Client App

wolfSSL + FRDM-K64F
● Why are we using FRDM-K64F?
○ Simplicity, relevance
● Could as easily use any number of embedded platforms:
○ Microchip PIC32MX/MZ
○ STMicro STM32F2/F4/F7
○ Freescale Kinetis, Coldfire
○ ...

wolfSSL + FRDM-K64F
● wolfSSL is available for download from wolfssl.com:
● And also from GitHub:

wolfSSL + FRDM-K64F
● Or might already be in your IDE!
○ Keil MDK-ARM “Software Pack”
○ Microchip MPLAB Harmony
○ Freescale MQX-SSL

wolfSSL + FRDM-K64F
● wolfSSL has tight integration for Freescale platforms (among
others)
○ FREESCALE_MQX - MQX operating system
○ FREESCALE_MMCAU - mmCAU HW crypto
○ FREESCALE_K70_RNGA - K70 HW RNG
○ FREESCALE_K53_RNGB - K53 HW RNG

wolfSSL + FRDM-K64F
● This platform is being used currently for a new product!
Smart Door Lock Product
● Door Lock = Freescale FRDM-K64F
● Home Gateway = Freescale i.MX6
● Security = wolfSSL

wolfSSL + FRDM-K64F
● Drop wolfSSL into an Existing Project

wolfSSL + FRDM-K64F
● wolfSSL / wolfCrypt Code Structure

wolfSSL + FRDM-K64F
● Configuring the SSL/TLS library
○ Configuring wolfSSL (user_settings.h)
○ Project Properties -> Compiler -> Preprocessor
○ Add WOLFSSL_USER_SETTINGS
○ This file contains wolfSSL-specific configuration defines
○ Based on wolfSSL’s main settings.h file

wolfSSL + FRDM-K64F
● Include wolfSSL header file in main.c
● Initialize wolfSSL library
● Optionally, enable debug output (also define DEBUG_WOLFSSL)
#include “wolfssl/ssl.h”
/* initialize wolfSSL library */
wolfSSL_Init();
/* enable wolfSSL debug output */
wolfSSL_Debugging_ON();

wolfSSL + FRDM-K64F
● Create wolfSSL context (ex: using TLS 1.2)
● Enable (or set) peer verification
● Load trusted root CA certificate, from DER-formatted buffer
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);
int ret;
ret = wolfSSL_CTX_load_verify_buffer(ctx, ca_cert_der_2048,
sizeof(ca_cert_der_2048), SSL_FILETYPE_ASN1)

wolfSSL + FRDM-K64F
● After socket has been created and connect()’ed, create wolfSSL
session:
● Pass established socket file descriptor to wolfSSL
● Initiate SSL/TLS connection, do handshake with peer
WOLFSSL* ssl;
if ((ssl = wolfSSL_new(ctx)) == NULL)
err_sys("wolfSSL_new failed");
wolfSSL_set_fd(ssl, sockfd);
ret = wolfSSL_connect(ssl);
if (ret != SSL_SUCCESS)
err_sys("wolfSSL_connect failed");

wolfSSL + FRDM-K64F
● Write data using:
● And read data using:
wolfSSL_write(ssl, msg, msgSz);
wolfSSL_read(ssl, reply, sizeof(reply));

wolfSSL + FRDM-K64F
● Shutdown SSL/TLS session
● Free resources:
wolfSSL_shutdown(ssl);
wolfSSL_free(ssl);
wolfSSL_CTX_free(ctx);
wolfSSL_Cleanup();

Peak RAM Usage
● RSA Cipher Suites
● ECC Cipher Suites
Math Library Key Size Peak Stack Use Peak Heap Use
fast 1024 10k 9k
fast 2048 13k 11k
normal 1024 6k 14k
normal 2048 7k 17k
Math Library Key Size Peak Stack Use Peak Heap Use
fast 256 7k 12k
normal 256 6k 15k

wolfSSL + FRDM-K64F
It’s as simple as that!
(try it yourself and see)

Emerging Ciphers
What’s hot in the crypto world!

Emerging Ciphers
● 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)

ChaCha20 Info
● Based from Salsa20 stream cipher using a different quarter-
round process giving it more diffusion
● Fast stream cipher that also can have block characteristics
● Can be used for AEAD encryption with Poly1305
● Was published by Bernstein in 2008
Used by
● Google Chrome
● TinySSH
● Apple HomeKit
● wolfSSL
reference 1

ChaCha20 Quarter Round
The heart of ChaCha20 is the quarter round. Operations
performed are (note ^ means xor)
a += b; d ^= a; d <<<= 16;
c += d; b ^= c; b <<<= 12;
a += b; d ^= a; d <<<= 8;
c += d; b ^= c; b <<<= 7;
Where a,b,c, and d are 32 bit unsigned integers.

ChaCha20 Matrix
Data for encryption is arranged into a matrix
constant(0) constant(1) constant(2) constant(3)
key(4) key(5) key(6) key(7)
key(8) key(9) key(10) key(11)
input(12) input(13) input(14) input(15)

ChaCha20 Operation
To complete a double round 8 quarter rounds are performed. The
first 4 quarter rounds consist of a column round. All data used
from the matrix x is in similar columns. The last 4 quarter rounds
consist of a diagonal round. All data used in the quarter round
from the matrix x is in a diagonal pattern.
QUARTERROUND( x0, x4, x8,x12)
QUARTERROUND( x2, x6,x10,x14)
0 1 2 3
4 5 6 7
8 9 10 11
12 13 14 15
0 1 2 3
4 5 6 7
8 9 10 11
12 13 14 15

ChaCha20 Performance

Poly1305 Info
Why it’s used
Extremely fast in comparison to others
To provide authentication of messages
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)
reference 2

Poly1305 Performance

Poly1305 Outline Of Operation
Algorithm
● Set an accumulator h to 0
● Divide the message into chunks c
● h = h + c and then h = rh, where r is part of the key
● Periodically reduce h modulo 2^130 - 5
● After all chunks ( c ) processed reduce h modulo 2^130 - 5
● Add key to h

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

Curve25519 Visualization

Curve25519 Performance

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

Ed25519 Terms
● A is the public key point
● a is the public key
● H(*) is the Sha512 hash of *
● B is the unique point (x, 4/5) ∈ E for which x is positive
● M is the message
● l is the prime 2^252 +
27742317777372353535851937790883648493

Ed25519 Sign / Verify
Steps for signature
1. computing r = H(hb, . . . , h2b−1, M)
2. computing R = rB
3. computing S = (r + H(R, A, M)a) mod l
Verification
SB = R + H(R, A, M)A

Ed25519 Sign

Ed25519 Verify

Ed25519 Fast Single Verify
SB = R + H(R, A, M)A is changed to R = SB - H(R, A, M)A
Saving having to decompress R

Ed25519 Performance

References
1. ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf
2. Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf
3. Curve25519 http://cr.yp.to/ecdh/curve25519-20060209.pdf
4. Ed25519 http://ed25519.cr.yp.to/ed25519-20110926.pdf
Generic Graph Images of Curves From
5. "Montgomery curve1" by Krishnavedala - Own work. Licensed under
CC BY-SA 3.0 via Wikimedia Commons - https://commons.
wikimedia.org/wiki/File:Montgomery_curve1.svg#/media/File:
Montgomery_curve1.svg
6. "Twisted Edwards curve" by Krishnavedala - Own work. Licensed
under CC BY-SA 3.0 via Wikimedia Commons - https://commons.
wikimedia.org/wiki/File:Twisted_Edwards_curve.svg#/media/File:
Twisted_Edwards_curve.svg

THANKS! QUESTIONS?
WOLFSSL
info@wolfssl.com
+1 (425) 245 - 8247
CHRIS CONLON
chris@wolfssl.com
JACOB BARTHELMEH
jacob@wolfssl.com

Session Introduction
• Abstract
• As designers and developers race to pack cool and eye catching features
into “Internet of Things” and connected devices, the security of those
devices oftentimes takes a back seat. After all, how many times does a
manufacturer hear end customers ask: “Is that refrigerator secured with
TLS 1.2 or SSL 3.0?”. Security analysts and hackers aside, the answer is,
hardly ever.
One of the most prominent ways of securing connected devices today is
with TLS, or “Transport Layer Security”. This session will start with a
basic introduction of TLS, working its way up to a demonstration of how
easy it can be to integrate TLS into an existing Internet-connected device.
Also included will be considerations on what ciphers, algorithms, and key
sizes are preferential for various types of projects, touching on both the
enterprise server side as well as the resource constrained device side.
The open source wolfSSL SSL/TLS library will be used for demonstration
purposes.

Session Introduction
• Key Takeaway
• Key takeaways from this session will include an overview of the TLS
protocol, considerations when choosing what algorithms, ciphers and key
sizes to use, and an understanding of how to add TLS to a new or
existing application or device.
• Intended Audience
• The intended audience of this session is designers and engineers
interested in using SSL/TLS to secure their projects or devices. Helpful
prerequisites include a general understanding of C programming.

Securing Data in Transit -

More Related Content

What's hot

Viewers also liked

Similar to Securing Data in Transit -

Securing Data in Transit -