Verifying Security Aspects of SoC Designs with Jasper App

Ziyad Hanna, PhD

Vice President of R&D
Jasper Israel General Manager
ziyad.hanna@jasper-da.com

Victor Markus Purri

Jasper Applications Engineer
victor@jasper-da.com

Jasper® Design Automation

April 2013
Abstract— This paper presents Jasper technology and methodology to verify the robustness of
secure data access and the absence of functional paths touching secure areas of a design.
Recently, we have seen an increasing demand in industrial hardware design to verify security
information. Complex system-on-chips, such as those for cell phones, game consoles, and
servers contain secure information. And it is likely that the presence of this information makes
providers vulnerable to unauthorized access to secure data. The potential business loss, direct
and indirect, is large, and verifying whether the secure information can be leaked is hard to
achieve with conventional RTL validation methods. The security requirements are not easily
expressible by regular SVA assertions; therefore, it is not practical to achieve validation with
standard formal verification tools. Jasper’s Security Path Verification App (SPV) is part of a wide
spectrum of apps we provide for design and verification domains. SPV provides a comprehensive
solution to the security path verification problem. With SPV, it is convenient to specify the security
paths and perform an exhaustive verification based on our special path sensitization technology,
automatic connectivity abstraction, path divide-and-conquer search, and by leveraging the
comprehensive core formal engines and usability features of the JasperGold platform. Jasper
security path verification has been successfully used by various customers in the SoC domain,
confirming the impact of Jasper’s solution and technology roadmap.

Keywords— (Formal Verification, Security Verification, Hardware and Software SoC Design,
Model Checking, Formal Specification Languages)

Introduction
The role of formal technology in the overall SoC design and verification flow has grown
significantly. To address this growth, Jasper has developed various apps that provide a wide
range of solutions for emerging problems in design and verification. These apps include solutions
for architectural modeling and verification, RTL development and block/system verification, SoC
integration, and post-silicon debugging [1]. Today, a variety of engineering groups, such as
architects, RTL designers, validation engineers, and silicon debugging experts use solutions
based on formal technologies. The higher quality of verification results and the improved
productivity that formal verification methods bring have made it a common methodology to apply in
all aspects of design and validation flows. The scope of Jasper formal technology has expanded to
address security verification as well, which we explain in detail in this paper.

Data security is of growing importance today as system architects are being asked to challenge
existing security practices in their systems. For example, as data centers become increasingly
virtualized, high value or highly sensitive workloads from different lines of business will be shared
across common physical infrastructures. Physical isolation of the systems is not applicable
anymore because of the emerging growth in cloud computing and shared hardware and software
resources.

Hardware companies such as Intel and ARM have introduced comprehensive capabilities and
methodologies to boost their offerings in data security for the growing applications in mobile and
server products. ARM TrustZone® technology is a system-wide approach to security on high-
performance computing platforms for a huge array of applications, including secure payment,
digital rights management (DRM), enterprise, and web-based services [2]. Intel Trusted Execution

©2013 Jasper Design Automation Page 2

Technology (Intel® TXT) provides hardware-based security technologies to help build a solid
foundation for security, addressing the increasing and evolving security threats across physical
and virtual infrastructures [3]. Other SoC companies are doing the same, and they have already
developed similar technologies and methodologies to address the emerging security concern.

Encryption algorithms and techniques for securing data continue to be an active domain of
research in academia and on industrial fronts, and Jasper formal property verification solutions
can check the correctness of such algorithms. However, the big question is where to store such
encrypted data (in the software or the hardware) and how to verify the access control. Recently,
we have seen a trend toward storing security data in hardware in the form of embedded
microcode or software or in actual silicon implementation. The aim is to make it much harder for
attackers to have access to sensitive data. Despite these approaches, we still see successful
attempts to access secure data.

Current methodologies have an ad hoc approach to security verification that is part of IP design,
SoC integration, system validation, and software development. The main method of verification is
through simulation with a focus on trying to enumerate the possible security leakage scenarios
and simulating them. While this method is scalable with simulation capacity, it is not exhaustive,
thus many scenarios are left unchecked, which enables easy pathways for attackers.

Using formal methods is a natural approach to increase the confidence in systems. However, the
major focus we see continues to rely on verifying the correctness of encryption algorithms and
their implementation in software and hardware. In contrast, Jasper security path verification
addresses a specific, important aspect of overall security verification by checking access to the
secure data on the hardware to make certain that attackers cannot breach the authentication logic
and seek the secure data through illegal logic paths.

In a typical SoC design, like the one pictured below [4], we can identify various security anchors,
such as key storage, random number generators, counters and timers, and various security data
storage. The big question is, is it possible to access such sensitive information from outside the
pin interface or external access points to the system? In other words, is it possible to transfer the
security keys from a certain location A to location B through some control C? Answering this
question is the main goal of Jasper SPV App.

©2013 Jasper Design Automation Page 3

Figure 1: ARM Trusted Base System

SoC designs are complex because they normally involve tens of IP blocks, and as a result, many
possible paths cross the IPs at the SoC level. The test logic (for example, scan), can add paths in
the system where secure data can travel. To contain the security verification problem, system
architects isolate secured areas (the red areas in the above drawing), analyze the data flow of the
whole system, and manually try to identify possible paths by observing the structures and adding
blocking conditions. On the other hand, system integration engineers analyze the structural paths
and try to convince themselves that they are false paths. No doubt, this is a tedious and ad hoc
methodology that can work on a small subset of traces, but it is difficult to get a real sense of
completeness.

Security Path Specification

Specifying whether there is a path from location A to location B in the RTL is not straightforward
using standard specification languages such as SVA. Users need to add some glue logic and
many assumptions to constrain the search for such a path. One way to do so is by disconnecting
signal A from its driving logic, constraining it to a stable value A_unique and ensuring that other
sources of data cannot drive the same A_unique, and then checking whether the target signal B
can eventually receive the value A_unique. If so, there is a logical path from signal A to signal B;
otherwise, no functional path exists.

©2013 Jasper Design Automation Page 4

 wire [31:0] A; // Source
wire [31:0] B; // Destination
wire [31:0] A_unique;

// Force A_unique to be stable

assume $stable(A_unique);

// Ensure all "other" sources don’t generate A_unique.

assume (other_source_of_data1 != A_unique)
assume (other_source_of_data2 != A_unique)
...

// Check that the unique value never reaches B

assert (B != A_unique)

Notice that the number of instances of the assumption assume (other_source_of_data1 !=

A_unique) can be large depending on the size of the cone of influence of target signal B. It is
possible to use this approach, but it is clearly not a straightforward method. It requires the user to
add the glue logic and enumerate all the assumptions; therefore, it is error prone. Imagine the
enormity of the task if the user wants to check many paths. That case requires much more logic
and added assumptions. Another important deficiency of this method is that if data mutates (for
example, is inverted or split into smaller chunks) between A and B, this approach will miss a path.

With the Jasper SPV App approach, the user specifies the path property in one simple way:
assert –no_path -from A -to B

Clearly, this is a much simpler method and hides the complexity of the modeling details, so the
user does not need to develop and maintain the model. We extend the semantics of our security
path verification to enable path conditions that force the paths to visit or skip certain locations in
the design.

Checking for a functional path from two points is used in complementary contexts: to know if there
is a path from a non-secure area to a secure area and to know if there is a path from a secure
area to a non-secure area. Illegal paths to the secure area can introduce vulnerabilities in which
non-secure data is mistaken as secure, while illegal paths from the secure area can leak data to
the hackers. With Jasper SPV App, the user can specify the paths and then verify them formally.

©2013 Jasper Design Automation Page 5

Figure 2: Security Path Verification

?
?
? Secure ?
Area

? ?

Illegal overwrite of Illegal leak of

secure data secure data

Security Path Verification Technologies

A simple verification approach is to apply structural analysis to traverse the cone of influence of
the target signal B backwards and determine whether the traversal can reach signal A. If the
traversal does not reach signal A, it is guaranteed that there is no path from A to B, and this is
trivially a false path. However, if the traversal reaches signal A, there may or may not be a
functional path. This depends on the logical behavior of the design and the assumptions involved.
With SPV App, we apply the structural analysis as a simple preprocess method to rule out false
paths.

Simulation is another conventional method used to validate security paths. It is usually based on
inserting x values at the source of the paths and checking whether the destination signals can
receive the x value. This method is not complete because it can show the paths, but it cannot
verify their absence. In addition, simulation methods suffer from x optimism and pessimism, which
can cause generation and suppression of x values during simulation. And as a result, false paths
are detected and true paths are missed.

Applying the standard formal property verification approach may be effective, but it suffers from
multiple issues, which are mentioned in the section “Security Path Specification.” The main issue
is usability, and that is because of the need to add assumptions to force a desired path to be from
a desired point. Another issue is correctness, and that is because paths may be missed in cases
where the data is mutated between source and destination.

Jasper’s approach does not have the limitations and issues of the above methods. It is based on
the “path sensitization” technology we developed specifically for security path verification
problems. It introduces a new type of property with the format assert -no_path -from
A -to B that checks whether there is a functional path from source signal A to destination signal
B. By proving this property, the formal engines inject a unique tag called “taint” on A and check
whether this unique tag can ever appear at B. If the property is formally proven, this means that it
is impossible to expose data from A on B under the current set of constraints. On the other hand, if

©2013 Jasper Design Automation Page 6

the tool is able to make the property fail, a counterexample will show how data from A can be
exposed on B.

Checking assertions such as the ones above on big SoC designs can be a challenging proof
because of the complexity of the preconditions at A and B and the deep levels and complex nature
of the logic. Obviously, it is possible to safely black box some of the modules that are not in the
desired paths; however, if such modules can interfere with the paths, then black boxing is not a
valid approach. To cope with these issues and for scalability reasons, Jasper SPV App adds a
concept of safe connectivity abstraction to make sure that tainted values still propagate in semi-
black-boxed modules.

Figure 3: Safe Connectivity Abstractions Ro

De

Another method used by SPV App to cope with long search paths is divide-and-conquer. With this
approach, the tool searches for a functional path between points A and B by searching for
intermediate relevant points and trying to construct a path through them.

Figure 4: Divide and Conquer Method Ro

De

©2013 Jasper Design Automation Page 7

SPV App is built on the JasperGold platform; therefore, it leverages the platform’s rich modeling,
optimization, proof engines, and debugging features. Powered with these capabilities, the
scalability of SPV App has proven to meet the capacity of emerging SoC designs and systems.

Security Path Verification versus Formal Property Verification

Security path verification is essentially different from the formal property verification approach. In
security verification, we want to check whether there are possible paths outside the normal
specification scope. Basically, we are trying to mimic the hacker approach by breaking the
specification to see if it is possible to leak security data via unexpected paths. On the other hand,
with formal property verification, we want to check whether the property is always correct under
the constraints. That said, in security verification, we sometime want to run in an under-
constrained environment (such as during reset) or without environmental constraints or even with
partial constraints. If we prove that there is no functional path without environmental constraints,
this is a much stronger result compared to a fully constrained environment. The challenge is to
cope with false negatives, which means that since the SPV App is showing a path under a partial
formal setup, have we found a security violation or not? JasperGold debugging capabilities (such
as Visualize, what-if analysis, dynamic constraints, and so forth) help users analyze the results of
the verification to feel confident in the results; that is, be convinced that such a path is legal or not.

Case Study
In this case study, we show how SPV App can be used on a small example design.

©2013 Jasper Design Automation Page 8

Figure 5: Design Used in Case Study Ro
De

SoC
Master 0: Master 1: Master 2:
CPU0 CPU1 Key Mgr
ready

Interconnect
Firewall

Slave 0: Slave 1: Slave 2: Slave 3: Slave 4:

ROM Encrypt Decrypt Peripheral RAM
Interface Bridge Interface

ROM External
Peripherals
RAM

The masters of this network are the CPUs and a “Key Manager.” The role of the Key Manager is
to read encryption/decryption keys from the ROM and transport them to specific cryptographic
slaves, which are in charge of encryption/decryption operations. After completing this process, the
FSM inside Key Manager moves to a “ready” state, which unblocks some communication
channels in the firewall through a side channel.

This network has several security requirements. Some are functional requirements that deal with
the proper operation of Key Manager, firewall, and ROM interface. These can be described in SVA
or PSL and are a good fit for JasperGold Formal Property Verification (FPV) App.

However, a network such as this one also has data propagation and control propagation
requirements that specify which resources are visible (that is, accessible) by agents in this system
under a specific configuration. As explained earlier in this paper, those are not fit for SVA or PSL
properties, but they are a good fit for JasperGold SPV App.

Usually, these propagation requirements can be divided into “leak” and “illegal overwrite” checks.
We will focus on five requirements, which we expect will cover different areas where the tool can
be applied.

©2013 Jasper Design Automation Page 9

1. No security leak: Secure data/control should never reach non-secure areas
1.1. Keys should never reach CPUs without going through encryption logic
1.2. Key Manager FSM state should never reach CPUs
2. No illegal overwrite: Non-secure data/control should never reach secure areas
2.1. Slave’s copy of key should never be overwritten by CPUs
2.2. Slave’s copy of key should not come from non-secure ROM locations
2.3. Slave’s key control information should never be affected by CPUs

The above requirements will be verified by assert –no_path properties (described above).
SPV App creates the properties when you use the command check_spv –create.

The following section shows the first check. The explanation of the other checks and further
details about Jasper security verification technology can be found on the Jasper website.

No Security Leak Check

We want to check that keys should never reach the CPUs without going through encryption logic.
Here we tell the tool to find a path between the ROM interface and CPUs that does not go through
encryption/decryption logic. To ignore paths going through the cryptographic logic, we use the
command stopat, which disconnects the logic driving the signal:
% stopat s1_encrypt.cypher_data ;# Disconnect encryption logic
% stopat s2_decrypt.cypher_data ;# Disconnect decryption logic

Now, we can create the main properties that will look for a path between the ROM and the CPU:
% check_spv -create \
-name leak:KEY_to_CPU0 \
-from rom_data -from_precond {rom_read && (rom_addr == `KEY_ENC || rom_addr == `KEY_DEC)} \
-to m0_cpu.M_rdata -to_precond m0_cpu.M_req

% check_spv -create \
-name leak:KEY_to_CPU1 \
-from rom_data -from_precond {rom_read && (rom_addr == `KEY_ENC || rom_addr == `KEY_DEC)} \
-to m1_cpu.M_rdata -to_precond m1_cpu.M_req

Notice how the assertions are qualified with the switches –from_precond and –to_precond.
We use the switch –from_precond to direct the tool to search only for paths coming from
rom_data when an encryption key is being read from the ROM. As for –to_precond, we use it
to restrict the search for scenarios in which tainted data gets to the CPU when it is requesting
data. When proving the assertions, the tool finds a bug related to a write operation being done to
the ROM.

©2013 Jasper Design Automation Page 10

Figure 6: Encryption Key Leakage Ro
De

This counterexample shows how a piece of an encryption key (red highlights) can get from the
ROM to the CPU. In this scenario, the CPU posts a write request to the ROM (orange highlights),
which generates an error response (signal S_err/M_err asserted). However, the data
associated with this response is the one from the previous read operation done to the ROM. The
previous read operation (green highlights) is to read an encryption key, which was initiated by the
Key Manager. Therefore, the data associated with the error response going to the CPU is also a
piece of the encryption key, and that is a security hole.

Summary

Jasper SPV App is an essential solution to address the emerging needs for verifying security
holes in chip designs. This app is powered by unique specification, modeling, verification, and
debugging capabilities to make it an applicable and scalable solution for a large spectrum of
hardware designs, including IP blocks, CPUs, and large SoC designs. Jasper SPV App has been i
widely used by various Jasper customers, confirming the power of this app and its promising
technology roadmap. This article provided a quick overview of the Jasper security path verification
concepts and demonstrated how the solution works on a small case study. A more in-depth article
can be found on the Jasper website, www.jasper-da.com.

©2013 Jasper Design Automation Page 11

References

[1] John Goodenough. Jasper Formal Verification at ARM. DVCON 2011. http://www10.edacafe.com/video/ARM-
Jasper-Formal-Verification-ARM-brJohn-Goodenough/34449/media.html.
[2] ARM-TrustZone http://www.arm.com/products/processors/technologies/trustzone.php
[3] Intel Trusted Execution Technooogy: White paper. http://www.intel.com/content/www/us/en/trusted-execution-
technology/trusted-execution-technology-security-paper.html
[4] Securing the System with TrustZone Ready Program, ARM.
http://www.arm.com/files/pdf/Tech_seminar_TrustZone_v7_PUBLIC.pdf
Trademarks

Jasper Design Automation, the Jasper Design Automation logo, JasperGold, and
Visualize are trademarks of Jasper Design Automation, Inc.

All other trademarks or registered trademarks are the property of their respective
owners.

Jasper Design Automation, Inc.

707 California St.
Mountain View, CA 94041
Direct: (650) 966-0200
http://www.jasper-da.com

©2013 Jasper Design Automation Page 13