Q: Can you explain SSLMAC?

A: TLSv1 uses HMAC-SHA-1 or HMAC-MD5, however SSL version 3.0 uses a different cryptographic MAC that we (and others) call SSL MAC.  The information about this MAC is a little bit difficult to find, but it is discussed in Section of the SSL 3.0 draft specification (http://tools.ietf.org/html/rfc6101), the SSL MAC is also discussed in Section 3.4 of a paper by Bruce Schneier which I have included with this email.  Internally we use the book SSL and TLS Essentials by Stephen Thomas as a reference to the SSL MAC.

Q: Do you support AES-512?

A: This depends whether you're asking about 512-bit XTS-AES keys, or genuinely looking for 512-bit key strength using AES.

The XTS mode algorithm actually uses two separate AES keys: one is used for the main block encryption process, while the other is used to generate a "tweak value" for each block. The P1619 standards body technically refers to these modes as XTS-AES-128 and XTS-AES-256, but unfortunately the community (including us) has also taken to referring to the keys as 256-bit and 512-bit XTS-AES keys, based on the number of bits in both the "main key" (Key1) and the "tweak key" (Key2). So people easily get confused by the different references.

If you're being asked about 512-bit AES key strength, there is no definition of an AES-512 algorithm, though the underlying Rijndael cipher can definitely be extended to a 512-bit key. Of course, 512-bits of key strength is massive overkill, since a 256-bit AES key protects data for hundreds of years (based on current assumptions about the growth of computing technology). Please let us know if you've actually been asked about 512-bit key strength. However, we are going to assume the question relates to XTS-AES.

Q: What is the power consumption for your hardware IP?

A: Power is very tricky to analyze, as there are a lot of variables at play, and we don't actually build and test our own silicon to do real power measurements. As an IP provider, it isn't really possible for us to properly characterize power consumption given the variety of processes, libraries and implementation details involved, and the difficulty of getting these correct and confirming them against our customers' assumptions.

When pressed, we usually go through an estimation analysis using the size (in gates) and memories involved, all of the parameters of the specific target process (i.e. gate power in 'nW/MHz-g', gate leakage, etc.) and an understanding of how crypto cores typically behave.

The basic formula we would typically use for active power is:

(gates)*(power factor)*(clock)*(activity factor)*(interconnect factor)

Since our customers have most of that information already based on their process and design, we often find they are better equipped to do the power analysis since it is typically part of their process already. Obviously, memories also have to be analyzed separately.

The main thing we can provide guidance on is the activity factor. Crypto is a relatively chaotic process, and thus we typically assume closer to 40-50% in the symmetric cores, as compared to a standard piece of logic which would be closer to 15%. Since additional power management is typically handled by our Customer's logic outside our block (i.e. clock gating), there aren't any further tricks to analyze on that front.

This is true for all crypto technologies, and not just Elliptic. It's important to note that the statement above is only true while a given function is being utilized - crypto logic is not active unless it is processing data.

In the general case, dynamic power consumption (while crypto is active) can be estimated for your process and libraries by assuming the following:

  • a 50% (average) activity factor for the cryptographic components (crypto is a highly chaotic process by design)
  • a more standard 15-20% (average) activity factor for the rest of the logic
  • a very low average activity factor for memories, since it follows the standard 15-20% activity for logic, but also only accesses a very small % of the memory for each event
    • The bulk of power consumption for memories is leakage, based on the memory technology selected
    • We don't provide vendor-specific memory models
      • The customer is responsible for instantiating physical memory models into the IP
      • Elliptic provides memory dimensions and wrappers that contain behavioral models for IP integration simulation purposes
      • Memory compilers typically provide active and leakage power characterization

From this information, you could then also apply modeling of how much crypto activity is being requested/applied in time (on average) in your application to calculate energy consumption.

This methodology has shown strong correlation to specific customer silicon data in the cases where this information has been shared.

Q: Are your products FIPS 140-2 certified?

A: FIPS 140-2 compliance is strictly a system-level specification, and as such we can’t actually get “certified” for our IP cores – though we do know that some of our customers have completed certification with our IP embedded in their systems. Part of the FIPS 140-2 process is that the individual algorithms must undergo separate validation under the Cryptographic Algorithm Validation Program (CAVP). We undertake all available testing for our algorithms, both in hardware (RTL) and software (C), and have certificates available at the following websites:

AES Certificate

3DES Certificate

SHA Certificate

HMAC Certificate


FIPS 140-2 provides guidelines for security at the device level, meaning only completed products (and not components or IP) can be considered FIPS 140-2 “compliant”. However, our TRNG is certainly FIPS 140-2 “ready”, and has been used by several customers whose products have later successfully undergone FIPS testing. Our TRNG has also been reviewed in another customer’s product by by a major NATO member security agency for classified use and was found to produce cryptographically random results of very high quality.

We do offer sample data in a file that we can provide you. It’s quite large, so let us know if you have any difficulty downloading or reviewing it. The file is called “TRNG_data.tar”.

Note that this material is protected under terms of your non-disclosure agreement with us. This data has been analysed by us using diehard and other tools here.

The file "rand.bin" is 100 MB from an actual ASIC TRNG implementation identical to the one we are discussing, integrated in one of our customer's IC products. The product in question was implemented in a quite standard 130 nm technology using fab-supplied cell libraries. For confidentiality reasons we cannot disclose further information than that. This is the analog front-end generator output passed through our whitening filter.

The other outputs we captured are two files of 100 MB each trng.build_8848B4D9.5Mar2010.[12].bin (we actually saved much more than that, but I expect this will be plenty for you) from an FPGA implementation in our lab. This implementation does not include the analog front end due to technology limitations in FPGAs, but incorporates the entire whitening filter chain driven from a unique seed. By design, this product can be operated in either a full TRNG mode in which every output is derived from a continuous stream of analog samples, or in a PRNG mode in which a sequence of RNG outputs can be generated from an analog seed, with reseeding occurring under (typically) software control.


FIPS 140-2 compliance is strictly a system-level specification, and as such we can’t actually get “certified” for our IP cores – though we do know that some of our customers have completed certification with our IP embedded in their systems. Part of the FIPS 140-2 process is that the individual algorithms must undergo separate validation under the Cryptographic Algorithm Validation Program (CAVP). A complication with this particular core is that the cryptographic components (AES in ECB and CTR modes, GHASH) are not accessible. Elliptic has done some preliminary work with our NVLAP Lab (the authority that certifies CAVP results) to develop a method to validate the AES core in-situ within the LLP-04/05 perimeter. If desired, we can work with you in a validation program to obtain CAVP certification of your implementation. Your customer (or you) would continue to be responsible for the remainder of the FIPS 140-2 certification process.

Regardless of all that, your customer will definitely need to get the compliance for their product no matter what we (or even you) provide in terms of the PHY device information. There are a few important things they’ll be looking for:

  • Ability to validate the crypto functionality
    • This is why they’re looking for direct access to the underlying AES and GHASH functions. Contact Elliptic for more information regarding support for direct access for these functions.
    • The inquiry to NIST initiated by Domus in response to our query resulted in an initially favourable response that correct operation of the more complex modes could be taken as evidence that the underlying primitive operation implementation is also correct.
  • Comprehensive definition of the cryptographic boundary, and techniques used to protect keys from being snooped or otherwise manipulated
    • This will mainly be a system-level question. Our IP allows the keys to be read or written. But either in your device implementation, or even at the board/system level, something must be done to protect the keys from being read.
    • Depending on the FIPS 140-2 level they are targeting, they may also need to implement countermeasures to zeroize the key memories on detection of a tampering event (even if power has been cut). There is usually a system-level countermeasures plan for this sort of thing, using capacitive backup to provide enough residual power to execute the countermeasures (or something similar).

Q: Is the motivation for the CTR mode in IPSec because of its higher performance?

A: CTR is an interesting mode, and we don’t actually see it come up very often in IPsec apps. There are several reasons:

  • CTR mode has a lot of conditions and constraints that must be observed in order to be used securely (you can read these in RFC 3686)
  • The main motivation to use CTR mode in most applications is because it can be parallelized for increased throughput. However, most authentication modes (such as SHA) can not be parallelized, and thus this is only useful for increasing large packet performance.
  • It is absolutely essential to use authentication with CTR, as it is very easy to forge messages.
  • AES-GCM mode was eventually devised to address this scaling problem. It uses CTR mode and a Galois-field-based authenticator that has no feedback loops in order to support unrolled implementations.

Because of the above factors, the motivations for people to use CTR mode as defined in RFC 3686 are somewhat dubious (particularly now that a GCM RFC has been developed).

Perhaps the most important thing to consider when selecting IPsec modes to support is the fact that there are mandatory modes that ALL devices claiming IPsec support must include (RFC 4835). So, for example, by supporting 3DES and SHA1, you will always be able to establish a connection to any endpoint. By adding AES-CBC and SHA256, you can be assured that over time, when 3DES and SHA1 begin their sunset periods and AES and SHA256 become the favored mandatory ciphers, you’ll still always be able to handle connections.

Basically, the primary motivator for supporting other modes is if either you or other endpoints are taking advantage of some inherent feature of the mode. In the case of CTR mode, the only way this would be truly advantageous is if both your side and the other endpoint negotiated CTR mode for multi-gigabit connections, where the implementation could parallelize the ciphers (again, only relevant for large messages). Since your system is still within the realm of a single AES core (up to 1 Gbps), you should always be able to negotiate back to CBC mode. The only exception is if you expect to be dealing with a non-compliant endpoint that only supports CTR or more generally, if you’re selling into a closed system that supports one and only one of these modes.

The drivers for XCBC are different, but the motivations above are similar. XCBC is mainly there to allow smaller, cheaper devices to support only AES (with two modes) rather than AES, DES and SHA. The goal here is to sacrifice performance for the sake of device cost (either code space in software or chip area for hardware offload). The other motivation is for a single crypto operator of a given key strength, rather than mixed operators. Now, that said, XCBC is on the “SHOULD+” list in RFC 4305, so it is intended to eventually become a MUST. However, that is likely years in the future, given the time it takes for these things to happen.

Q: Can you summarize Elliptic’s hardware IPSec solutions?

A: Elliptic offers a range of IPsec offload solutions, depending on the overall system performance and offload requirements. The range of solutions is listed below, in order from smallest, lightest offload to maximum offload.

In all cases, the mixture of specific cryptographic modes can be parameterized to match the requirements of the application. In most cases, there are also a range of parameters that affect the size and performance of individual cipher and hash modes, which can be fine-tuned in discussion with Elliptic staff.

Every solution offers the following set of features at a minimum:

  • AES-CBC mode cipher supporting 128, 192 and 256-bit key sizes
    • DES-CBC mode cipher supporting 56 and 168-bit (3DES) key sizes
    • HMAC-MD5 and HMAC-SHA-1 mode hash
    • Optional support for GCM-AES and SHA-256

Most solutions also offer support for other ciphers, hashes and modes for raw cryptographic offload not associated directly with IPsec.


  • Configurable mix of cryptographic cores
  • Shared memory pool
  • Shared interface (1 Slave)
  • Optional Secure Key Ports

Typical CPU Offload: 20-30 MIPS/Mbps Header Processing Offload from CPU: None
System Performance Range: 5-50 Mbps Size Range: 40k-100k gates

CLP-600: SPAcc

  • Configurable mix of cryptographic cores
  • Shared memory pool
  • Shared interfaces (1 Master, 1 Slave)
  • Scatter-gather DMA-based packet memory architecture
  • Optional Secure Key Ports

Typical CPU Offload: 25-30 MIPS/Mbps Header Processing Offload from CPU: None
System Performance Range: 20-200 Mbps Size Range: 80k-160k gates

SPP-230: ESP/AH PDU Processor

SPP-330: IPsec/TLS Multi-protocol PDU Processor

LLP-130: Multi-threaded ESP/AH PDU Engine

  • Configurable mix of cryptographic cores
  • Configurable number of parallel processing pipelines, each with dedicated cryptographic cores
  • Shared memory pool
  • Shared interfaces (N Masters, M Slaves)
    • Interface options based on flexible assignment of input/output pipelines, SA interfaces, etc.
  • Scatter-gather DMA-based packet memory architecture
  • Security protocol sequencing (for parallel cipher/hash processing)

Typical CPU Offload: 30-35 MIPS/Mbps Header Processing Offload from CPU:

  • AH & ESP mode processing for IPv4 & IPv6
  • Transport mode processing
  • Tunnel mode processing
  • Extended Sequence Numbers
  • Per-packet SA management

System Performance Range: 100-20 Gbps Size Range: 300k-1200k gates

CLP-300: Public Key Accelerator (PKA)

Elliptic's Public Key Accelerator (PKA) for RSA & ECC provides acceleration of the processing-intensive asymmetric cryptography functions required for RSA-based and ECC-based applications. Specifically:

For RSA:  Modular Math (i.e. ModExp, ModDiv, etc.) and the associated Pre-Compute functions.

For ECC:  Point Math (i.e. PointMultiply, PointDouble, etc.)

It supports these functions across multiple key sizes, which can be dynamically selected at run-time. It can dramatically improve performance (up to 50x) compared to a software-only solution, while simultaneously reducing power consumption.

CLP-800: Smart True Random Number Generator (TRNG)

The compact Smart TRNG combines a whitening circuit with a noise source that provides automatic seeding of the random number stream and an ongoing source of entropy to the core. The core is therefore classified as a non-deterministic random bit generator using NIST terminology. The noise source does not depend on process specific circuitry and is therefore very portable across different fabrication technologies.

  • Compliant to both NIST 800-22 and FIPS 140-2
  • Optional support for SPA/DPA timing attack resistance
  • High speed operation – 12.5 Mbps at 50 MHz core clock
  • Initial seed provided from internal noise source
  • Automatic re-seeding


tRoot w embedded chip flexible future proof 


Elliptic's Secure Foundation of Trust 

Elliptic's tRoot is a highly-secure foundation of trust that enables connected devices to securely and uniquely identify and authenticate themselves to create secure channels for remote device management and service deployment for further revenue opportunities. tRoot has a unique architecture with the ability to effectively adjust to future security requirements and standards, and enable personalization of features, services and environments to create business growth and monetization in the exploding IoT market. Learn more >>


EE Journal logo

"I Am tRoot" by Jim Turley

Apart from handling cold-boot procedures, tRoot also lends a hand in other security-related chores. Need to deliver DRM-protected material? Elliptic's hardware and software will manage the keys. Worried about cloning? Your tRoot is on the job. Concerned that hackers armed with sensitive instruments might mount a side-channel attack? That's the sort of thing tRoot was born to fight. Read the EEJournal article about Elliptic tRoot >> 


S5 Box