226 Topic by chrisc

(0 replies, posted in Announcements)

As stated in the TLS 1.1 and 1.2 protocol definitions (RFC 4346, RFC 5246), “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.”  TLS 1.2 is an improvement to the TLS 1.2 standard, but how exactly do they differ?  What was changed in TLS 1.2 to warrant a new version of the protocol?

Listed below are the changes made to both version 1.1 and 1.2 of the TLS protocol.  TLS 1.2 support is slowly making it’s way into existing projects.  The wolfSSL embedded SSL/TLS library fully supports SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.

A.  TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0.  The major changes are:
- The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
- Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
- IANA registries are defined for protocol parameters
- Premature closes no longer cause a session to be non-resumable.

RFC 4346:  http://tools.ietf.org/html/rfc4346#section-1.1

B.  TLS 1.2
This protocol was defined in RFC 5246 in August of 2008.  Based on TLS 1.1, TLS 1.2 contains improved flexibility. One of the primary goals of the TLS 1.2 revision was to remove the protocol’s dependency on the MD5 and SHA-1 digest algorithms.  The major differences include:
- The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
- The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash.  Signed elements include a field explicitly specifying the hash algorithm used.
- There was substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept.
- Addition of support for authenticated encryption with additional data modes.
- TLS Extensions definition and AES Cipher Suites were merged in.
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Many of the requirements were tightened
- Verify_data length depends on the cipher suite
- Description of Bleichenbacher/Dlima attack defenses cleaned up.
- Alerts must be sent in many cases
- After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list.
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite.
- Added HMAC-SHA256 cipher suites.
- Removed IDEA and DES cipher suites.  They are now deprecated.

RFC 5246:  http://tools.ietf.org/html/rfc5246

C.  Goals of the TLS Protocol

- Cryptographic security: TLS should be used to establish a secure connection between two parties.
- Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another's code.
- Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary.  This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.
- Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations.  For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch.  Additionally, care has been taken to reduce network activity.

Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS - Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS - What's the Difference? (http://luxsci.com/blog/ssl-versus-tls-w … rence.html)
Cisco - SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac … 1/ssl.html)

As always, if you have any questions or would like to talk to the yaSSL team about more information, please contact info@wolfssl.com.

Go to forum: Announcements

227 Reply by chrisc

(4 replies, posted in wolfSSL)

Added, thanks!

http://www.wolfssl.com/wolfSSL/Community.html

Best Regards,
Chris

Go to forum: wolfSSL

228 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi sissiok,

Those functions are prototyped in the <wolfssl/wolfcrypt/asn.h> header file.

To define WOLFSSL_TEST_CERT, you need to add it to C_EXTRA_FLAGS if using ./configure:

cd wolfssl-3.6.0
./configure C_EXTRA_FLAGS="-DWOLFSSL_TEST_CERT"
make
sudo make install

Then, define it when compiling your application as well.

Best Regards,
Chris

Go to forum: wolfSSL

229 Reply by chrisc

(1 replies, posted in wolfCrypt)

Hi Fred,

Requests for adding support for new hardware crypto modules come from both manufactures as well as individual companies/developers.

I'll send you an email to continue the conversation.

Best Regards,
Chris

Go to forum: wolfCrypt

230 Reply by chrisc

(4 replies, posted in wolfSSL)

Hi Alex,

Glad to see you got things figured out!  Do you mind if we list your project on our Community page (http://wolfssl.com/wolfSSL/Community.html)?

Thanks,
Chris

Go to forum: wolfSSL

231 Reply by chrisc

(4 replies, posted in wolfSSL)

Case moved to email support.

Go to forum: wolfSSL

232 Reply by chrisc

(1 replies, posted in wolfCrypt)

Hi Fred,

NXP isn't necessarily harder, we just haven't put together specific instructions for it yet.  In general, you should be able to follow the steps outlined in Section 2.4 of the wolfSSL Manual:

http://wolfssl.com/wolfSSL/Docs-wolfssl … lfssl.html

Best Regards,
Chris

Go to forum: wolfCrypt

233 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi Blink,

wc_ecc_make_key() generates both the private and public key.  You can export the public key using the following function:

int wc_ecc_export_x963(ecc_key*, byte* out, word32* outLen);

A good usage example is the ecc_test() function inside the wolfCrypt test app (<wolfssl_root>/wolfcrypt/test/test.c).

Best Regards,
Chris

Go to forum: wolfSSL

234 Reply by chrisc

(4 replies, posted in wolfSSL)

Hi Kackle123,

Have you tried running the wolfCrypt test app on your target platform to make sure the library has been configured correctly and that the crypto algorithms pass? 

The wolfCrypt test is located in <wolfssl_root>/wolfcrypt/test/test.c.  You can define NO_MAIN_DRIVER if you have your own driver code available.

Thanks,
Chris

Go to forum: wolfSSL

235 Reply by chrisc

(1 replies, posted in wolfCrypt)

Hi Midas,

Can you verify that you are compiling your application with the same preprocessor defines used to compile the wolfSSL library?  A simple way to do this if you used the autoconf/configure system to build wolfSSL is to include the <wolfssl/options.h> header in your application code, ie:

#include <wolfssl/options.h>

Best Regards,
Chris

Go to forum: wolfCrypt

236 Reply by chrisc

(2 replies, posted in wolfSSL)

Hi Blink,

When compiling a standalone application that uses the wolfSSL library, you'll need to make sure it is compiled using the same preprocessor defines as the library was compiled with.  If you used the autoconf system (./configure, make, make install) to build and install the library, you can simply include the <wolfssl/options.h> header in your application to pull in the same preprocessor defines.

Best Regards,
Chris

Go to forum: wolfSSL

237 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi Sudhakar,

Currently the only example project files that ship with wolfSSL are the CodeWarrior project files located under the <wolfssl_root>/mqx directory.  These were written for CodeWarrior in combination with the TWR-K70F120M platform.

If you download wolfSSL from our website and use it directly in your application, you can reference the wolfSSL Manual for documentation purposes:

https://www.wolfssl.com/wolfSSL/Docs-wo … l-toc.html

Freescale also has put together a CyaSSL Patch for KSDK which includes an evaluation version of CyaSSL in addition to an example HTTPS server using the RTCS web server (httpsrv_ssl_<platform>).  You can download this from the download link at:

www.freescale.com/ksdk

Freescale has a blog post explaining getting the httpsrv_ssl example up and running on a FRDM-K64F platform here:

https://community.freescale.com/message/469137#469137

Best Regards,
Chris

Go to forum: wolfSSL

238 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi Jordi,

It looks like the wolfSSL example client is able to connect to https://queue.amazonaws.com when I try in non-blocking mode (see below).  I also noticed that the server mentioned will only accept connections using TLS 1.0.

$ cd wolfssl-3.4.6
$ ./configure
$ make
$ ./examples/client/client -h queue.amazonaws.com -p 443 -v 1 -d -N
... client would read block
... client would read block
... client would read block
... client would read block
... client would read block
SSL version is TLSv1
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Are you sure you have your I/O layer set up correctly?

Best Regards,
Chris

Go to forum: wolfSSL

239 Reply by chrisc

(5 replies, posted in wolfSSL)

Hi Steve,

Nothing immediately sticks out at me as being incorrect in your above post.

Best Regards,
Chris

Go to forum: wolfSSL

240 Reply by chrisc

(7 replies, posted in wolfSSL)

Hi jal,

To use wolfSSL in a Android application, you'll want to download both wolfSSL-3.4.6.zip as well as wolfssl-jni-1.2.0.zip.  This provides you with both the native C library as well as the JNI bindings exposing the native library to a Java-based Android NDK application.

The CyaSSL Android SSL provider was something we experimented with several years back.  It's code is in "alpha" form, and future development will take place on wolfSSL JNI instead.

Best Regards,
Chris

Go to forum: wolfSSL

241 Reply by chrisc

(5 replies, posted in wolfSSL)

Hi Steve,

wolfSSL uses C_EXTRA_FLAGS with our ./configure system instead of CFLAGS.  Can you try appending your options to C_EXTRA_FLAGS instead?

We do this since at certain points we overwrite the default CFLAGS variable.

Best Regards,
Chris

Go to forum: wolfSSL

242 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi,

We're working on replying to your email.

Thanks,
Chris

Go to forum: wolfSSL

243 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi Matan,

By default, wolfSSL has an Input and Output buffer that are 5 bytes.  These grow and shrink using dynamic memory as SSL/TLS records are received or sent - growing up to a maximum of 16kB each.

If your application is only going to be doing one simultaneous read or write over SSL, you will only be using a maximum of 16kB.  If you will have two threads, both doing SSL/TLS, and may be doing a read and write at the same time, you could potentially get up to 32kB at a time.

Unfortunately, I don't have much experience with SMTP.  A while back, we did have a open source user integrate CyaSSL (now wolfSSL) into ssmtp.  His code can be found here:

https://github.com/tony2001/ssmtp

Best Regards,
Chris

Go to forum: wolfSSL

244 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi,

wolfSSL's ecc_verify_hash() expects the ECC key to be of type "ecc_key", which is a structure in <wolfssl_root>/wolfssl/wolfcrypt/ecc.h. You can create an ecc_key structure by either creating a new one with:

/**
 Make a new ECC key
 rng          An active RNG state
 keysize      The keysize for the new key (in octets from 20 to 65 bytes)
 key          [out] Destination of the newly created key
 return       MP_OKAY if successful, upon error all allocated memory will be freed
 */
int wc_ecc_make_key(RNG* rng, int keysize, ecc_key* key);

or importing an existing key with one of the following functions:

/* import public ECC key in ANSI X9.63 format */
int wc_ecc_import_x963(const byte* in, word32 inLen, ecc_key* key);

/* ecc private key import, public key in ANSI X9.63 format, private raw */
int wc_ecc_import_private_key(const byte* priv, word32 privSz, const byte* pub, word32 pubSz, ecc_key* key);

/**
 Import raw ECC key
 key       The destination ecc_key structure
 qx        x component of base point, as ASCII hex string
 qy        y component of base point, as ASCII hex string
 d         private key, as ASCII hex string
 curveName ECC curve name, from ecc_sets[]
 return    MP_OKAY on success
 */
int wc_ecc_import_raw(ecc_key* key, const char* qx, const char* qy, const char* d, const char* curveName);

Does this help?

Go to forum: wolfSSL

245 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi Matan,

1.Can anyone help me with estimating the minimum size of the TLS library I will have to use? SRAM is probably my most limited resource.

The typical footprint size of wolfSSL with an embedded optimized compiler is around 60kB of Flash.  The smallest embedded SSL build we have done to date is our "LeanPSK" build which came in at around 21kB of Flash.  This was a very stripped down version of the library - supporting only TLS 1.2, pre-shared keys, and SHA256.

RAM usage is between 1-36kB per SSL/TLS session, as outlined in the attached Resource Use document.

2. From reading online, I understand 16Kbyte(!) TLS buffer size must be used unless "both sides support the max_fragment_length SSL extension". I tried to figure out if this is absolutely required for secure smtp email via gmail/yahoo but didnt find any useful data. does anyone have any info regarding to this issue?

Your understanding of the TLS Max Fragment Length extension is correct - the client can request that a smaller TLS maximum fragment length be used, but if the server doesn't support that extension, it is ignored.

The SSL/TLS spec defines the maximum possible record size to be 16kB, which makes reducing it challenging unless you have the ability to use the above extension.

3.Is there any documented use of Wolf/cyaSSL with UIP stack?

We have had people use us with the uIP stack, but haven't used it in house before to my knowledge.  We have a I/O abstraction layer that allows you to write your own Input and Output callbacks.  This would allow you to run wolfSSL over any transport medium you choose.

4.If not, Is there any guide which can help me figuring out what are the required steps to get my device to perform TLS handshake with smtp server, using only the required parts of wolSSL, such that the memory footprint is minimal? Performance tradeoff is not an issue.

The Resource Use document should be helpful, as well as taking a look into our LeanPSK build.  Do you know if there are certain cipher suites and protocols you need to use?

Best Regards,
Chris

Go to forum: wolfSSL

246 Reply by chrisc

(3 replies, posted in wolfSSL)

Hi Jordi,

A return of WANT_READ means that wolfSSL needs to read additional data in order to progress the SSL/TLS state machine, but the underlying I/O doesn't have any data at the moment.  You'll need to loop on the SSL_read/write/connect/accept function and call it again when the underlying I/O is ready.

- Chris

Go to forum: wolfSSL

247 Reply by chrisc

(6 replies, posted in wolfCrypt)

Hi Jori,

After you've created a CSR with wc_MakeCertReq(), you can call wc_SignCert() to sign it with a CA key.  See <wolfssl_root>/wolfcrypt/test/test.c for an example.

Best Regards,
Chris

Go to forum: wolfCrypt

248 Reply by chrisc

(1 replies, posted in wolfSSL)

This is being handled through the wolfSSL support portal.

- Chris

Go to forum: wolfSSL

249 Reply by chrisc

(1 replies, posted in wolfSSL)

Hi Hemanth,

Using PSK will reduce the footprint size of the library significantly, but you'll need to have a framework in place to pre-distribute and manage the keys on your end devices.  Our "LeanPSK" build is the smallest build we have done to date.  Last time we compiled it on an optimized, ARM compiler, it had a footprint of around 21kB.  To compile the leanPSK build using the ./configure system, you can use the "--enable-leanpsk" build option.

If you don't want to use PSK, some things which will reduce footprint of a normal RSA or ECC build include:

1)  Define NO_OLD_TLS - this will eliminate all protocol versions except TLS 1.2 and reduce the library size by a few kB.

2)  Define NO_SESSION_CACHE - this will disable the session cache (as long as you don't need it) and will reduce the library size by a few more kB.

3)  Disable un-needed algorithms and ciphers.  For example, you could disable 3DES by defining NO_DES3

4)  If you only need to use ECC, you can compile out RSA by defining NO_RSA.  And, along these lines, you can define ECC_TIMING_RESISTANT, which cuts the heap usage in half and reduces the code size, but ECC operations are twice as slow.  Using ECC keys will save you memory, since ECC keys are much smaller than RSA keys at the same security level.

5)  If you are on an embedded platform which has hardware cryptography, this can reduce footprint size.  For example, AES has tables that take about 10kB, which are eliminated when offloaded into hardware.

Best Regards,
Chris

Go to forum: wolfSSL

250 Reply by chrisc

(1 replies, posted in wolfSSL)

We have had users use wolfSSL on VxWorks before, and I believe last time we checked (which was on an older version), there weren't any changes required to the wolfSSL code base in order to get the library to build. It may be that something has changed in newer versions of VxWorks.

By default wolfSSL assumes a BSD-style socket API is available (ie: send(), recv()). It sounds like you may not have those available, or that there is a setting in VxWorks which enables them (but are disabled by default). In the case where they are not available, wolfSSL includes an I/O abstraction layer. This allows a user to write their own Send and Receive callbacks. More info on this can be found in Section 5.1.2 of the wolfSSL Manual:

http://wolfssl.com/yaSSL/Docs-cyassl-ma … ility.html

If you don't have opendir() available, you can define NO_WOLFSSL_DIR when compiling wolfSSL.

We do ship Visual Studio project files for wolfSSL with each release. These are located in the root of the download package. It's usually pretty easy to pull wolfSSL into a new build environment as well, and is outline in Section 2.4 of the wolfSSL Manual:

http://wolfssl.com/yaSSL/Docs-cyassl-ma … yassl.html

Go to forum: wolfSSL