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/32669 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 201415 / 199
2
3
10
11
12
13
14
17
18
19
23
24
25
27
29
45
46
47
48
49
50
51
52
55
56
57
58
65
67
68
70
72
74
75
76
77
78
79
81
82
84
86
87
89
90
93
94
100
101
102
103
104
106
107
109
110
111
112
113
114
115
119
122
123
124
126
127
128
129
137
139
141
143
145
147
150
154
155
158
161
163
164
165
166
168
171
174
175
176
179
182
183
185
188
190
191
192
194
195
196
00:00
Source code
01:48
Computer animation
04:39
Product (business)Arithmetic progressionSoftware developerCryptographyBitGoodness of fit
06:34
Information securityWeb 2.0Open sourcePublic-key cryptographyNumberProduct (business)Source codeProxy server1 (number)Server (computing)Library (computing)Electronic mailing listCryptographyPlastikkartePower (physics)Wrapper (data mining)Semiconductor memoryConnected spaceStreaming mediaEnterprise architectureSign (mathematics)Food energyEstimatorOperating systemTelecommunicationFiber bundleEncryptionVector potentialTransport Layer SecurityCloud computingCASE <Informatik>Total S.A.Standard deviationProjective planeBitMultiplication signSingle sign-onComputer configurationInternetworkingImplementationComputer fileComputer-generated imageryLevel (video gaming)EmailDifferent (Kate Ryan album)Physical lawQuicksortLine (geometry)Address spaceSingle-precision floating-point formatPlanningEscape characterSystem callGroup actionInsertion lossQuantumCompilerMultitier architectureLikelihood-ratio testCellular automatonSubsetEndliche ModelltheoriePoint (geometry)Suite (music)ScreensaverOpen setProcess (computing)Range (statistics)Modul <Datentyp>XMLUML
12:20
Server (computing)Multiplication signClient (computing)BitHash functionCommunications protocolRow (database)Open sourceInformation securityEndliche ModelltheorieVulnerability (computing)Default (computer science)Public key certificateTransport Layer SecurityMaxima and minimaImplementationPatch (Unix)Band matrixJava appletDifferent (Kate Ryan album)Ocean currentProduct (business)MereologyExtension (kinesiology)EncryptionWrapper (data mining)Computing platformLevel (video gaming)Software developerLibrary (computing)Computer configurationWebsiteRevision controlSoftwareBuffer solutionPhysical systemPrice indexMessage passingProcedural programmingCellular automatonCycle (graph theory)Exception handlingInclined planeRight angleSemiconductor memoryPoint (geometry)LengthOracleArithmetic meanFrame problemService (economics)Inverse elementXMLComputer animation
18:06
Computer hardwareComputing platformComputer fileAsynchronous Transfer ModeSuite (music)Message passingCache (computing)Library (computing)AdditionFunctional (mathematics)Buffer solutionModule (mathematics)Sign (mathematics)Client (computing)Public key certificateEncryptionProduct (business)Operating systemSemiconductor memoryCompilerContext awarenessMathematicsImplementationStandard deviationFormal verificationMemory managementBlock (periodic table)Operator (mathematics)Stack (abstract data type)Public-key cryptographyType theoryLatent heatBenchmarkTrailMathematical optimizationProjective planeKey (cryptography)CryptographyRow (database)BitComputer configurationCombinational logicMultiplication signAnalytic continuationAtomic numberRadiusScripting languageService (economics)Group actionStaff (military)Social classPercolation theorySet (mathematics)CASE <Informatik>Computing platformFiber bundleLine (geometry)Arithmetic progressionExecution unitInclusion mapInternet service providerEndliche ModelltheorieRule of inferencePressureAreaMappingLink (knot theory)InformationDeciphermentSpacetimeLevel (video gaming)Cellular automatonOverlay-NetzOpen sourceXML
24:00
Integrated development environmentAngleInformation technology consultingElement (mathematics)Matching (graph theory)Water vaporStack (abstract data type)Service (economics)Computing platformLibrary (computing)Group actionDirection (geometry)Software developerEmailOpen sourceStandard deviationBitSource codeMultiplication signCryptographyProcess (computing)Random number generationMathematical analysisOperating systemSoftwareFeedbackCodeCellular automatonEnterprise architectureLattice (order)Endliche ModelltheorieWebsiteComputer clusterValidity (statistics)Computer hardwarePairwise comparisonScripting languageComputer programmingDefault (computer science)Thread (computing)NumberSlide ruleArmMereologyOperator (mathematics)Office suiteCuboidParticle systemModule (mathematics)Programmer (hardware)Revision controlSoftware testingRoundingGraph (mathematics)XMLProgram flowchart
29:55
outputOpen sourceMultiplication signSoftware developerCASE <Informatik>Public key certificateFunction (mathematics)Turing testMessage passingDifferent (Kate Ryan album)Canadian Mathematical SocietyXMLLecture/Conference
Transcript: English(auto-generated)
05:36
We're going to finish with our last talk. Chris is going to talk about crypto and SSL on Embedded, and WolfSSL
05:45
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? Good? Cool.
06:02
Alright, well, yeah, thanks guys for attending our session. I know it's the last one in the dead room of today. Hopefully we'll just today give you an update of what we've done progress-wise in the last year, 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.
06:24
My name is Chris Conlon. I'm a software developer with WolfSSL, 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, so we have pretty good excuses to take a day or two off work every once in a while.
06:43
We're a growing company. I guess our map is a little bit faded there, but we're a total of ten people, five full-time and five part-time, based in three countries and six different cities. So I'm in Bozeman, Montana. We have people in Seattle, Washington, Portland, Oregon, Hapa
07:02
Soa, 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, SeaAzle, secures over 500 million endpoints on the Internet.
07:23
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.
07:47
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.
08:00
This is our product lineup at WolfSSL. Our main product is called SeaAzle. 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.
08:20
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 SeaAzle. 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.
08:46
So we have an SSL proxy built on top of Squid, we have a secure memcache implementation, and we also have a Skep implementation.
09:01
So looking at our main product, SeaAzle, 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, using a pre-shared keys, Cypher Suite, and TLS 1.2 only.
09:24
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. And so this is not only important so the embedded world cares about memory usage, but so does the enterprise and cloud services.
09:43
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. And oftentimes it's quite a burden to take that whole package and port it over to your embedded operating system or device.
10:05
Oftentimes companies just will devote a single engineer just to working with OpenSSL. Whereas SeaAzle, we pretty much have ported to everything we've encountered so far. You can see here's a number of the operating systems we support, and are always working on porting over to new ones every day.
10:28
WolfCrypt is our cryptography library. It previously was called SeaTauCrypt, and was bundled in together with SeaAzle. So they were one and the same. This year we've been working on separating them out into two separate products.
10:42
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 in your project, 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.
11:03
And it pretty much supports all of your standard cipher suites, as well as some progressive ones. We added the HD128 and Rabbit stream ciphers a while ago. We support the NTRU public key algorithm, which is the quantum-resistant public key from Security Innovation.
11:21
And then we've added the Blake-2 SHA-3 finalists. So we try to stay up to date on that. Since this is what we do every day, all day, as a job, we like to give our users the most cutting-edge technology when possible.
11:41
The Azle Embedded Web Server is built on top of Mongoose, which is also an open-source web server. So we took Mongoose and put SeaAzle into it, and now you can get the whole entire bundle in the Azle Embedded Web Server. Again, very small, so 100 kilobytes with SSL support, 20 kilobytes without if you just wanted the plain HTTP connection.
12:04
It's got a pretty good list of features as well for being an embedded web server. So you've got CGI and SSI and IP restrictions, etc. And also very portable.
12:20
Here's one of the two new products we've introduced this year. WolfSSLJNI is simply a JNI wrapper around SeaAzle. SeaAzle 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. Up until this point, people would have to take an SSL library like OpenSSL or SeaAzle and write their own wrapper around it.
12:46
So hopefully this will just provide people an off-the-shelf solution. I guess I should mention our licensing model a little bit about our company. We're dual-licensed under the GPL and commercial license.
13:01
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. So we wrote actually a C++ SSL library called Yazzle. And then eventually wrote SeaAzle because the embedded market really wanted a C library.
13:24
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. It's a 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.
13:51
We've stuck with our same principles that we've learned through all of our work with SeaAzle being portable. 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.
14:05
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. So it should make it onto our website probably in the next couple of weeks.
14:26
Okay, 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. So we fixed the Lucky 13 attack.
14:43
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 SeaAzle codebase. And so Lucky 13 was a timing attack, so you can monitor how much time it takes you to get SSL records back.
15:01
And using that eventually decrypts 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. We've had DTLS support for a couple of years now.
15:21
So DTLS is Datagram TLS. So 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. And so we introduced a couple of reliability enhancements since now we have a couple more users using it.
15:45
It's really popular with streaming media, VoIP, etc. And we have added support for DTLS 1.2. So the two versions of DTLS are 1.0 and 1.2.
16:01
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.
16:21
We've added some support for some new TLS extensions. And so the server name indication, or SNI, lets a client specify which server it's connecting to. This can be useful when you have multiple servers hosted on the same location, if they're virtual for example.
16:40
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. And so on an embedded client you have to reserve 16 kilobytes for that buffer. And so a lot of times if you don't have that much memory, which we encounter people every day who...
17:06
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. And then the third one we introduced was truncated HMAC.
17:22
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. 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.
17:49
And when you're configuring C-ASL, we use the AutoComp system by default on Linux. So you can just add the enable TLX option.
18:02
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. 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.
18:24
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. We added a mode to AES CCM, so counter with CBC MAC.
18:45
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-ASL and SSL, you gain eight more cipher suites, options between RSA suites, ECC suites, and pre-shared keys.
19:08
We had some discussions with NTT who developed Camelia and worked with them to add Camelia to our C-ASL library and WOLF script. Camelia is a block cipher, like AES, so again it's exposed through .c and .h files.
19:24
We give users some new functions to work with. And again you have eight new cipher suites. We added SHA-384 cipher suites. Our HMAC now supports SHA-512. And we enhanced our AES-NI support up to optimizing for AES-CCM and GCM.
19:47
So AES-NI is an Intel hardware accelerated crypto that I think they say five to ten times speed improvement over standard AES. And so they have one instruction that's specific for these AEAD ciphers,
20:02
and we added support for that. Kind of a byproduct of our WOLFSKET project was the addition of some of these PKCS standards. PKCS-7, which is crypto-affric message syntax, is used to sign and encrypt messages.
20:22
It uses an ASN-1 bundle, and it wraps it up kind of like an onion. And it uses a lot in SCEP. And we've also had quite a few requests in the last couple of years for both of these. The second one is PKCS-10, or certificate signing request. This lets a client make a CSR to send to a CA,
20:43
which then turns that into, they sign the public key contained in that and send you back an actual SSL certificate. A couple of things, portability-wise, we added support for persistent session cache.
21:02
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. And along the same lines, we added the ability to persist the CA certificate cache,
21:22
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. So if you have a hardware module or HSM that can do these in one step,
21:43
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. And then along the same lines, we added some public key callbacks for RSA,
22:03
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. 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.
22:28
Let's see, that kind of wraps up our crypto additions. Moving on to examples and documentation. We've made our examples a little bit easier for users to give them a little bit more information. One of the main questions we get is about resource usage,
22:42
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 or using that in production.
23:03
We did another pass through our API documentation, which is a pretty good improvement over what we had before. We actually have API docs for most of our functions now. But like always, documentation is continuous work in progress, and so it will continuously improve.
23:24
And 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, so we've created and released a porting guide, which covers everything from ndns to types to assembly optimizations to library settings,
23:45
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, logging callbacks, memory handling callbacks, etc. It should all be mentioned in here now. One go-to resource.
24:07
We're always porting to new chips, too, so we added support for microchips, so we've got fix32, mx, and mz, also ported to version 6 of their TCP IP stack, and now we work with Microchip Harmony,
24:22
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 and it should work seamlessly, and it may be in there in the future.
24:45
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 SimpleDefine, and we just added support for the MMC-IU,
25:00
which is their hardware-optimized crypto operations. And I think the next slide will... So here's a comparison between our software, our C-TAO-Crypt implementation, and the Freescale Kinetas MMC-IU. You can see that you see anywhere from a 20% to a 1,300% increase in speed.
25:24
Here's the same thing on a graph. So on embedded chips like the Kinetas, this is awesome for users. We added support for Cavium Nitrox, which is more of an enterprise hardware-optimized crypto solution.
25:44
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 the performance numbers of our Cavium Nitrox support. We added support for HPUX operating system,
26:03
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. We ported to the STM32 chips, as well as integrated into their hardware crypto and random number generator.
26:25
Here you see our speed performance comparison again. Between orange is our software implementation and green is the STM32 crypto. So again this is a substantial improvement for users.
26:44
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. So if you go to Kyle's website, you can download WolfSSL and pull it right in through the Kyle tools.
27:04
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. So that's kind of all the technical news, or the highlights at least. A couple of items of business news.
27:23
You may remember us as Iazzle, which we were last year, 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. Wolves, they communicate effectively, they work well in groups,
27:43
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, and we launched what we call our Kickstart Consulting Program.
28:02
So somebody can send us their entire platform, we'll put our software over to it and send it back to them. At least in the United States, a big item of news is FIPS 140-2 validation for WolfCrypt. So this is a crypto module validation that a lot of government
28:25
and some businesses look for in crypto modules that they pull into their code. And so it's a pretty long process to go through. It's anywhere from six to twelve months, and plus waiting on time for a lab to verify things. And so hopefully we'll get this wrapped up in the next half, well, probably the next quarter if we're lucky.
28:45
With that, it'll bring a whole bunch of new documentation to see as on WolfCrypt. It'll bring a whole bunch of new tests and some other things. We've tried to streamline our support process a little bit better with our growth,
29:00
using just direct email. It got a little overwhelming. So we switched over to Zendesk and 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, customers and users.
29:21
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 U.S. mostly and being open source, can we then actually confidently say you don't have NSA programmers putting back doors?
29:45
That's a legitimate question, and we can probably say we are not compromised by the NSA. We actually keep an eye on contributions very closely into our codebase. So I think OpenSSL had some questionable things that were slipped in,
30:04
but we definitely have four developers that we know what they're doing all the time. We can confidently tell you that we haven't been compromised.
30:32
You should be able to do anything regarding using OpenSSL or C-ASL. They should be pretty much sloppable, SSL-wise.
30:41
I guess I'm not sure what you mean. Do you have an example of ASN1? In this case, a few years ago you couldn't do it with C-ASL. I could do it with OpenSSL, so I went with OpenSSL,
31:01
and that was the reason why I went with OpenSSL. Otherwise, C-ASL looked better for everything else. So they do a little bit different. They have a BIO method of input-output. For certificate management, we offer users the ability to create certificates.
31:22
Both self-signed and now with our CSI or CA signed. What I wanted to do is basically create broken CMS messages. 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. It could be. Now that we have PKCS7 so far, there's a chance that it might...
31:44
Yeah, look at it and send us a question. Sure. We'll get back to you. I've got a bunch of OpenSSL stickers here, if anybody wants a sticker. Otherwise, thanks for attending.
Recommendations
Series of 26 media