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 18.104.22.168 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:
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:
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..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:
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:
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:
Most solutions also offer support for other ciphers, hashes and modes for raw cryptographic offload not associated directly with IPsec.
Typical CPU Offload: 20-30 MIPS/Mbps Header Processing Offload from CPU: None
System Performance Range: 5-50 Mbps Size Range: 40k-100k gates
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
Typical CPU Offload: 30-35 MIPS/Mbps Header Processing Offload from CPU:
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.
tVault™ PLUS provides robust end-to-end security by protecting content from distribution centers to smart devices and multiple displays, thus meeting the stringent demands of Hollywood studios. Secrets and content are protected in the Trusted Execution Environment (TEE) during all stages of DRM playback and link protection for transmission to other devices.
tVault PLUS supports multiple DRM and link protection standards including Microsoft® PlayReady®, HDCP 2.2 for Miracast, HDMI and DisplayPort, and DTCP-IP for DLNA applications. The solution is Global Platform compliant and provides an efficient small-footprint solution, enabling full-featured protection of High Definition (HD) or Ultra HD content on mobile and connected devices. tVault PLUS scales easily to incorporate additional content protection standards while minimizing use of limited TEE resources, offering flexibility, better performance and value while minimizing development costs, risks and time-to-market.