This document provides an overview of securing data in transit using TLS in constrained devices. It begins with introducing the presenters from wolfSSL Inc. and the topics that will be covered, which include an introduction to wolfSSL, an overview of SSL/TLS and cryptography, enabling TLS for a simple HTTP client, emerging ciphers and algorithms, and time for Q&A. It then discusses wolfSSL's history and products. The remainder of the document focuses on explaining SSL/TLS protocols, cipher suites, X.509 certificates, implementing TLS on embedded devices using wolfSSL and the FRDM-K64F board as an example, and emerging ciphers like ChaCha20 and Poly1305.
Secure Communication: Usability and Necessity of SSL/TLSwolfSSL
Network-related applications and devices often use secure communication. Although keeping network communications safe should be a top priority to all developers and engineers, it often gets left behind due to lack of understanding, insufficient funding, or looming deadlines.
Securing a project with SSL shouldn?t have to include a steep learning curve, deep pockets, or an unlimited time frame. By learning a few basics of how things work, where the technology is best used, and what features to look for when trying to choose the right SSL implementation, a developer or engineer can easily, simply, and quickly secure their project - putting both themselves and their employer?s minds at ease.
This presentation will introduce SSL - including why secure communication is important, introductory details about SSL, x509, and the underlying cryptography. It will give an overview of where SSL is used today - including Home Energy, Gaming, Databases, Sensors, VoIP, and more. A description of important items to look for when trying to choose an SSL implementation will give developers and engineers a solid foundation to begin securing their projects with SSL and will enable them to have more informed discussions with potential vendors.
Learn more at www.yassl.com.
This presentation covers the current status of TLS 1.3 in the wolfSSL embedded TLS library (as of the time it was presented). It talks about the Draft status of TLS 1.3, middlebox compatibility, extensions, RSA-PSS negotiation and the specification's progress in the TLSWG (TLS Working Group).
www.wolfssl.com
www.wolfssl.com/tls13
Slides from Todd Ouska's presentation on Secure Memcache at OSCON 2010. To learn more about secure memcache or the CyaSSL embedded SSL library, visit www.yassl.com.
wolfSSL, author of the open source CyaSSL embedded SSL library has made significant progress in 2013 towards bringing the community a more usable, feature-rich, and better supported library for use in an ever-growing range of embedded platforms and environments. This talk will provide an overview of technical progress in the last year and news on the current state of wolfSSL. Details on what's new include the addition of new crypto ciphers and algorithms, better hardware cryptography support, more flexible abstraction layers, a JNI wrapper, new platform support, and better development tool integration. www.wolfssl.com
Joseph Salowey, Tableau Software
Transport Layer Security (TLS) 1.3 is almost here. The protocol that protects most of the Internet secure connections is getting the biggest ever revamp, and is losing a round-trip. We will explore differences between TLS 1.3 and previous versions in detail, focusing on the performance and security improvements of the new protocol as well as some of the challenges we face around securely implementing new features such as 0-RTT resumption.
ION Bucharest, 12 October 2016 - DNSSEC helps prevent attackers from subverting and modifying DNS messages and sending users to wrong (and potentially malicious) sites. So what needs to be done for DNSSEC to be deployed on a large scale? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet. We’ll also examine some of the challenges operators have faced and the opportunities to address those challenges and move deployment forward.
in I.T field we need secure data communication and one of the most worldwide utility is OpenSSL . In our slide you will find basic introduction of OpenSSL and how to use it with black track for local communication data encryption.
Secure Communication: Usability and Necessity of SSL/TLSwolfSSL
Network-related applications and devices often use secure communication. Although keeping network communications safe should be a top priority to all developers and engineers, it often gets left behind due to lack of understanding, insufficient funding, or looming deadlines.
Securing a project with SSL shouldn?t have to include a steep learning curve, deep pockets, or an unlimited time frame. By learning a few basics of how things work, where the technology is best used, and what features to look for when trying to choose the right SSL implementation, a developer or engineer can easily, simply, and quickly secure their project - putting both themselves and their employer?s minds at ease.
This presentation will introduce SSL - including why secure communication is important, introductory details about SSL, x509, and the underlying cryptography. It will give an overview of where SSL is used today - including Home Energy, Gaming, Databases, Sensors, VoIP, and more. A description of important items to look for when trying to choose an SSL implementation will give developers and engineers a solid foundation to begin securing their projects with SSL and will enable them to have more informed discussions with potential vendors.
Learn more at www.yassl.com.
This presentation covers the current status of TLS 1.3 in the wolfSSL embedded TLS library (as of the time it was presented). It talks about the Draft status of TLS 1.3, middlebox compatibility, extensions, RSA-PSS negotiation and the specification's progress in the TLSWG (TLS Working Group).
www.wolfssl.com
www.wolfssl.com/tls13
Slides from Todd Ouska's presentation on Secure Memcache at OSCON 2010. To learn more about secure memcache or the CyaSSL embedded SSL library, visit www.yassl.com.
wolfSSL, author of the open source CyaSSL embedded SSL library has made significant progress in 2013 towards bringing the community a more usable, feature-rich, and better supported library for use in an ever-growing range of embedded platforms and environments. This talk will provide an overview of technical progress in the last year and news on the current state of wolfSSL. Details on what's new include the addition of new crypto ciphers and algorithms, better hardware cryptography support, more flexible abstraction layers, a JNI wrapper, new platform support, and better development tool integration. www.wolfssl.com
Joseph Salowey, Tableau Software
Transport Layer Security (TLS) 1.3 is almost here. The protocol that protects most of the Internet secure connections is getting the biggest ever revamp, and is losing a round-trip. We will explore differences between TLS 1.3 and previous versions in detail, focusing on the performance and security improvements of the new protocol as well as some of the challenges we face around securely implementing new features such as 0-RTT resumption.
ION Bucharest, 12 October 2016 - DNSSEC helps prevent attackers from subverting and modifying DNS messages and sending users to wrong (and potentially malicious) sites. So what needs to be done for DNSSEC to be deployed on a large scale? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet. We’ll also examine some of the challenges operators have faced and the opportunities to address those challenges and move deployment forward.
in I.T field we need secure data communication and one of the most worldwide utility is OpenSSL . In our slide you will find basic introduction of OpenSSL and how to use it with black track for local communication data encryption.
ModSecurity and NGINX: Tuning the OWASP Core Rule Set - EMEANGINX, Inc.
On demand recording: https://www.nginx.com/resources/webinars/modsecurity-and-nginx-tuning-the-owasp-core-rule-set-emea/
In this webinar we discuss how to install the OWASP Core Rule Set (CRS) with NGINX and ModSecurity, as well as how to tune it. The CRS protects against many types of attack, including SQL Injection (SQLi), Local File Inclusion (LFI), and Remote Code Execution (RCE). Watch this webinar to learn:
- How to install the OWASP Core Rule Set (CRS) with ModSecurity
- About the types of attacks the CRS blocks, such SQLi, RFI, and LFI
- How to tune the CRS to minimize false positives
- What it looks like when ModSecurity blocks an attack (in a live demo), and how to interpret the audit log
Registration URL: https://attendee.gotowebinar.com/register/937771661672757762
Webinar ID: 374-977-347
ION Sri Lanka - Why Implement DNSSEC?
Why Implement DNSSEC?
Jitender Kumar (Afilias)
DNSSEC helps prevent attackers from subverting and modifying DNS messages and sending users to wrong (and potentially malicious) sites. So what needs to be done for DNSSEC to be deployed on a large scale? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet. We’ll also examine some of the challenges operators have faced and the opportunities to address those challenges and move deployment forward.
ModSecurity and NGINX: Tuning the OWASP Core Rule SetNGINX, Inc.
On demand recording: nginx.com/watch-on-demand/?id=modsecurity-and-nginx-tuning-the-owasp-core-rule-set
In this webinar we discuss how to install the OWASP Core Rule Set (CRS) with NGINX and ModSecurity, as well as how to tune it. The CRS protects against many types of attack, including SQL Injection (SQLi), Local File Inclusion (LFI), and Remote Code Execution (RCE). Watch this webinar to learn:
- How to install the OWASP Core Rule Set (CRS) with ModSecurity
- About the types of attacks the CRS blocks, such SQLi, RFI, and LFI
- How to tune the CRS to minimize false positives
- What it looks like when ModSecurity blocks an attack (in a live demo), and how to interpret the audit log
Introduction to the design principles behind SSL. This was a relatively basic talk since the audience was a networking class with no previous security experience. Talk given to Cal Poly networking class on November 29, 2007.
ION Islamabad, 25 January 2017
By Champika Wijayatunga, ICANN
DNSSEC helps prevent attackers from subverting and modifying DNS messages and sending users to wrong (and potentially malicious) sites. So what needs to be done for DNSSEC to be deployed on a large scale? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet. We’ll also examine some of the challenges operators have faced and the opportunities to address those challenges and move deployment forward.
Can a set of open source technologies and tools developed by a loosely affiliated community of developers, offered for free over the Internet, compete with proprietary products from multi-billion dollar companies in building networks? Would you be insane to try to run your business on this stuff, or insanely smart? Either way, open source is going to have a huge impact on network operations over the coming decade. Large networks can be built and managed with open source components and tools. Learn about the benefits of using open source.
ION Cape Town, 8 September 2015 - Mark Elkins will explore one organization’s technical solution for deploying DNSSEC support within its country code Top Level Domain (ccTLD). With a goal of making it easier for domain name holders to easily add DNSSEC, we will take a quick look at the DNSSEC implementation strategy, the status/progress of signed domains, and lessons learned and challenges for increasing the percentage of signed domain names.
DANE: The Future of Transport Layer Security (TLS)
Dan York (Internet Society)
If you connect to a “secure” server using TLS/SSL (such as a web server, email server or xmpp server), how do you know you are using the correct certificate? With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“), which allows you to securely specify exactly which TLS/SSL certificate an application should use to connect to your site. DANE has great potential to make the Internet much more secure by marrying the strong integrity protection of DNSSEC with the confidentiality of SSL/TLS certificates. In this session, we will explain how DANE works and how you can use it to secure your websites, email, XMPP, VoIP, and other web services.
ION Cape Town, 8 September 2015 - If you connect to a “secure” server using TLS/SSL (such as a web server, email server or xmpp server), how do you know you are using the correct certificate? With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“), which allows you to securely specify exactly which TLS/SSL certificate an application should use to connect to your site. DANE has great potential to make the Internet much more secure by marrying the strong integrity protection of DNSSEC with the confidentiality of SSL/TLS certificates. In this session, we will explain how DANE works and how you can use it to secure your websites, email, XMPP, VoIP, and other web services.
Deploying DNSSEC: A .LK Case Study
Sashika Suren (LK Domain Registry)
This session will explore LK Domain Registry’s technical solution for deploying DNSSEC support in the .LK registry. With a goal of making it easier for domain name holders to easily add DNSSEC, we will take a quick look at our DNSSEC implementation strategy, the status/progress of .LK signed domains, and our lessons learned and challenges for increasing the percentage of signed domain names.
Securing TCP connections using SSL
Originally developed by Netscape
Communications to allow secure access of a
browser to a Web server, Secure Sockets
Layer (SSL) has become the accepted
standard for Web security.1 The first version
of SSL was never released because of
problems regarding protection of credit
card transactions on the Web. In 1994,
Netscape created SSLv2, which made it
possible to keep credit card numbers
confidential and also authenticate the Web
server with the use of encryption and digital
certificates. In 1995, Netscape strengthened
the cryptographic algorithms and resolved
many of the security problems in SSLv2
with the release of SSLv3. SSLv3 now
supports more security algorithms
than SSLv2.
Zero Day Malware Detection/Prevention Using Open Source SoftwareMyNOG
Zero Day Malware Detection/Prevention Using Open Source Software – Proof of Concept
Fathi Kamil Mohad Zainuddin
Senior Analyst (Malware Research Centre, MyCERT)
yaSSL 2010-2011 Technical and Community UpdatewolfSSL
View slides from Chris Conlon's presentation about yaSSL's progress in the 2010-2011 year at FOSDEM in Brussels, Belgium.
To learn more about yaSSL's product or the CyaSSL embedded SSL library, visit www.yassl.com.
Slides from Chris Conlon's presentation about yaSSL's work porting the CyaSSL embedded SSL library, the MIT Kerberos library, and the Kerberos GSS-API to the Android platform.
To learn more, visit www.yassl.com.
ModSecurity and NGINX: Tuning the OWASP Core Rule Set - EMEANGINX, Inc.
On demand recording: https://www.nginx.com/resources/webinars/modsecurity-and-nginx-tuning-the-owasp-core-rule-set-emea/
In this webinar we discuss how to install the OWASP Core Rule Set (CRS) with NGINX and ModSecurity, as well as how to tune it. The CRS protects against many types of attack, including SQL Injection (SQLi), Local File Inclusion (LFI), and Remote Code Execution (RCE). Watch this webinar to learn:
- How to install the OWASP Core Rule Set (CRS) with ModSecurity
- About the types of attacks the CRS blocks, such SQLi, RFI, and LFI
- How to tune the CRS to minimize false positives
- What it looks like when ModSecurity blocks an attack (in a live demo), and how to interpret the audit log
Registration URL: https://attendee.gotowebinar.com/register/937771661672757762
Webinar ID: 374-977-347
ION Sri Lanka - Why Implement DNSSEC?
Why Implement DNSSEC?
Jitender Kumar (Afilias)
DNSSEC helps prevent attackers from subverting and modifying DNS messages and sending users to wrong (and potentially malicious) sites. So what needs to be done for DNSSEC to be deployed on a large scale? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet. We’ll also examine some of the challenges operators have faced and the opportunities to address those challenges and move deployment forward.
ModSecurity and NGINX: Tuning the OWASP Core Rule SetNGINX, Inc.
On demand recording: nginx.com/watch-on-demand/?id=modsecurity-and-nginx-tuning-the-owasp-core-rule-set
In this webinar we discuss how to install the OWASP Core Rule Set (CRS) with NGINX and ModSecurity, as well as how to tune it. The CRS protects against many types of attack, including SQL Injection (SQLi), Local File Inclusion (LFI), and Remote Code Execution (RCE). Watch this webinar to learn:
- How to install the OWASP Core Rule Set (CRS) with ModSecurity
- About the types of attacks the CRS blocks, such SQLi, RFI, and LFI
- How to tune the CRS to minimize false positives
- What it looks like when ModSecurity blocks an attack (in a live demo), and how to interpret the audit log
Introduction to the design principles behind SSL. This was a relatively basic talk since the audience was a networking class with no previous security experience. Talk given to Cal Poly networking class on November 29, 2007.
ION Islamabad, 25 January 2017
By Champika Wijayatunga, ICANN
DNSSEC helps prevent attackers from subverting and modifying DNS messages and sending users to wrong (and potentially malicious) sites. So what needs to be done for DNSSEC to be deployed on a large scale? We’ll discuss the business reasons for, and financial implications of, deploying DNSSEC, from staying ahead of the technological curve, to staying ahead of your competition, to keeping your customers satisfied and secure on the Internet. We’ll also examine some of the challenges operators have faced and the opportunities to address those challenges and move deployment forward.
Can a set of open source technologies and tools developed by a loosely affiliated community of developers, offered for free over the Internet, compete with proprietary products from multi-billion dollar companies in building networks? Would you be insane to try to run your business on this stuff, or insanely smart? Either way, open source is going to have a huge impact on network operations over the coming decade. Large networks can be built and managed with open source components and tools. Learn about the benefits of using open source.
ION Cape Town, 8 September 2015 - Mark Elkins will explore one organization’s technical solution for deploying DNSSEC support within its country code Top Level Domain (ccTLD). With a goal of making it easier for domain name holders to easily add DNSSEC, we will take a quick look at the DNSSEC implementation strategy, the status/progress of signed domains, and lessons learned and challenges for increasing the percentage of signed domain names.
DANE: The Future of Transport Layer Security (TLS)
Dan York (Internet Society)
If you connect to a “secure” server using TLS/SSL (such as a web server, email server or xmpp server), how do you know you are using the correct certificate? With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“), which allows you to securely specify exactly which TLS/SSL certificate an application should use to connect to your site. DANE has great potential to make the Internet much more secure by marrying the strong integrity protection of DNSSEC with the confidentiality of SSL/TLS certificates. In this session, we will explain how DANE works and how you can use it to secure your websites, email, XMPP, VoIP, and other web services.
ION Cape Town, 8 September 2015 - If you connect to a “secure” server using TLS/SSL (such as a web server, email server or xmpp server), how do you know you are using the correct certificate? With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“), which allows you to securely specify exactly which TLS/SSL certificate an application should use to connect to your site. DANE has great potential to make the Internet much more secure by marrying the strong integrity protection of DNSSEC with the confidentiality of SSL/TLS certificates. In this session, we will explain how DANE works and how you can use it to secure your websites, email, XMPP, VoIP, and other web services.
Deploying DNSSEC: A .LK Case Study
Sashika Suren (LK Domain Registry)
This session will explore LK Domain Registry’s technical solution for deploying DNSSEC support in the .LK registry. With a goal of making it easier for domain name holders to easily add DNSSEC, we will take a quick look at our DNSSEC implementation strategy, the status/progress of .LK signed domains, and our lessons learned and challenges for increasing the percentage of signed domain names.
Securing TCP connections using SSL
Originally developed by Netscape
Communications to allow secure access of a
browser to a Web server, Secure Sockets
Layer (SSL) has become the accepted
standard for Web security.1 The first version
of SSL was never released because of
problems regarding protection of credit
card transactions on the Web. In 1994,
Netscape created SSLv2, which made it
possible to keep credit card numbers
confidential and also authenticate the Web
server with the use of encryption and digital
certificates. In 1995, Netscape strengthened
the cryptographic algorithms and resolved
many of the security problems in SSLv2
with the release of SSLv3. SSLv3 now
supports more security algorithms
than SSLv2.
Zero Day Malware Detection/Prevention Using Open Source SoftwareMyNOG
Zero Day Malware Detection/Prevention Using Open Source Software – Proof of Concept
Fathi Kamil Mohad Zainuddin
Senior Analyst (Malware Research Centre, MyCERT)
yaSSL 2010-2011 Technical and Community UpdatewolfSSL
View slides from Chris Conlon's presentation about yaSSL's progress in the 2010-2011 year at FOSDEM in Brussels, Belgium.
To learn more about yaSSL's product or the CyaSSL embedded SSL library, visit www.yassl.com.
Slides from Chris Conlon's presentation about yaSSL's work porting the CyaSSL embedded SSL library, the MIT Kerberos library, and the Kerberos GSS-API to the Android platform.
To learn more, visit www.yassl.com.
View slides from Chris Conlon's presentation about securing MySQL - including an intro to SSL, and performance statistics for MySQL SSL usage.
To learn more about yaSSL products or the CyaSSL embedded SSL library, visit www.wolfssl.com.
This presentation covers an open source technology (GPG) used to send and receive E-mails securely and also basics of the underlying concepts which this technology uses - Data in Motion and Data at Rest
Case Studies and Lessons Learned from SSL/TLS Certificate Verification Vulner...JPCERT Coordination Center
Recently we’ve seen many vulnerabilities related to improper certificate validation. Those vulnerabilities come from developers’ ignorance or misunderstanding of basic knowledge of certificate validation or insufficient testing of validation code. This presentation starts with the basics of the certificate validation process, surveys several vulnerabilities in the real world, and concludes with lessons learned from real-world vulnerabilities.
This is presented on JavaOne2015.
Are you relatively new to the communications area and want a better understanding of the Communications Server component of z/OS? Have you heard of TCP/IP, SNA, VTAM, APPN, OSA, etc. but wondered what relationship these things have to Communications Server? If so, this presentation is for you!
An unusual number of recent news articles spotlighting SSL security flaws including HeartBleed, POODLE, and FREAK, has forced major security policy changes in communication software and compliance standards. In order to meet the future security challenges, and to continue providing business, this session will highlight how Rocket MV product family can help you to fortify your data communications, and meet compliance requirements of today and tomorrow.
The wolfSSL lightweight SSL/TLS library now includes TLS 1.3 support. This slide deck, from a seminar given in Tokyo, Japan, covers the differences in TLS 1.3 and what wolfSSL currently supports.
Secure enclaves are becoming a popular way to separate and protect sensitive code and data from other processes running on a system. A FIPS 140-2 validated cryptographic software module is currently required to run power-on self tests when loaded, but security of the module can be taken one step further by validating the module inside a secure enclave, such as Intel SGX.
wolfSSL has been working on FIPS 140-2 validating the wolfCrypt library running inside an Intel SGX enclave. This session will discuss the advantages, challenges, and process of FIPS 140-2 validating a cryptographic software module inside Intel SGX and how the same process could be applied to other secure enclave environments.
In this Pdf,you can know what is SSL Certificate?,How it wroks?,who need SSL Certificate? How you can secure your website in this internet world?
All these Question's solution in giving in this Pdf.
Developer's Guide to JavaScript and Web CryptographyKevin Hakanson
The increasing capabilities and performance of the web platform allow for more feature-rich user experiences. How can JavaScript based applications utilize information security and cryptography principles? This session will explore the current state of JavaScript and Web Cryptography. We will review some basic concepts and definitions, discuss the role of TLS/SSL, show some working examples that apply cryptography to real-world use cases and take a peek at the upcoming W3C WebCryptoAPI. Code samples will use CryptoJS in the browser and the Node.js Crypto module on the server. An extended example will secure the popular TodoMVC project using PBKDF2 for key generation, HMAC for data integrity and AES for encryption.
The tools at our disposal today for deploying HTTPS are tremendously powerful, and easy to use. Initiatives like Let's Encrypt offer certificates, and new security policies like HSTS and HPKP allow you to protect against extremely powerful attacks. HTTPS, Here and Now!
This was an invited talk at the ICT Security Happening, organized by the VDAB Competence Center in Leuven.
1086: The SSL Problem and How to Deploy SHA2 Certificates (with Mark Myers)Gabriella Davis
Two years ago enabling your site with SSL was a simple affair, buy a certificate or create your own, install it, then just remember to renew it every couple of years. Then, suddenly security holes are being found in SSL virtually every month , popular browsers stop connecting to your site to protect themselves, and you’re continually being told your users data is at risk. In this session we will discuss how it all went wrong and can go wrong again, then go through each step of requesting, generating and deploying a 4096 SHA-2 certificate to use in a keyfile by Domino, IBM Connections, IBM Sametime and other WebSphere products. If you work with these IBM products and need to secure them with confidence this session will show you how!
Cotopaxi - IoT testing toolkit (3rd release - Black Hat Europe 2019 Arsenal)Jakub Botwicz
Presentation about 3rd release of Cotopaxi toolkit from Black Hat Europe 2019 Arsenal session. Author: Jakub Botwicz
https://www.blackhat.com/eu-19/arsenal/schedule/index.html#cotopaxi-iot-protocols-security-testing-toolkit-18201
Comparative Analysis of Open-SSL Vulnerabilities & Heartbleed Exploit DetectionCSCJournals
Since its introduction in 1994 the Secure Socket Layer (SSL) protocol (later renamed to Transport Layer Security (TLS)) evolved to the de facto standard for securing the transport layer. SSL/TLS can be used for ensuring data confidentiality, integrity and authenticity during transport. A main feature of the protocol is its flexibility. Modes of operation and security aims can easily be configured through different cipher suites. During its evolutionary development process several flaws were found. However, the flexible architecture of SSL/TLS allowed efficient fixes in order to counter the issues. This paper presents an overview on theoretical and practical attacks of the last 20 years.
6. About wolfSSL
Founded: 2004
Locations: Bozeman, MT
Seattle, WA
Portland, OR
Our Focus: Open Source Embedded Security
(Apps, Devices, IoT, and Cloud)
Copyright 2015 wolfSSL Inc.6
Products: - wolfSSL
- wolfSSL FIPS
- wolfCrypt
- wolfSSH
- wolfSCEP
- wolfSSL Inspection
- yaSSL
7. One Billion Endpoints!
Copyright 2015 wolfSSL Inc.7
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
22. 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
Copyright 2015 wolfSSL Inc.22
1
2
3
4(A)
(B)
23. 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
Copyright 2015 wolfSSL Inc.23
1
2
3
4(A)
(B)
24. TLS - Sub Protocols
Record Protocol
● Layered protocol (Sending Side)
○ Fragments input data into blocks
○ (optionally) compresses data
○ Applies MAC
○ Encrypts
○ Transmits the result
Copyright 2015 wolfSSL Inc.24
1
2
3
4(A)
(B)
25. TLS - Sub Protocols
Record Protocol
● Layered protocol (Receiving Side)
○ Decrypts received data
○ Verifies data (using MAC)
○ Decompresses
○ Reassembles
○ Delivers result to higher level
Copyright 2015 wolfSSL Inc.25
1
2
3
4(A)
(B)
29. X.509 Certs and Keys
SSL / TLS
29 Copyright 2015 wolfSSL Inc.
30. 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
Copyright 2015 wolfSSL Inc.30
31. 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
Copyright 2015 wolfSSL Inc.31
32. 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)
Copyright 2015 wolfSSL Inc.32
-----BEGIN CERTIFICATE-----
…
…
-----END CERTIFICATE-----
33. 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”
Copyright 2015 wolfSSL Inc.33
35. SSL / TLS on Devices
Securing a simple HTTP client with TLS
35 Copyright 2015 wolfSSL Inc.
36. 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)
Copyright 2015 wolfSSL Inc.36
38. 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
○ ...
Copyright 2015 wolfSSL Inc.38
39. wolfSSL + FRDM-K64F
● wolfSSL is available for download from wolfssl.com:
● And also from GitHub:
Copyright 2015 wolfSSL Inc.39
40. wolfSSL + FRDM-K64F
● Or might already be in your IDE!
○ Keil MDK-ARM “Software Pack”
○ Microchip MPLAB Harmony
○ Freescale MQX-SSL
Copyright 2015 wolfSSL Inc.40
42. 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
Copyright 2015 wolfSSL Inc.42
43. wolfSSL + FRDM-K64F
● Drop wolfSSL into an Existing Project
Copyright 2015 wolfSSL Inc.43
47. 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
Copyright 2015 wolfSSL Inc.47
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)
48. 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
Copyright 2015 wolfSSL Inc.48
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");
49. wolfSSL + FRDM-K64F
● Write data using:
● And read data using:
Copyright 2015 wolfSSL Inc.49
wolfSSL_write(ssl, msg, msgSz);
wolfSSL_read(ssl, reply, sizeof(reply));
51. Peak RAM Usage
● RSA Cipher Suites
● ECC Cipher Suites
Copyright 2015 wolfSSL Inc.51
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
52. wolfSSL + FRDM-K64F
It’s as simple as that!
(try it yourself and see)
Copyright 2015 wolfSSL Inc.52
54. 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)
Copyright 2015 wolfSSL Inc.54
55. 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
Copyright 2015 wolfSSL Inc.55
reference 1
56. 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.
Copyright 2015 wolfSSL Inc.56
57. 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)
Copyright 2015 wolfSSL Inc.57
58. 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( x1, x5, x9,x13)
QUARTERROUND( x2, x6,x10,x14)
QUARTERROUND( x3, x7,x11,x15)
QUARTERROUND( x0, x5,x10,x15)
QUARTERROUND( x1, x6,x11,x12)
QUARTERROUND( x2, x7, x8,x13)
QUARTERROUND( x3, x4, x9,x14)
Copyright 2015 wolfSSL Inc.58
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
60. 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)
Copyright 2015 wolfSSL Inc.60
reference 2
62. 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
Copyright 2015 wolfSSL Inc.62
63. Curve25519
Used by
● Tor
● Google Chrome
● Apple iOS
● wolfSSL
Copyright 2015 wolfSSL Inc.63
reference 3
Generic Montgomery curve. Reference 5
68. Ed25519
Used by
● Tera Term
● GnuPG
● wolfSSL
Copyright 2015 wolfSSL Inc.68
reference 4 Generic Twisted Edwards Curve. Reference 6
69. 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
Copyright 2015 wolfSSL Inc.69
70. 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
Copyright 2015 wolfSSL Inc.70
76. 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
Copyright 2015 wolfSSL Inc.76
77. THANKS! QUESTIONS?
Copyright 2015 wolfSSL Inc.77
WOLFSSL
info@wolfssl.com
+1 (425) 245 - 8247
CHRIS CONLON
chris@wolfssl.com
JACOB BARTHELMEH
jacob@wolfssl.com
78. 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.
Copyright 2015 wolfSSL Inc.78
79. 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.
Copyright 2015 wolfSSL Inc.79