Engineering Spotlight: Todd Ouska, wolfSSL’s Chief Technology Officer, on TLS 1.3

October 12, 2018 by Chantelle Dubois

The importance of security in embedded systems is growing, making wolfSSL's Todd Ouska’s line of work a hot topic. AAC’s Chantelle Dubois had a chance to speak with him about his career and his thoughts on the embedded systems security domain.

As embedded systems become more common, so do security issues that require cryptographic countermeasures. AAC spoke with wolfSSL CTO Todd Ouska about the most recent update to cryptographic protocols, TLS 1.3, and what changes he's seen in the industry so far.

Protocols for cryptographic security are essential for consistent protection across embedded systems. SSL (secure sockets layer), one of the most widespread protocols so far, has largely been replaced with TLS (transport layer security), which was recently updated in August to TLS 1.3.

Todd Ouska has a unique perspective on TLS 1.3 and the cryptography libraries that help engineers develop secure projects. Ouska is the co-founder and Chief Technology Officer of wolfSSL, a company that focuses on open source embedded systems security solutions. While studying economics at Johns Hopkins University, Ouska worked with the university’s technical support and computer systems department and indulged in his tech hobby. 


Todd Ouska on stage at Ignite OSCON 2010. Image courtesy of wolfSSL.


It was kind of a hobby, but it’s what I got as a job out of school doing and just kind of kept going with it.

With an increasing awareness of the importance of security in embedded systems and the recent commercial release of TLS 1.3, Ouska’s line of work is becoming a hot topic. AAC’s Chantelle Dubois had a chance to speak with him about his career and his thoughts on the embedded systems security domain.

Chantelle Dubois (AAC): Tell us a bit about your background and the path that eventually lead you to co-founding wolfSSL.

Todd Ouska (TO): My career started in the database world. The second company I worked for, in the Seattle area, focused on embedded real-time systems. That’s how I met Larry [Stefonic], our co-founder, and Christin [Casperson, wolfSSL Sales & Marketing] worked there as well. I was onsite consulting, focusing on optimization, integration, and tuning of the database and embedded systems, and so worked on a few projects with Larry in that capacity.

A couple of years later, [when they began work on] mySQL, they needed a clean room implementation of TLS and he remembered the work I had done. [Larry contacted] me about it and that’s how it started. That was a one-off project; we didn’t see that as a company at the time. 

AAC: wolfSSL was founded in 2004 with a focus on open source, dual-licensed SSL solutions. What made this an important need to fill?

TO: The de facto standard for TLS—and the one that a lot of people are familiar with—is openSSL. Some of the negatives involved in SSL is that the IP isn’t super clear [especially] for bigger cooperations who want a clean, commercial license with clear ownership. So [we wrote] it ourselves, as clean room implementation, [while also focusing on] embedded performance and optimization.


CyaSSL is another wolfSSL embedded SSL library, shown here running on an STM32F2. Image used courtesy of wolfSSL.


We wanted to fill all these needs, not just the dual license. Open source made sense to us due to our background, especially with security products that are out in the wild where people can try it and conduct research with it. The open source component is a big part that helped us grow and receive recognition, and allow people to look at it and try it out. 

AAC: What do you think has changed in the security and embedded systems landscape since you first began working in this domain?

TO: I think several things; we’ve seen an increased awareness of security for new embedded projects [and the people building them are thinking more about it].

We’ve also seen a decreased ability for people to try and roll out their own protocol; [more] people are using industry standards like TLS that have been well vetted and have existed for a while.

[There has been an] increased threat in the landscape of embedded hardware, [such as] people hacking printers, phones, or routers. [This] has made people more aware that security is important and needs to be done right from the start. We’ve also seen an increase in hardware with crypto support such as hardware acceleration, secure elements, and being able to accelerate things like AES, having secure RSA, or ECC keys that can’t be tampered with. [There] is a big pretty increase in security that we’ve seen in that area.


The Sun Microsystem PCI-X Crypto Accelerator is an SSL accelerator card. Image courtesy of Retro-Computing Society of Rhode Island.

AAC: TLS 1.3 was recently published, which wolfSSL’s library supports. What goes into preparing for a protocol update such as TLS 1.3?

TO: There’s a couple of components to that. First, we need to make sure that we have an inner library that is well tested. TLS 1.3 was a major release, whereas TLS 1.0 to 1.1 and 1.1 to 1.2 were relatively minor in comparison—and, for those, it took a few weeks to roll it out and a few weeks to test, inter-op, and get it to our users.

But, TLS 1.3 has been a major change. We put close to a year probably into the implementation, the integration, the tuning, the inter-op, and so it’s been a pretty big effort. It’s also been complicated by [the fact that] they had 28 different drafts of the specification, and it was changing with each draft. So we’ve also had many different versions of TLS 1.3 in our library that we needed to test and make sure it works with other libraries at the same time. 

The second component is releasing it, making it available to our users, making sure it’s API compatible, works with other implementations, supports backwards compatibility with previous versions, and making it easier to document and use out of the box. We’ve spent a fair bit of time on that, so it’s not just getting the code right but making it easy to use for our users. 

AAC: What do you think is the biggest change in TLS 1.3 vs 1.2? You mention it’s a significant update.

TO: I like that they got rid of older and insecure algorithms. There’s a stronger focus on increased security, so you can’t accidentally get into a state where you are using a lower, weaker, and insecure algorithm. Everything is strong and secure out of the box.

They’ve also really focused on reducing latency and reducing roundtrips, meaning you will have way faster connection time which is really important in embedded systems where there could be latency in the network.

So, I think those are the two biggest changes: better security overall and better performance.

AAC: What sort of impact can we expect to see with TSL 1.3 on embedded systems security? 

TO: I think we’ll see a pretty quick large-scale adoption because of the better security, better performance, and lower latency. I think all those things are going to make it, hopefully, pretty ubiquitous in the next few months to a year. 

AAC: Why has wolfSSL made TLS 1.3 a priority?

TO: wolfSSL is the first to implement TLS 1.3 that is FIPS 140-2 compliant, and also the first to make TLS 1.3 commercially available. We’re excited about TLS 1.3 because we’re eager to see [enhanced] security. Products with good security out of the box are pretty great to see from our perspective. 

AAC: Thank you for your time, Todd!

  • P
    priyankp October 19, 2018

    I never had to deal with crypto in Microcontrollers but I am starting some projects with beefy STM32 Cortex M7 parts with Ethernet. ST provides a code generation tool that provides mbedTLS. Now mbed is an ARM product so I assume they have made a good use of crypto acceleration and other architecture features. I also assume that the code is thoroughly tested. So is it worth leaving all the convenience of a integrated code generation tool and integrate wolfSSL manually? What advantages does it provide over mbedTLS? Are they significant? This is not a rhetorical question.

    Like. Reply
  • N
    nkomomartin October 23, 2018

    Hello technicians,  sorry to distract you a little bit. I’m having a problem with equivalent Panasonic mosfets 2pq002.  I need help for their equivalent

    Like. Reply