CEO Interview: Jason Oberg of Tortuga Logic

I first met Jason Oberg, CEO and one of the co-founders of Tortuga Logic, several years ago when I was still at Atrenta. At that time Jason and Jonny Valamehr (also a co-founder and the COO) were looking for partners. The timing wasn’t right, but we’ve stayed in touch, for my part because their area of focus (security) is hot and likely to remain hot.

Jason has a PhD in hardware security from UCSD around timing side-channels, supervised by Ryan Kastner. Jonny is also a PhD in hardware security, from UCSB supervised by Tim Sherwood. They formed the company in the summer of 2014, funded by an NSF grant and a small business innovation research (SBIR) grant. They started in an incubator in San Diego and have now branched out, moving their head office to San Jose where we met for this interview:

What does Tortuga Logic do?
Everything related to securing hardware, which needs to cover a lot of security approaches, from the hardware/software boundary, through secure boot, to protection of privileged assets, resources and more. We believe strongly in the need for a secure design lifecycle, spanning the design and verification chain and extending even into post-silicon. Of course there are a number of security offerings today, from IP to formal-based tools, each of which have important roles to play, but on their own these are insufficient to provide a high assurance of system security. Our role is to complement these as I’ll explain shortly.

Incidentally, Tortuga doesn’t currently look at physical security concerns, such as power side-channels, PUFs and TRNG validation.

We have seen a lot of hardware security vulnerabilities recently. What’s your view on why and what are the challenges and opportunities in this space?
First let’s get rid of a possible misunderstanding. In big companies at least, this isn’t because designers are careless or don’t know what they are doing; many of these companies have large and very expert security teams. The real issue is that the range of possible problems is effectively unbounded, and therefore practical security, like safety, must be driven by an ROI calculation. What are the reasonably conceivable problems against which you are willing to defend? You have to draw a line somewhere because you can’t imagine all possibilities; even correcting for those you can imagine will have some consequences in cost, performance and power. Like it or not, you’ll have to trade off security in some areas against other objectives

Based on the judgement of your internal experts, you draw that line and make a conscious decision that whatever is on the other side of the line is too difficult to exploit. Over time, exploits become more sophisticated and what was once inconceivable or too difficult to exploit becomes conceivable. This is just the nature of security.

Smaller companies and teams don’t have armies of security experts, so face bigger challenges. First, they don’t have as much expertise in where to draw the line or what might lurk on the other side. And second, while they can and should use proven security IP and tools, those alone do not guarantee their systems will be secure. You can use security features incorrectly just as you can use any other feature incorrectly, and some of those bugs can be quite subtle. So the burden is still on the system designer to verify that their system is secure. Formal plays an important role in validating some integration characteristics but it can’t uncover potential problems in hardware/software interaction for example.

Certainly an opportunity here is to provide metrics and tools to analyze the vulnerabilities of a design, especially to simplify/standardize this task. The ideal is to create a security verification plan and ultimately an audit trail to be able to demonstrate your path to security. You could imagine a goal to demonstrate some standardized level of security in an auditable process, not unlike what we do today for safety. Microsoft has one good example (for software) in their Security Development Lifecycle (SDL) where they do up-front threat-modeling followed by threat model-aware architecture, design and verification.

How are Tortuga Logic’s solutions different from other offerings in this space?
A Tortuga user starts with threat modeling. A very important point to understand is that this doesn’t mean listing known or possible vulnerabilities. It means rather building a description of all the things you want to protect, e.g. assets and keys, along with all the possible ways those assets can be accessed. Think of this as a way to characterize the complete problem space before drilling down to discover and analyze specific vulnerabilities, which is where many system security methods start today. Based on that top-down analysis, Tortuga can then build analytics to assess vulnerabilities, to determine the effectiveness of protection methods against attacks you know about, also to help you understand what you haven’t considered.

The product next takes as input your design files and security rules based on this threat modeling and generates a security monitor model in the form of synthesizable IP which can be inserted in the design. There are several reasons we took this approach. First, this model sits in the existing verification environment, monitoring for potential weaknesses. It requires no change to the verification environment such as testbenches, so adds minimal overhead for the verification team. Because it is synthesizable, it can be run in emulation and FPGA prototyping, which means you can continue to monitor for weaknesses during HW/SW testing. You can even use our models with formal. This is an end-to-end solution across the verification flow.

Who is using your products?
We’re bound by the same constraints as other suppliers, so we’re limited in sharing names. I can tell you that we have been working for some time with government research labs, also large aerospace and defense primes. We have publicly announced a relationship with Xilinx who are working with us on both internal and external security objectives. We are also working with large processor companies exposed to the Meltdown and Spectre problems.

Where can people learn more about Tortuga?
Check out the whitepapers on our website and of course feel free to contact us (we’re very actively staffing up so welcome new engagements). We’ll also be at DAC. We won’t have a booth, but we plan to present at some of the major EDA vendor booths.

Also Read:

CEO Interview: YJ Su of Anaglobe

CEO Interview: Ramy Iskander of Intento Design

CEO Interview: Rene Donkers of Fractal Technologies