The Evolution of Security IP

By Richard White
President and CEO
Elliptic

Over the last two years, Elliptic's business model has changed significantly in response to our customers' requirements to outsource their security designs to Elliptic. This reflects the increasing complexity of security design - it is a constantly changing field with standards being renewed in the face of new vulnerabilities in what were thought to be robust security designs.

As an example, the latest challenge the industry has faced was seen in the IEEE P1619 standardization for storage security. After spending well over a year debating which AES algorithm to use, the committee came very close to ratifying LRW-AES. To the dismay of the IEEE and early implementers, the algorithm was found to be vulnerable to certain attacks and was quickly replaced by XTS-AES which appears to address the weaknesses identified in LRW-AES. Not surprisingly, customers are now hedging their bets in new storage designs by putting down multiple security algorithms including GCM-AES or even the much slower but fully proven AES-CBC algorithm to be sure that their silicon is bullet proof against new vulnerabilities. The storage industry continues to watch the National Institute of Science and Technology (NIST) very closely to see if they will endorse XTS-AES which will allow implementers to sleep more peacefully.

Another recent example of hedging your bets has occurred in the 3GPP LTE Project where the confidentiality and integrity algorithms have adopted SNOW 3G as a backup algorithm in the event that the KASUMI algorithm is ever hacked or compromised. A practical response to the complexities of building secure systems that will last for decades in the face of mounting attacks.

Elliptic certainly can't guarantee that an algorithm won't be hacked and rendered obsolete; we can however offer guidance on work around strategies and fall back solutions to hedge against these unexpected situations which are the norm in this dynamic industry.

As an example of the complexity facing SoC designers, Table 1 offers an outline of the breadth of the standards that Elliptic watches.

Although there has been some convergence on AES as the primary standard for encryption based on the NIST recommendation, there is now a proliferation of AES modes. Often this is for good reasons, i.e. in storage security where XTS-AES offers the unique feature that the ciphertext is the exact same size as the plaintext to fit precisely into the sector based structure of disks. In other cases, new AES modes such as -f8 have been developed which are specific to one standard - in this case SRTP.

With this proliferation of standards comes the question of how to implement solutions that address multiple markets. Elliptic has architected a highly configurable solution that can be profiled to address a broad array of requirements. The engine is called the CLP-32 IPsec/SRTP Offload Engine and it has now been extended to address multiple markets including DRM, conditional access and wireless base-station applications.

The CLP-32 Close-Up

Figure 1 shows the block diagram of the CLP-32 when configured for VPN applications.

Figure 1 CLP-32 Block Diagram

The major features to the CLP-32 include:

• Scatter/gather DMA across an AMBA/AHB bus
• Sequencing of cryptographic operations such as encryption and message authentication
• Build time configurable cipher and hash suites
• Build time configuration of the size of the cipher and hash key buffers
• Configuration and control through a separate AMBA/AHB slave port
• Optional NVM port for Root of Trust key

Scatter/gather DMA is an important feature for networking applications where packet fragmentation occurs as traffic traverses a network. Scatter/gather DMA allows the CLP-32 engine to seamlessly integrate with a software architecture implemented through a linked list of packet fragments in memory which are passed to the engine. The DMA master sequentially gathers then processes the entire packet through the engine's internal memory for the required operation such as an AES encryption and HMAC/SHA-1 hash required for IPsec. With those operations complete, the engine can then DMA the resulting (and now bigger packet) back into system memory again as a single packet or scatter back into a new linked list. This is a great simplification of the overall system design for VPN processing and applies equally well to IPsec, SRTP and SSL/TLS.

Sequencing is also a significant feature of the CLP-32. The engine facilitates the sequential operation of a crypto and hash operation on the same data as required for packet processing but also permits simultaneous operation of the cipher and hash cores to optimize the use of the engines in the core. This mode of operations dramatically reduces bus utilization and optimizes overall engine performance.

Table 2 outlines the diversity of cipher/hash algorithms currently supported in the CLP-32 and where they might be used.

When configured for DRM or for a combination of VPN and DRM applications, the engine can be configured to add a 'root-of-trust' NVM port on the AES core. Customers have built their root-of-trust keys in technologies such as fuses, eFuses, OTP, MTP and even RTL. The choice of NVM impacts the flexibility and the robustness of the security architecture. Elliptic can offer guidance as to which option to select and the impact of the choice in terms of vulnerability and suitable for a specific target market.

Ellipsys Middleware

Our customers increasingly demand an entire systems oriented solution. This has resulted in Elliptic investing more in software support for its security engine solutions. Ellipsys has evolved over the last three years to offer a complete stand-along security software solution combined with the ability to substitute hardware offload engines to substitute for software when the engines are available in silicon. The Ellipsys architecture is shown in Figure 2.

Figure 2 Ellipsys Middleware Block Diagram

Initially customers used Ellipsys as a lab verification vehicle as it offered the software team the ability to get started early in a project - even before the hardware was available. When FPGA emulation or silicon is available the hardware offload cores can quickly be substituted for software and verification quickly concluded.

Increasingly, customers are now using Ellipsys as a complete software solution for their overall product design. As Ellipsys is offered in source code form, customers can build and integrate a run-time image into their reference design and can sublicense it to their end users. This allows customers to focus their resources on the value add they offer to their target market and rely completely on a fully-verified, NIST validated security software solution from Elliptic.

Ranked by Gartner as the fastest growing security IP provider, Elliptic can help guide your next project to conclusion with well proven, fully verified software and hardware IP solutions. Elliptic has the unique position that it can do hardware and software security designs, completely understands the trade-offs in performance between the two and therefore can offer a unique system optimized solution to customers. We look forward to working with your team on your next security project.

Search for Elliptic IP here

About the Author

Richard has more than 27 years of experience in technology companies. Richard was a former CEO of Solidum and Accelerix and acted as a contract CEO to Intelligent Photonics Control and Spectalis. He has provided consultant services to a number of technology companies including Seaway Networks, Wavesat and Ad Opt. Richard started his career as a semiconductor engineer during the early days of Mitel. He has also worked at NovAtel Communications, Extreme Packet Devices and Enhance Systems in a variety of senior management roles. He holds a B. Eng Electrical Engineering from Carleton and an Executive MBA (PMD60) from Harvard.