wolfSSL 2013 Technical and Community Update
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 199 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32668 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Cellular automatonProduct (business)BitArithmetic progressionGoodness of fitCryptographySoftware developerLecture/Conference
00:59
Library (computing)Proxy serverInternetworkingOpen sourceSemiconductor memoryServer (computing)Connected spaceCellular automatonMultiplication signWeb 2.0NumberCryptographyWrapper (data mining)Operator (mathematics)Enterprise architectureGroup actionPoint (geometry)ScreensaverSinc functionProcess (computing)SubsetProduct (business)Compiler1 (number)QuantumAlgorithmInformation securityTotal S.A.Different (Kate Ryan album)Sign (mathematics)Projective planeFood energyComputer-generated imageryMathematical analysisCloud computingCASE <Informatik>TelecommunicationElectronic mailing listEscape characterImplementationComputer configurationModul <Datentyp>Vector potentialPlanningComputer fileStandard deviationEncryptionPower (physics)PlastikkarteEmailLine (geometry)Single sign-onOperating systemPublic-key cryptographyTransport Layer SecurityLevel (video gaming)BitFiber bundleSource codeSuite (music)Streaming mediaXMLUML
06:45
Product (business)Physical systemImplementationComputer configurationRow (database)Wrapper (data mining)Communications protocolInformation securityDefault (computer science)Level (video gaming)Vulnerability (computing)Java appletRevision controlBitHash functionEndliche ModelltheorieComputing platformLibrary (computing)Client (computing)Software developerBand matrixTransport Layer SecurityOcean currentMultiplication signPatch (Unix)Maxima and minimaMereologyBuffer solutionServer (computing)SoftwareWebsitePublic key certificateDifferent (Kate Ryan album)Extension (kinesiology)AuthenticationCellular automatonFlagSemiconductor memoryRule of inferenceService (economics)Price indexLengthFrame problemPoint (geometry)Water vaporInverse elementEncryptionMessage passingCycle (graph theory)Open sourceCryptographyProcedural programmingXMLComputer animation
12:31
Computer fileScripting languageService (economics)Functional (mathematics)Line (geometry)Physical lawPublic key certificateAsynchronous Transfer ModeInclusion mapSpacetimeContext awarenessCellular automatonKey (cryptography)BitPressureAdditionInternet service providerEndliche ModelltheorieImplementationGroup actionBenchmarkMathematical optimizationBuffer solutionLink (knot theory)Operator (mathematics)AxiomProcess (computing)Social classLibrary (computing)Standard deviationProjective planeSign (mathematics)CryptographyFiber bundleMessage passingCycle (graph theory)MathematicsProduct (business)DeciphermentRule of inferenceMemory managementArithmetic progressionComputing platformCybersexAnalytic continuationStack (abstract data type)RadiusCombinational logicMultiplication signDisk read-and-write headLatent heatAreaSet (mathematics)InformationTrailFormal verificationEncryptionModule (mathematics)Semiconductor memoryComputing platformComputer hardwareType theoryAtomic numberRow (database)Operating systemSuite (music)Electronic program guideBlock (periodic table)Cache (computing)Public-key cryptographyComputer configurationCompilerClient (computing)XML
18:25
NumberProcess (computing)Pairwise comparisonLibrary (computing)Information technology consultingSoftware testingSoftwareBitCryptographyProgrammer (hardware)EmailComputer hardwareValidity (statistics)WebsiteFeedbackRevision controlGraph (mathematics)Random number generationOpen sourceOperator (mathematics)Enterprise architectureMultiplication signSoftware developerImplementationModule (mathematics)CodeIntegrated development environmentRoundingDefault (computer science)Source codeComputer programmingLength of stayService (economics)Server (computing)Cellular automatonOffice suiteMereologyComputer clusterPopulation densityStandard deviationDirection (geometry)Thread (computing)CuboidSimilarity (geometry)ArmMathematical analysisLattice (order)Point (geometry)Scripting languageElement (mathematics)Endliche ModelltheorieWater vaporStack (abstract data type)AngleComputing platformOperating systemGroup action
24:20
Turing testMultiplication signSoftware developerFunction (mathematics)Open sourceoutputPublic key certificateCASE <Informatik>SummierbarkeitData managementDifferent (Kate Ryan album)Message passingCommunications protocolBitXMLLecture/Conference
Transcript: English(auto-generated)
00:01
We're going to finish with our last talk. Chris is going to talk about crypto and SSL on embedded and Wolf SSL apparently has also done a lot of progress in the last year and he's going to tell us about what has happened. Go ahead Chris. Thanks Philip. Can everybody hear me okay with this microphone?
00:24
Good? Cool. All right, well yeah, thanks guys for attending our session. I know it's the last one in the embedded dev room of today. Hopefully we'll just today give you an update of what we've done progress-wise in the last year.
00:40
Go over a little bit of an overview of our products for those who aren't familiar with our company or the products we offer. My name is Chris Conlon. I'm a software developer with Wolf SSL and I live in Bozeman, Montana and so there's a picture of the valley that Bozeman is in and we have lots of good skiing nearby.
01:01
So we have pretty good excuses to take a day or two off work every once in a while. We're a growing company. I guess our map is a little bit faded there, but we're a total of 10 people, five full-time and five part-time. Based in three countries and six different cities. So I'm in Bozeman, Montana.
01:23
We have people in Seattle, Washington, Portland, Oregon, Hapasoa, Brazil, back up to San Jose, California, and then a guy over in Tokyo. So that's a couple more than we had last year, so it's a good sign. And we estimate that our main product, Seattle, secures over 500 million endpoints on the internet.
01:48
Those endpoints are really diverse. SSL is a very horizontal technology, so anything connecting to the internet could be a potential use case for an SSL or crypto library. So anything ranging from machine-to-machine communication to home energy to smart power meters, etc.
02:12
So like I mentioned, we'll just go over a brief overview of our products that we offer, talk about what's new, and then hopefully we'll have some time for you guys to ask any questions you may have.
02:25
This is our product lineup at WolfSSL. Our main product is called Seattle. It's a lightweight embeddable SSL and TLS library. It is backed by our WolfCrypt crypto engine, which ships with it, and then it also includes a passive SSL inspection feature as well.
02:46
WolfCrypt is our cryptography library slash engine. We have an embeddable web server called Yazzle EWS. We came out with a new product this year called WolfSSL JNI, which is simply a JNI wrapper around C-Yazzle.
03:03
And then we have a couple products, which we don't currently have on our website yet, but we have them in the labs, and available to those interested. So we have an SSL proxy built on top of Squid. We have a secure memcache implementation, and we also have a SCEP implementation.
03:26
So looking at our main product, C-Yazzle, like I mentioned, it's a lightweight embeddable SSL library. The whole library footprint ranges from 20 to 100 kilobytes, depending on how you build it. The 20 kilobyte option is a lean PSK, so that's a subset,
03:42
using a pre-shared keys, Cypher Suite, and TLS 1.2 only. 100 kilobytes will give you pretty much a full SSL stack using an embedded optimized compiler. RAM usage is low as well, 1 to 36 kilobytes per session.
04:01
And so this is not only important, so the embedded world cares about memory usage, but so does the enterprise and cloud services. Because when you have millions of connections coming in, you're limited by your RAM memory. And then it's also very portable. So one of our main open source competitors is OpenSSL.
04:22
And oftentimes it's quite a burden to take that whole package and port it over to your embedded operating system or device. Oftentimes companies just will devote a single engineer just to working with OpenSSL. Whereas C-Azle, we pretty much have ported to everything we've encountered so far.
04:40
You can see here's a number of the operating systems we support. And they're always working on porting over to new ones every day. WolfCrypt is our cryptography library. It previously was called C-TauCrypt and was bundled in together with C-Azle.
05:01
So they were one and the same. This year we've been working on separating them out into two separate products. And so there's a lot of people who only want crypto and not necessarily SSL. So very soon you'll just be able to download a straight crypto library, if that's your desire. It's very modular, so if you only want to use AES, say, in your project,
05:21
you can just pull out the source file and the header file and stick them right into your project without having to pull in everything else. And it pretty much supports all of your standard cipher suites as well as some progressive ones. We added the HC128 and Rabbit stream ciphers a while ago. We support the NTRU public key algorithm,
05:41
which is the quantum-resistant public key from Security Innovation. And then we've added the BLAKE2 SHA-3 finalists. So we try to stay up to date on that. Since this is what we do every day, all day, has a job, we like to give our users the most cutting-edge technology when possible.
06:06
The ASL Embedded Web Server is built on top of Mongoose, which is also an open-source web server. So we took Mongoose and put C-ASL into it, and now you can get the whole entire bundle in the ASL Embedded Web Server. Again, very small, so 100 kilobytes with SSL support,
06:24
20 kilobytes without if you just wanted the plain HTTP connection. And it's got, surely, a pretty good list of features as well for being an embedded web server. So you've got CGI and SSI and IP restrictions, et cetera. And also very portable.
06:45
Here's one of the two new products we've introduced this year. So WolfSSL JNI is simply a JNI wrapper around C-ASL. C-ASL is written in C. We had a customer who really actually wanted to use DTLS 1.2, which the Java implementation currently doesn't have DTLS support.
07:03
And so up until this point, people would have to take an SSL library, like OpenSSL or C-ASL, and write their own wrapper around it. So hopefully this will just provide people an off-the-shelf solution. And then I guess I should mention our licensing model a little bit about our company.
07:21
I have here that we're dual-licensed under the GPL and the commercial license. So all of our products are open-source. We originally were born out of MySQL. They wanted a clean-room SSL implementation that they knew the license to and they could safely ship with their commercial licenses. And so we wrote, actually, a C++ SSL library called Yazel,
07:44
and then eventually wrote C-ASL because the embedded market really wanted a C library. And so we follow that licensing model now with most of our subsequent products. The second new product we've introduced this year is our SCEP client,
08:02
so Simple Certificate Enrollment Protocol. And so this lets a client go out and enroll with a SCEP server and retrieve back a certificate, which they can then use to authenticate to a network. We've stuck with our same principles that we've learned through all of our work with C-ASL being portable.
08:21
And so we've abstracted out most of the layers that you would encounter as problems when you're moving over to a new platform. And it, again, uses WolfCrypt underneath as the crypto library. It's currently under development. We're actually just wrapping it up, probably this week.
08:41
So it should make it onto our website probably in the next couple of weeks. OK, let's talk a little bit now about what's new, what we've done in the last year, probably the more interesting part for people who have already heard our spiel about what we do.
09:04
So we fixed the Lucky 13 attack. Nadem and Kenny came to us beforehand and told us about that, and they were very helpful in helping us along, pushing the patch into our C-ASL codebase. And so Lucky 13 was a timing attack,
09:22
so you can monitor how much time it takes you to get SSL records back, and using that, eventually decrypt the plaintext, which is pretty amazing, actually. And, yeah, you've got to give props to those guys for figuring that out. So we should be protected against that.
09:43
We've had DTLS support for a couple of years now. So DTLS is Datagram TLS. It's meant to be used over unreliable protocols such as UDP. And because it can't use the reliability in out-of-order packets, stuff that TCP has, it's a lot more complex.
10:03
And so we introduced a couple reliability enhancements since now we have a couple more users using it. It's really popular with streaming media, VoIP, etc. And we have added support for DTLS 1.2.
10:20
So the two versions of DTLS are 1.0 and 1.2. 1.2, just pretty much updating it to the level of TLS 1.2, and adding the AEAD, so authenticated encryption, with associated data. And so it not only encrypts, but it also authenticates messages.
10:42
We've added some support for some new TLS extensions. And so the server name indication, or SNI, lets the client specify which server it's connecting to. This can be useful when you have multiple servers hosted
11:01
on the same location, if they're virtual, for example. We introduced max fragment length, which allows the client to negotiate a different maximum SSL record size. So by default SSL uses a 16 kilobyte record, and so they're not all that big, but they can grow up to that big. So on an embedded client you have to reserve 16 kilobytes for that buffer.
11:25
A lot of times if you don't have that much memory, which we encounter people every day, it's a struggle for them to fit an extra 16 kilobytes into their SSL allotment. The client can use this and negotiate down a smaller maximum fragment size.
11:43
And then the third one we introduced was truncated HMAC. And so traditionally a hash algorithm like SHA-1 is used to form the MAC tag, which is usually 160 bits. And so with this the client can, again, reserve bandwidth and shrink that down to 80 bits.
12:04
Currently there's not any security weaknesses known by using an 80-bit MAC instead of the full hash implementation for MD5 and SHA-1. And when you're configuring C-EASL we use the AutoComp system by default on Linux, so you can just add the enable TLSX option.
12:27
We added, as I mentioned, the SHA-3 finalist, BLAKE-2. So it ranges from 256 to 512-bit digest lengths. It's actually pretty speedy, and it matches our company philosophy pretty well.
12:41
So not only is it lightweight, but it's also fast. So you can see here, this is our CTOW script, or WOLF script, implementation benchmark. It's faster than our SHA implementations. And actually on some embedded platforms it will be faster than MD5 if the compiler optimizes it correctly.
13:04
We added a mode to AES-CCM, so counter with CBC-MAC. And it's enabled using enable AES-CCM now, available to users through AES.c and .h, using those functions. And when used with C-EASL and SSL, you gain eight more cipher suites,
13:24
options between RSA suites, ECC suites, and pre-shared keys. We had some discussions with NTT, who developed Camelia, and worked with them to add Camelia to our C-EASL library and WOLF script.
13:43
Camelia is a block cipher, like AES, so again it's exposed through .c and .h files. We give users some new functions to work with, and again you have eight new cipher suites. We added SHA-384 cipher suites.
14:01
Our HMAC now supports SHA-512. And we enhanced our AES-NI support up to optimizing for AES-CCM and GCM. So AES-NI is an Intel hardware accelerated crypto that I think they say five to ten times speed improvement over standard AES.
14:23
And so they have one instruction that's specific for these AEAD ciphers, and we added support for that. Kind of a byproduct of our WOLFSKET project was the addition of some of these PKCS standards.
14:42
PKCS-7, which is crypto-affric message syntax, is used to sign and encrypt messages. It uses an ASN-1 bundle, and it wraps it up kind of like an onion. It's used a lot in SCEP, and we've also had quite a few requests in the last couple of years for both of these.
15:00
The second one is PKCS-10, or certificate signing request. This lets a client make a CSR to send to a CA, which then turns out into... They sign the public key contained in that and send you back an actual SSL certificate.
15:20
A couple of things, portability-wise. We added support for persistent session cache. So you can now persist the session cache to either a file or a buffer. So here you can see relevant functions for files and buffers, and you enable it with save session.
15:42
And along the same lines, we added the ability to persist the CA certificate cache, either to, again, files or buffers. We added a couple of callbacks. We added an atomic record callback for MAC and encrypt operations and decrypt verify.
16:03
So if you have a hardware module or HSM that can do these in one step, you can actually write a callback, and it will just call your HSM or hardware module directly, which some users really want and sometimes can provide a performance increase as well.
16:21
And then along the same lines, we added some public key callbacks for RSA, sign and verify, encrypt, decrypt, and ECC, sign and verify. You can now unload your keys and certificates once you've loaded them into an SSL context.
16:41
So if you need to refresh that cache for some reason and you want to dump the existing one without destroying the whole entire context. Let's see, that kind of wraps up our crypto editions. Moving on to examples and documentation. We've made our examples a little bit easier for users
17:01
to give them a little bit more information. One of the main questions we get is about resource usage, and so we've added the ability to track stack usage and memory allocation to our examples, and then also increased the IPv6 support since a lot more people seem to be either experimenting with
17:22
or using that in production. We did another pass through our API documentation, which is a pretty good improvement over what we had before. We have API docs for most of our functions now. But like all of this, documentation is a continuous work in progress,
17:42
and so it will continuously improve. Probably 80% of our customers are porting to their operating system or platform, a combination of TCP IP stack, etc. And so we get a ton of questions about porting,
18:01
so we've created and released a porting guide which covers everything from ndns to types to assembly optimizations to library settings, math libraries, that is, all the way down to all of our callbacks. So we have callbacks for swapping out IO if you want to run SSL over something besides TCP IP,
18:21
logging callbacks, memory handling callbacks, etc. It should all be mentioned in here now. One go-to resource. We're always porting to new chips, too, so we added support for microchips, Fix32, MX, and MZ. We also ported to version 6 of their TCP IP stack,
18:44
and now we work with Microchip Harmony, which is their development environment that just was released this year. WolfCrypt will actually ship with Harmony by default, so as soon as you download Harmony, WolfCrypt will be in there. If you want C-Azle, you can download it
19:02
and it should work seamlessly, and it may be in there in the future. We've added support for some Freescale stuff, so some of their hardware-based round number generators, RNG-A and RNG-B, are now easily enabled by a simple define,
19:22
and we just added support for the MMC-IU, which is their hardware-optimized crypto operations. I think the next slide will... So here's a comparison between our software CTAU-Crypt implementation and the Freescale Kinetas MMC-IU.
19:42
You can see that you see anywhere from a 20% to a 1300% increase in speed. Here's the same thing on a graph. So on embedded chips like the Kinetas, this is awesome for users.
20:01
We added support for Cavium Nitrox, which is more of an enterprise hardware-optimized crypto solution. Right now we do blocking crypto, which most all crypto libraries do. Hopefully sometime in the next year or so we'll be able to add non-blocking crypto, which will really, really increase
20:21
the performance numbers of our Cavium Nitrox port. We added support for HPUX operating system, better ThreadX support, as well as default IO callbacks for NetX. So out of the box, if you're using either ThreadX or NetX, we should work.
20:42
We ported to the STM32 chips, as well as integrated into their hardware crypto and random number generator. Here you see our speed performance comparison again, between orange is our software implementation and green is the STM32 crypto.
21:02
So again, this is a substantial improvement for users. We've been working pretty closely with Kyle this last year. We ported to their MDK arm, as well as integrated into the MDK5, development environment, and we're actually a software pack now.
21:21
So if you go to Kyle's website, you can download WolfSSL, and pull it right in through the Kyle tools. So you don't even have to come to our website and download it anymore, which we think is pretty cool, and users are enjoying it so far, and we've gotten some good feedback.
21:42
So that's kind of all the technical news, or the highlights at least. A couple items of business news. You may remember us as the Yazzle, and last time you saw us, probably. We've changed our name to WolfSSL. We just think it better aligns with our company values and culture.
22:02
Wolves, they communicate effectively, they work well in groups, and they share among the group, kind of like open source developers. We added a couple more developers to the team so we can get things done a little bit faster. We increased our on-site consulting activity,
22:22
and we launched what we call our Kickstart consulting program. Somebody can send us their entire platform. We'll put our software over to it and send it back to them. Well, at least in the United States, a big item of news is FIPS 140-2 validation for WolfCrypt.
22:45
This is a crypto module validation that a lot of government and some businesses look for in crypto modules that they pull into their code. So it's a pretty long process to go through. It's anywhere from 6 to 12 months, plus waiting on time for a lab to verify things.
23:03
Hopefully we'll get this wrapped up in the next quarter, if we're lucky. With that, it'll bring a whole bunch of new documentation to see Yazzle and WolfCrypt. It'll bring a whole bunch of new tests and some other things.
23:21
We've tried to streamline our support process a little bit better with our growth using just direct email. It got a little overwhelming. So we've switched over to Zendesk. We're giving that a try. So now you'll be issued a support ticket when you email us, and hopefully it'll work a little bit better. We try to keep customers highest priority,
23:41
customers and users. So I think that's pretty much my update of what we've done this year. But I'd love to answer any questions you guys have about WolfSSL or related technologies. Being apparently based in the US, mostly,
24:03
and being open source, can we then actually confidently say you don't have NSA programmers putting back your words? That's a legitimate question. We can probably say we are not compromised by the NSA. We actually keep an eye on contributions very closely
24:22
into our code base. I think OpenSSL had some questionable things that were slipped in. But we definitely have four developers, and we know what they're doing all the time. We can confidently tell you that we haven't been compromised.
24:46
Why don't you take ASM.1 protocols? Can I write my own protocol using your library, like I can with OpenSSL? Yeah, you should be able to do anything regarding using OpenSSL or CSL.
25:01
They should be pretty much swappable. Well, SSL-wise. I'm not sure what you mean. Do you have an example of ASM.1?
25:29
They do a little bit different. They have a BIO method of input-output.
25:42
For certificate management we offer users the ability to create certificates, both self-signed and now with our CSR or CA signed. Well, what I wanted to do is basically create broken CMS messages. It was the opposite. I didn't want to make something that was working. I wanted something that was broken. I wanted to break it in a specific way.
26:02
It could be. Now that we have PKCS7 so far, there's a chance that it might look at it and send us a question. Well guys, I've got a bunch of WolfSSL stickers here
26:20
if anybody wants a sticker. Otherwise, thanks for attending.