Low memory footprint

A typical embedded implementation uses

<50KB of flash and 4KB of RAM per connection


Implement 25 RFCs and widely deployed and tested against common TLS implementations

Robust security

Compliant with NIST Special Publication 800-52r1 and integrated with FIPS140-2 crypto (certificate #2389)

Product description

GUARD TLS-TK (formerly MatrixSSL) provides secure connectivity to devices with a small memory footprint. It has evolved to also serve networking devices requiring top performance. GUARD TLS-TK is a lean and efficient C source code SDK that is easy to integrate, and where bugs have few places to hide. GUARD TLS-TK is the SDK to replace RSA/BSAFE or OpenSSL.

Started by PeerSec Networks in 2003 under the name MatrixSSL, this TLS/DTLS stack is now developped by Inside Secure.

To provide high performance, GUARD TLS-TK is designed with true multi-threading, zero-copy processing and an asynchronous API for hardware integration. GUARD TLS-TK based customer solutions have achieved over 42 GBs of TLS throughput, 50,000 Handshakes per second for session setups, and 460,000 active sessions.

To provide robust security, GUARD TLS-TK has implemented the best practice from NIST Special Publication 800-52r1. For full compliance, GUARD TLS-TK is available with FIPS validated SafeZone cryptographic module. GUARD TLS-TK has not been affected by highly-publicized vulnerabilities (e.g. Heartbleed, POODLE, FREAK, DROWN) found in OpenSSL.

GUARD TLS-TK is available under a dual-licensing model: GNU Public License and a Standard Commercial license. The dual license means that one can easily evaluate the library for free, but that for commercial usage without the GPL constraints, one must acquire a license by contacting Inside Secure. The open source package can be downloaded from GitHub.

There two other commercial variants of this TLS implementation:

- An integration with SafeZone FIPS140-2 Cryptographic Module,  delivered as FIPS Security Toolkit.

- GUARD TLS Tiny for extremely constraint environments such as 8-bit microprocessors that can run with less than 10kB of Flash and 1kB of RAM  (an example of very lightweight cryptography).

Other information


  • TLS 1.0, 1.1 and 1.2 server and client support (SSL 3.0 optional)
  • DTLS 1.0 and 1.2 server and client support
  • Included crypto library - RSA, ECC (including Brainpool curves), AES, 3DES, ARC4, SHA1, SHA256, MD5, ChaCha20-Poly1305
  • Session re-keying and cipher renegotiation
  • Session resumption/caching, stateless session tickets
  • Extensions: server name indication, max fragment length, trusted CA keys, truncated HMAC, status request (OCSP)
  • Application Protocol Negotiation
  • Server and client X.509 certificate chain authentication
  • Parsing of X.509 .pem and ASN.1 DER certificate formats
  • PKCS#1.5, PKCS#5, PKCS#8 and PKCS#12 key formatting
  • RSASSA-PSS Signature Algorithm support
  • Online Certificate Status Protocol (OCSP)
  • Certificate Revocation List (CRL)
  • OpenSSL APIs wrapper to ease transition from OpenSSL
  • Cryptographic Messaging Syntax (CMS): for packaging signed/encrypted firmware updates or provisioning files in Smart Meters (commercial license)
  • PKCS#10 support (commercial license)
  • X.509 certificate generator (commercial license)
  • FIPS140-2 validated cryptographic module: it requires a license for FIPS Security Toolkit


  • < 50KB total footprint with crypto provider and certificates
  • < 10KB total footprint with PSK only (tiny version)
  • Assembly language optimizations for Intel, ARM and MIPS
  • Deployed on Bare Metal, FreeRTOS, eCos, VxWorks, uClinux, eCos, FreeRTOS, ThreadX, WindowsCE, PocketPC, Palm, pSOS, SMX, BREW, MacOS X, Linux and Windows.
  • Used on hardware platforms including ARM, MIPS32, PowerPC, H-8, SH3, i386 and x86-64. TILE-Gx, CAVIUM Octeon
  • Support for asynchronous crypto hardware
  • Fully cross platform, portable codebase; minimum use of system calls
  • Pluggable cipher suite interface
  • Pluggable crypto provider interface
  • Pluggable operating system and malloc interface
  • TCP/IP optional
  • Multi-threading optional
  • Only a handful of external APIs, all non-blocking
  • Example client and server code included
  • Clean, heavily-commented portable C code

RFCs compliance

  • RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0: Supported
  • RFC 3274  Compressed Data Content Type for Cryptographic Message Syntax (CMS): Supported with commercial license
  • RFC 3749 Transport Layer Security Protocol Compression Methods: Supported
Disabled by default due to security issues.
  • RFC 4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS): Supported
Disabled by default at compile time.
  • RFC 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS): Supported
  • RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1: Supported
  • RFC 4347 Datagram Transport Layer Security (DTLS) Version 1.0: Supported
  • RFC 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS): Supported
Supported Elliptic Curves: secp192r1, secp224r1, secp256r1, secp384r1, secp521r1
Supported Point Formats: uncompressed
  • RFC 5077 Transport Layer Security (TLS) Session Resumption without Server-Side State: Supported (Session Tickets).
  • RFC 5083 Cryptographic Message Syntax (CMS) - Authenticated-Enveloped-Data Content Type: Supported with commercial license
  • RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2: Supported
  • RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS: Supported
  • RFC 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM): Supported
  • RFC 5430 Suite B Profile for Transport Layer Security (TLS): Supported via compile time configuration.
  • RFC 5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS):
These ciphers are removed per spec:“…the single-DES cipher suites SHOULD NOT be implemented by TLS libraries …the IDEA cipher suite SHOULD NOT be implemented by TLS libraries and SHOULD be removed from existing implementations.”
  • RFC 5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode: Supported
  • RFC 5652 Cryptographic Message Syntax (CMS)
Signed-Data Content Type: Supported with commercial license.
  • RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension: Supported
Extension required by compile time default.
  • RFC 6066 Transport Layer Security (TLS) Extensions: Extension Definitions
server_name Server Name Indication: Supported
max_fragment_length: Supported
client_certificate_url: Unsupported
trusted_ca_keys: Supported
truncated_hmac: Supported
status_request OCSP Client: Supported
  • RFC 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0: Supported
SSL 2.0 (including ClientHello) deprecated.
  • RFC 6347 Datagram Transport Layer Security Version 1.2: Supported
  • RFC 7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS): Supported Curves
  • RFC 7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension: Supported
  • RFC 7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS): Supported
  • RFC 7465 Prohibiting RC4 Cipher Suites: Supported
RC4 ciphers are disabled by default at compile time.
  • RFC 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS): Supported
  • RFC 7568 Deprecating Secure Sockets Layer Version 3.0: Supported
SSL 3.0 is disabled by default at compile time.
  • RFC 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension: Supported
  • RFC 7925 TLS/DTLS Profiles for the Internet of Things: Supported via compile time configuration.
  • RFC 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS): Supported
  • RFC 7918 Transport Layer Security (TLS) False Start: Supported
Disabled by default due to security concerns.

Support And Maintenance

Commercial customers

Commercial customers have access to our code under a commercial license (GPL-free) and benefit from a support contract with direct access to our development team. Their support requests are treated with priority. They will automatically receive new updates of the product.

Open Source users

Open source users can ask questions or propose patch through GitHub. They can also contact us by email: support@matrixssl.org.

As we are not able to contact open source users, please regularly check GitHub for the latest release.

Security researchers

We appreciate the work of security researchers that help us to maintain a high security standards. We would recommend that they report any security issues to support@matrixssl.org using the following PGP Key, Key fingerprint = D6AD F1C5 E34E 696B 0953 556C 8BB2 B39A 2795 C6B3.

Latest versions under GPL:

MatrixSSL 3.9.1 (March 21, 2017)

This version was driven by the need to update the test certificates that were expiring. There are no strong reasons to upgrade if you already use 3.9.0.

  • Disabled support for SHA-1 signed certificates by default. SHA-1 can no longer be considered secure for this purpose (see https://shattered.it/static/shattered.pdf). We decided to disable SHA-1 signed certificates by default to ensure that MatrixSSL customers consider the security implications before enabling them. Support for SHA-1 signed certificates can be restored by defining ENABLE_SHA1_SIGNED_CERTS in cryptoConfig.h.
  • Regenerated all test certificates. Many of the old ones had exceeded their validity period. The new test certificates have some minor changes, such as the addition of some missing basicConstraints and authorityKeyIdentifier extensions. Note that the test certificates should never be used in production, but only for initial testing during development.
  • Fixed bug that caused a segfault when ALLOW_VERSION_1_ROOT_CERT_PARSE was enabled and the peer sent a version 1 certificate. Correct behaviour is to just produce an internal certificate validation failure in this case, as the above define only allows parsing of locally stored trusted root certificates. This bug is minor as ALLOW_VERSION_1_ROOT_CERT_PARSE is disabled by default, and rarely used by MatrixSSL customers.
  • Introduced new function setSocketTlsCertAuthCb for setting certificate authentication callback when using MatrixSSL via psSocket_t interface. Previously constant function name ssl_cert_auth was used for authentication callback.

MatrixSSL 3.9.0 (March 10, 2017)

This version contains several new features and bug fixes. It is recommended for all users.

    • Client Authentication using an External Security Token
    • RFC 5280 Compliant Certificate Matching
    • Certificate Validation Configuration Options
    • X.509 Generation Improvements (Commercial Edition Only)
    • Added psX509GetOnelineDN API
    • Added matrixValidateCertsExt API
    • Support for RSA-MD2 and RSA-MD5 Signatures in CSR and CRL Parsing
  2. BUG FIXES SINCE 3.8.7b
    • Fixed server-side handling of client authentication with Server Name Indication
    • Constant Time Modular Exponentiation

Full list of changes and changes in previous version are described in the source code package on GitHub:



See also

 The GPL version can be downloaded from: https://github.com/matrixssl/matrixssl/releases/latest