Rambus

At Rambus, we create cutting-edge semiconductor and IP products, spanning memory and interfaces to security, smart sensors and lighting.

Security Icon

Security

Inside Secure TLS Toolkit 4.0, a complete and compact TLS implementation supporting TLS 1.3

Inside Secure TLS Toolkit (formerly known as MatrixSSL) is a TLS protocol implementation in C language with minimalistic system dependencies making it easily portable on any platform. Inside’s TLS Toolkit powers millions of products ranging from embedded devices with very limited capabilities to high-end network equipment. 

Contact Us IconContact
Download TLS Toolkit Product BrochureProduct Brochure

Complete, compact and portable

Delivered in clear, readable, cross-platform and well documented C source code optimized for size and performance

TLS 1.3 protocol

Inside’s TLS Toolkit is quick to adopt latest IETF specifications

Robust security

TLS Toolkit is available with FIPS 140-2 validated Inside Secure Crypto Module

How the Inside Secure TLS Toolkit works

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

Thanks to a clear and well documented source code integration is faster and smoother than alternatives. To further simplify and accelerate the integration, Inside Secure offers developer level support.

Inside’s TLS Toolkit has always been quick to adopt the latest TLS specifications. For example, support for the TLS 1.3 protocol was released in August 2018, within days of IETF publishing the RFC 8446 specification.

Inside’s standard offering can be configured to a minimal code footprint of 66 kB (PSK). Manual optimization can further reduce the code footprint to meet the needs of memory constrained devices.

For applications that require FIPS validation, Inside’sTLS Toolkit is also offered with a state-of-the-art FIPS 140-2 validated crypto module (certificate #2389 https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2389), successfully used in hundreds of millions devices.

For applications switching from OpenSSL a compatibility layer is provided to smoothen and accelerate migration to Inside’s TLS Toolkit.

TLS Toolkit 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 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 (https://github.com/matrixssl/matrixssl).

CryptoManager Root of Trust Cover

The CryptoManager Root of Trust

Built around a custom RISC-V CPU, the Rambus CryptoManager Root of Trust (CMRT) is at the forefront of a new category of programmable hardware-based security cores. Siloed from the primary processor, it is designed to securely run sensitive code, processes and algorithms. More specifically, the CMRT provides the primary processor with a full suite of security services, such as secure boot and runtime integrity, remote attestation and broad crypto acceleration for symmetric and asymmetric algorithms.
Download White Paper

Inside Secure TLS Toolkit Information

Features

  • Supports the latest TLS specifications: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 DTLS 1.0, DTLS 1.2
  • Both server and client roles
  • Crypto library included supporting all major algorithms
  • Ciphersuites
    • AES 128/256 GCM with SHA256/384
    • CHACHA20 POLY1305 with SHA256 
  • Key exchange modes
    • DHE (ffdhe2048, ffdhe3072, ffdhe4096)
    • ECDHE (P-256, P-384, P-521, Curve25519) 
    • PSK and PSK with DHE and ECDHE
  • Signature algorithms
    • ECDSA (P-256, P-384, P-521)
    • Ed25519
    • RSASSA-PSS, RSA PKCS#1.5 (certificates only)
  • Available with FIPS 140-2 validated Inside Secure Crypto Module
  • Pluggable crypto provider interface
  • Pluggable operating system and malloc interface
  • Standards compliant proven interoperability
  • Portable on any platform, minumum use of system calls
  • Better alternative to OpenSSL and RSA BSAFE
  • Available with an OpenSSL compatibility layer
  • Small footprint and optimized performance for IoT devices
  • Delivered in clear, readable, cross-platform, well documented and commented C source code
  • Developer level support available

Implementation

  • < 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, PocketPC, Palm, pSOS, SMX, BREW, MacOS X and Linux.
  • 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
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
  • 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
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
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
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
  • RFC 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM): Supported
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
  • 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
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
  • 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
brainpoolP224r1, 
brainpoolP256r1, 
brainpoolP384r1, 
brainpoolP512r1
  • 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
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • 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.3 (June 26, 2017)

This version fixes serious buffer handling vulnerabilities along with other smaller bugs. Upgrading to the latest version is highly recommended. Check the release notes on GitHub for details.

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.

  1. NEW FEATURES SINCE 3.8.7b
    • 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
    • ALLOW_CRL_ISSUERS_WITHOUT_KEYUSAGE Compatibility Option
  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:

https://github.com/matrixssl/matrixssl/releases/latest

From the blog

Resources

News

Related Papers

Videos

Watch CryptoManager Platform

Related Markets & Applications

Automotive
Data Center
IoT
Mobile

FREE Webinar: Understanding Fault Injection Attacks and Their Mitigation

Register Today