Seeking commentary on demo using TLS 1.3

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
KaHi_2151451
Level 2
Level 2
5 likes given First like received First like given

Greetings again Cypress/WICED community!

wolfSSL has received a request to do a demo using TLS v1.3 on a WICED device.

We are looking for input on which device the community would find most useful in addition to features that may be more preferred over others!

Demo Features we'd like commentary on:

- TLS 1.3 on an embedded device with which one:

   - Wifi Module (standard SSL/TLS over TCP)?

   - Ethernet (standard SSL/TLS over TCP)?

   - Bluetooth?

     IE Doing SSL/TLS over Bluetooth using the wolfSSL I/O abstraction layer and not using bluetooth protocol

- Possibly taking advantage of on-board crypto (if available)?

- Cipher suites? (Which algorithms would the community like to see running on a WICED device)?

- Specific algorithms? (Stream ciphers, block ciphers, AEAD modes, Perfect forward secrecy... etc)?

- Optimized build? (only showing the smallest footprint conscious features)

- Full Featured build? (Show off everything with no regard for build size)

Let us know your thoughts and feedback!

Regards,

Kaleb and the wolfSSL Team

0 Likes
8 Replies
user_108962310
Level 4
Level 4
10 likes received 10 likes given 5 likes given

kalsheraut

I know this an old post, but I'll offer what I would really be looking for:

Memory safety would be the #1 priority. Presently, the best we can do with TLS is to just leave as much heap space open as possible, and hope that things work out.

Even allocating a large static block (80K+) as the TLS workspace would be fine, if it facilitated provably-safe operation.

Secondarily, control of what is included in the cipher suite would be great, and I believe WolfSSL has fine-grained control over this.

The current mBedTLS + remainders of BESL that are being used are over 100KB, so anything considerably below that would be a big win.

Not many micros (especially not many ST micros) have crytpo cores, so I don't know how useful redirection to hardware peripherals would be.

@user_108962310

user_108962310 wrote:

kalsheraut

I know this an old post, but I'll offer what I would really be looking for:

Memory safety would be the #1 priority. Presently, the best we can do with TLS is to just leave as much heap space open as possible, and hope that things work out.

Even allocating a large static block (80K+) as the TLS workspace would be fine, if it facilitated provably-safe operation.

Secondarily, control of what is included in the cipher suite would be great, and I believe WolfSSL has fine-grained control over this.

The current mBedTLS + remainders of BESL that are being used are over 100KB, so anything considerably below that would be a big win.

Not many micros (especially not many ST micros) have crytpo cores, so I don't know how useful redirection to hardware peripherals would be.

Thank you so much for your feedback! Memory safety is always a concern and wolfSSL offers both blinding and near constant time solutions in software to assist with this.

wolfSSL builds can be tailored to support subsets of cipher suites only so yes absolutely we have some ECDHE_RSA builds that come in around 80K (assuming compiler is somewhat capable at optimizing of course, assume plus or minus 5k to compensate). ECC builds are on average about 19% smaller than RSA builds and Ed/Curve 25519 builds are about 35% smaller than RSA. So yes we have options under 100k absolutely!

Have you looked at the CUBEMX stuff for ST before? We recently added a bunch of support for CUBEMX which can generate Hardware Abstraction Layer API's (HAL API's) for multiple ST parts that do have hardware engines! Here are some links if you would be interested to read more on that.


https://www.st.com/en/development-tools/stm32cubemx.html

https://www.wolfssl.com/stm32f-support-expanded/

Thanks for all your thoughts! We'll keep them in mind when we put together the demo!

0 Likes

Sounds good. The TLS solution has changed at least twice over the story arc of SDK updates, and we now have all 3 different implementations in the field! (3.x.x, 5.x, and now 6.x ... mifo​ correct me if I'm wrong )

I did try to evaluate WolfSSL on Arduino or Particle platforms to test compatibility with our backend, but I couldn't get either to build, or they needed platform-specific implementations (gmtime, xtime, etc) that weren't straightforward.

So if you made a drop-in demo/library, I could evaluate immediately with our existing system.

CubeMX isn't too relevant to our application right now since the F4 family we are using does not have the cryto core, and ST has very limited M4 parts that have both AES and SDIO (required for the Cypress radio).

JoBl_3270231
Level 2
Level 2
First like received First like given

user_108962310KalebHimes

I'm currently working on the WICED port to wolfSSL and am finishing up a client TLS demo/snip using wolfSSL's example server found in the wolfSSL repository on GitHub. If you could send me a list of cipher suites that you would be interested in using, I would certainly put together a couple examples you could use to evaluate wolfSSL. I would need a few days to finish up and could have the examples by the middle to end of next week.

Thank you!

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_GCM_SHA384

Thank you for the list of suites. I'm starting to work on adding them. Would you like to set up a call later today or possibly tomorrow so, I can get your environment details? Whatever works best for you, I'm available either day. Feel free to contact me at jblixt[at]wolfssl[dot]com or john[underscore]blixt[the number one] on skype as well.

Regards,

John

The examples of wolfSSL with WICED SDK are NEARLY ready (Currently considered Beta and we would welcome any/all testing from the community)!

WICED supported versions  are WICED 6.1 and WICED 6.2.

Examples include:

  • A wolfCrypt test suite and benchmark test
  • A wolfSSL TLS client and server
  • A wolfSSL HTTPS client

WICED features supported by the examples:

  • NetX Duo TCP/IP stack for embedded systems
  • ThreadX RTOS for embedded platforms

Functionality supported by the examples:

  • TLS versions 1.0, 1.1, 1.2, and 1.3
  • Certificate verification
  • Certificate chain loading
  • RSA and ECC certificates
  • Multithread capability
  • Session resumption

A TLS client and server was added using the wolfSSL library, as well as, an HTTPS client example. wolfSSL supplies a client and server for testing purposes, the HTTPS client example also runs against the wolfSSL example server as well as www.example.com for demonstration purposes.

wolfSSL is a highly configurable option to accompany WICED software allowing manual configuration options affecting functionality and build size. The examples provided serve as a starting point for any embedded project and support TLS versions 1.0, 1.1, 1.2, and 1.3; they are built on the ThreadX RTOS using NetX Duo for the TCP/IP stack.

Cipher suites supported out of the box:

  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES256-SHA384
  • ECDHE-ECDSA-CHACHA20-POLY1305
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-SHA
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-SHA
  • ECDHE-RSA-CHACHA20-POLY1305
  • AES128-GCM-SHA256
  • AES256-SHA256
  • AES256-GCM-SHA384
  • AES128-SHA

Cipher suites supported for TLS 1.3 out of the box:

  • TLS13-AES128-GCM-SHA256
  • TLS13-AES256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES128-CCM-SHA256

This is not a comprehensive list of possible suites available only those that were included in the code snip for the WICED platform.

To get early access to the examples for testing and evaluation please shoot us an email at "support [at] wolfssl [dot] com" or open an issue with our support team through

"https [colon forward-slash forward-slash] wolfssl [dot] zendesk [dot] com" to get a copy of the patch files required for WICED SDK and a copy of the wolfSSL WICED examples applications!

@user_108962310

0 Likes

Greetings again Cypress/WICED community,

We wanted to let both the Cypress and WICED communities know about one of our more recent offers, a FIPS-Ready solution for all of our customers. Allow me to provide a little background on FIPS and how FIPS-Ready can help you:

FIPS 140-2 is a government standard that specifies a software module is compatible and allowed to be used in government systems. This includes such areas as drone software, government databases, and other high-security uses. Along with the new wolfCrypt FIPS cert #3389 we are offering a version of our library which uses the code that was certified. This won't include a validation for your product but what it will do is allow you to build the same code that was validated on other OE's. Then if/when an opportunity comes along for you to sell a product to a customer that requires FIPS you will already be setup to go to the LAB for validation. You simply send wolfSSL a copy of your hardware with the FIPS-Ready software installed and  running, we take it through the validation process and once your FIPS validation is complete you can begin marketing it to government and other FIPS 140-2 consumers.

If you are interested in this you can download a copy from the wolfSSL download page, just look for the wolfssl-4.0.0-glpv3-fips-ready.zip! If you have any questions or comments please shoot us a note at "support [at] wolfssl [dot] com" anytime, we would love to hear your feedback and commentary!