Hardware/Software IP protection - CiteSeerX

6 downloads 29492 Views 48KB Size Report
by embedding a digital signature into IP components. ... carries his/her unique signature. .... to buy from the provider instance-specific simulation/estimation.
Hardware/Software IP protection Marcello Dalpasso

Alessandro Bogliolo

Luca Benini

DEI – University of Padova Via Gradenigo 6A 35131 Padova, Italy

DI – University of Ferrara Via Saragat 1 44100 Ferrara, Italy

DEIS – University of Bologna Viale Risorgimento 2 40136 Bologna, Italy

[email protected]

[email protected]

[email protected]

ABSTRACT Design methodologies based on reuse of intellectual property (IP) components critically depend on techniques to protect IP ownership. IP protection is particularly challenging for hardware/software systems, where an IP core runs embedded software: both the software and the core are valuable IP that must be protected. We propose a new technique for protecting the IP of both processor cores and application software in hardware/software systems. Our approach is based on public-key cryptography and it has been implemented as a package in the JavaCAD distributed design and simulation environment [1].

1.

INTRODUCTION

Effective re-use is a pillar of large-scale system design. By re-using components of existing designs, it will be possible to build extremely large systems in short time [2; 3; 4]. Re-usable blocks can either be taken from internal libraries or purchased from third parties. In the latter case, re-usable blocks are often called intellectualproperty components (IPs, for brevity). To be fully successful, any IP-based design flow must address two major challenges. First, it must provide techniques for assessing correctness and quality (area, speed, power, testability) of designs containing IP components. Additionally, it must guarantee intellectual property protection for both the IP provider and the designer. These two challenges are subtly intertwined together. If the IP component is fully disclosed to the user, validation of a design containing the component is not much harder, in principle, than validation of a fully proprietary system. Unfortunately, full IP disclosure is almost never granted: in doing so, the provider would give up the full value of his investment. On the other hand, IP users do not want to fully disclose the content of their designs to IP providers. Hence, none of the two involved parties fully owns the information needed to carry out complete system validation. A new generation of “IP-aware” design tools for supporting IPhttp://www.javacad.eu.org/

based design methodologies is under development [1; 5; 6]. The main challenge for these tools is to enable design validation without compromising intellectual property [7]. A few approaches focus on IP-provider protection. Watermarking [8; 9] protects the provider by embedding a digital signature into IP components. If the digital signature cannot be removed, in case of litigation the provider can prove in court that the component illegaly employed by the user carries his/her unique signature. The main limitation of watermarking is that it protects the provider only from illegal instantiation of the component, but it does not hide its intellectual property. An alternative technique for protecting the provider is based on model encryption [10; 11]. In this case, the provider releases an accurate simulation model to the user, but protects his/her intellectual property by encrypting it. The encrypted simulation model can then be instantiated and simulated within the user’s design. The encrypted model is provided to the designer as a pre-compiled object file to be linked to the simulator and run on the designer’s machine. Using an object code gives rise to two main issues. First, the object code is not portable: the provider needs to prepare a different version of the encrypted model for each target architecture. Second, the designer must trust the object code to run it on his/her own machine. Furthermore, model encryption only protects hardware description language (HDL) descriptions of IP components. Another approach to IP protection is taken in the JavaCAD framework [1; 12]. JavaCAD is a distributed environment where IP users are clients and IP providers are servers. The IP user creates a design by instantiating and connecting modules. Some modules are locally available, while others are remote. IP-critical information about the remote module never leaves the provider. Non-critical information can be enclosed into standard methods which are run on the user’s virtual machine to improve performance. JavaCAD has several unique features. First, it does not specify which methods in a remote module should be remote: each provider can independently decide the degree of protection he/she needs. Second, it protects the user as well, because a remote module does not have any visibility on the structure of the design beyond its boundary. Finally, it is fully distributed. Providers and users can be physically remote, and can securely communicate over the Internet. All IP protection techniques presented so far are focused primarily on hardware design. However, most large-scale systems contain hardware and software. The most successful IP components in the market today are mega-cells that include one or more processors [13; 14]. In this paper we focus on the unique challenges that arise when designing a mixed hardware/software system where the core processor running the software is an IP component provided by a third party. While protection of the hardware core is still a fundamental requirement, software is often the most valuable intel-

Permission to make digital/hardcopy of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. DAC 2000, Los Angeles, California (c) 2000 ACM 1 -58113-188-7/00/0006..$5.00

in

algorithm

StrGen

binary code

I/O

M

pub

K prov uP

RndStr

Encrypt

Cmp

workload

workload

compiler

S des eRndStr dRndStr

a)

b)

Figure 1: a) RTL design with a virtual component. b) Architectural-level design with a virtual microprocessor core.

en

F

out

DecryptC seRndStr dRndStr

Designer Provider

priv

lectual property for system designers. Hence, we need to guarantee protection of the software developed by the user. This task cannot be accomplished by any of the previously described approaches.

2.

HW/SW IP PROTECTION

Fig. 1.a shows a generic RTL design with a virtual component (in gray). IP protection is represented as a barrier (the bold dashed line) between the component, that is a provider’s intellectual property, and the rest of the design, that belongs to the designer. Both the designer and the provider cannot look beyond the barrier, or otherwise they would violate the other party’s intellectual property. If instance-dependent cost metrics, depending both on the highlevel structure and working conditions of the design and on the inplementation details of its components, have to be evaluated, both the designer and the provider need to be involved. According to the virtual simulation paradigm of JavaCAD [1; 12], the involvement of an IP provider in a simulation/estimation task is conceived as a service supplied by the provider. In a distributed, event-driven simulation framework, the designer starts a simulation session by applying a workload at the primary inputs of the design. If accurate low-level estimates are required, the providers of the virtual components instantiated within the design are asked to perform simulation sub-tasks on their own machines. This is done by exploiting the remote method invocation protocol (RMI) of Java [15]. Remote methods for cost-metric estimation are implemented by the provider and made available within the specification of each IP component. In virtual simulation, provider’s IP and designer’s IP are kept and used in different locations and never sent across the Internet. The Internet is made impermeable to IP-critical information in order to realize the dashed barrier of Fig. 1.a. The basic assumption of virtual simulation is that functional events at the boundaries of IPprotected macros do not carry any intellectual property, so that they can be sent to the providers. Unfortunately, in general this assumption does not hold for programmable virtual components. Fig. 1.b shows a schematic representation of a design containing a virtual microprocessor core (uP), a memory hierarchy (M) and some input/output devices (I/O) connected by the system bus. The design functionality is determined by the algorithm executed on the core. Before execution, the algorithm needs to be mapped into the instruction set of the core (i.e., compiled) and loaded in memory. The external workload is applied through the input/output devices. Even if we assume the workload is not IP-critical, several new issues are rised by the presence of a programmable unit: (i)

K prov

DecryptS

Figure 2: Hardware/software IP protection.

the algorithm is a designer’s intellectual property; (ii) the core is a provider’s intellectual property; (iii) the compiler belongs to the provider and may contain IP-critical information about the architecture of the target core; (iv) the executable code represents the algorithm, so that it contains designer’s IP-critical information. Both the core and the compiler are enclosed within the dashed line that represents IP-protection. According to the virtual simulation paradigm, compilation and structural simulation could be viewed as remote services made available by the provider before IP disclosure. However, the compiler inputs the source code of the algorithm, while the core simulator needs visibility of the compiled code. Hence, virtual simulation would require IP-critical information to be sent across the Internet and disclosed to the provider.

2.1 The proposed solution The compiler and low-level simulator of the processor core of Fig. 1.b are IP-protected executable modules, belonging to the provider. They operate on IP-protected data, the source and binary code of the algorithm, belonging to the designer. Virtual simulation is not applicable since modules and data cannot be kept in separate places. On the other hand, we want to extend to programmable IP cores the key feature of virtual simulation, i.e., the possibility for the designer to buy from the provider instance-specific simulation/estimation runs before IP purchase. To this purpose we propose a new approach based on encapsulation and encryption, as illustrated in Fig. 2. The executable module that carries the provider’s intellectual property is represented by block F. It could be either the compiler or the uP of Fig. 1.b. In an unprotected enviroment, the module would be directly executed by the designer to process input data (in) and provide output results (out). In the proposed environment, the module is enclosed within a shaded box that provides IP protection by inhibiting the direct execution of the module, while exhibiting the same external interface and I/O behavior. We call wrapped module the entire shaded block of Figure 2. Wrapped modules can be freely delivered by the providers, or freely downloaded by the users from the providers’ Web sites. The designer instantiates and uses wrapped modules within the JavaCAD environment as if they were unwrapped. However, whenever he/she attempts to execute the module to process new input data, the wrapper verifies whether or

not the execution is authorized by the provider and actually enables the inner IP module to run only if authorization has been granted. The run-time authorization mechanism works as follows. 

1. A session string (RndStr) is randomly generated by the StrGen block in the IP wrapper. 2. The session string is encrypted by means of an asymmetric cipher algorithm (e.g., RSA [16]) using the public key of the pub provider (Kprov ). 3. The encrypted string (eRndStr) is passed by an RMI call to the authorization server (DecryptS) running on the provider’s machine. 4. The authorization server decrypts the session string using the priv private key of the provider (Kprov ) and decides whether or not the IP-protected module can be executed on the designer’s machine. Authorization (if granted) is notified by sending the decrypted string dRndStr back to the designer. 5. The decrypted string is received by the IP wrapper and compared with the original session string RndStr. If they match, the inner module F is executed and the results made available to the designer. As shown in Figure 2, the wrapped module does not directly communicate with the authorization server. Rather, a decryption client (DecryptC) external to the IP wrapper is used to this purpose. The reason for putting an additional module between the IP wrapper and the authorization server is twofold. First, the decryption client adds the designer’s signature to the encrypted session string, thus allowing the provider to identify the designer and possibly charge him/her for the execution of the IP module. Second, the decryption client verifies that nothing but the session string is passed to the provider by monitoring the size of transmitted data. The run-time authorization paradigm described above provides a unique solution to the main security issues involved in mutual IPprotection of hardware/software systems. The fundamental property of public-key cryptography guarantees that eRndStr can be successfully decrypted only by the provider. Even if the designer audits the data exchanged over the RMI protocol, he/she cannot extract any useful information; in fact, recording dRndStr and providing it again to the wrapped module to get a “free” authorization does not work, since the black box generates a fresh RndStr each time, and the comparison would fail. In addition, recording and analyzing eRndStr over time would not be of any help in attacking the cipher algorithm, since such a resistance is one of the fulfilled requirements of public-key ciphering. The wrapped IP module executes on the designer’s machine. Hence, inputs and outputs data (usually carrying designer’s IP) are not sent through the Internet nor disclosed to the provider. The wrapped module runs on the secured Java virtual machine: hence, it cannot attack the designer’s machine and does not communicate directly with the provider, so that it cannot steal sensitive information from the designer’s site. Designer’s signature enables user identification and accounting, thus granting to the provider complete control on the diffusion of the wrapped modules. A few additional features of the proposed approach are worth mentioning. First, the byte-code of the wrapped modules is portable. Second, the run-time authorization protocol does not impose significant performance penalties. Finally, both the IP wrapper (that generates and encrypts the random session strings) and the corresponding authorization server (that decrypts the session strings) are Java classes developed by the IP provider. On the other hand, the

session string protects the provider’s IP, while the designer’s IP is inherently protected since it never leaves the designer’s machine. These observations have two main consequences: i) is up to the provider to implement ad hoc encryption/decryption algorithms to protect his/her own intellectual property, ii) the designer does not need to trust (nor to know) the encryption strategy chosen by the provider. Though public-key cryptography described above provides a viable solution, symmetric keys could also be used in this context.

3. IMPLEMENTATION IN JAVACAD The proposed hardware/software IP-protection paradigm has been implemented in a package added to the set of JavaCAD Foundation Packages (JFP, [1]) and called javacad.authorize . This package contains the classes needed for both the client- and the server-side implementation of the protection scheme, and very few lines of code are needed for the provider to wrap the IP-protected tool. In particular, something must be wrapped around the tool to deliver it to the designer (and it is called client-side implementation), and an authorization server must be setup and run on the provider’s Web site (the server-side implementation). For the sake of conciseness, the functionality provided by the (optional) DecryptC block in Fig. 2 is not shown here.

3.1 Client-side implementation The client-side implementation (i.e., the Java code that runs on the designer’s JavaCAD simulation engine) is used by the provider of an IP-protected tool to modify the tool before delivering it to the designer. The implementation relies on the AuthClient class, that basically implements the functionality outlined within the gray box in Fig. 2. As a consequence of the encapsulation, the designer must instantiate an AuthClient object whenever an instance of the tool must be executed, and input/output parameter passing between the design and the tool is handled and masqueraded by the wrapper. For instance, if the actual tool invocation (in the absence of protection) would have been as follows: Tool tool = new Tool(); tool.setIn(input objects); tool.run(); output object = tool.getOut(); then it must be: AuthClient client = new ProviderAuthClient(); client.setIn(input object); client.run(); output object = client.getOut(); The skeleton of the AuthClient class is: package javacad.authorize; import javacad.*; public abstract class AuthClient extends JavaCADAuth private Object toolIn, toolOut; protected PublicKey provPubKey; public void run() throws NotAuthException,RemoteException byte[ ] rndStr = new random string; 



byte[ ] encrStr = encrypt(rndStr,provPubKey); AuthServer provider = getServer(prov name); byte[ ] decrStr = provider.decrypt(encrStr); if (Arrays.equals(rndStr,decrStr)) toolOut = invokeTool(toolIn); else throw new NotAuthException();

Again, the super-class JavaCADAuth provides: 

Hence, the provider must write the ProviderAuthServer:





byte[ ] decrypt(byte[ ] data,PrivateKey key), that returns the decrypted form of data using the given key.



public void setIn(Object in) toolIn = in; public Object getOut() return toolOut; protected abstract Object invokeTool(Object in); 

package provider.tool.server; import javacad.*; public class ProviderAuthServer extends AuthServerImpl









Some services are provided by the super-class JavaCADAuth; in particular, it implements: 



byte[ ] encrypt(byte[ ] data,PublicKey key), that returns the encrypted form of data using the given key; AuthServer getServer(provider name), that returns a handler to the server-side implementation of the protocol, as selected by a provider’s identifier; such a handler allows the client-side protocol to issue remote method invocations by means of the underlying RMI (Remote Method Invocation) Java protocol.

When the provider has coded and thoroughly tested his/her IP protected (stand-alone) tool, he/she must write the ProviderAuthClient class as follows: package provider.tool.client; import provider.tool.*; import javacad.*; public class ProviderAuthClient extends AuthClient public ProviderAuthClient() provPubKey = pub key; protected Object invokeTool(Object in) Tool tool = new Tool(); tool.setIn(in); tool.run(); return tool.getOut(); 









where Tool is the IP-protected tool in package provider.tool . Now, the provider can build a JAR (Java ARchive) file with all the classes (.class files) that are needed to run the tool on the designer’s JVM (Java Virtual Machine), and deliver it to the designer.

3.2 Server-side implementation The implementation of the server-side authorization protocol is quite simple, since one method only must be exported by the server via the RMI protocol:

















and activate a JavaCAD authorization server by exporting ProviderAuthServer (the JavaCAD authorization server is implemented in the javacad.authorize package).

4. CONCLUSIONS Intellectual property protection is a requirement for the success of re-use in electronic design. We introduced a bi-directional protection mechanism based on (public-key) cryptography where user and provider are the client and server in a distributed environment. Our approach provides complete protection to the IP hardware and the software that runs on it.

5. REFERENCES



package javacad.authorize; import javacad.*; public interface AuthServer public byte[ ] decrypt(byte[ ] data) throws RemoteException; public class AuthServerImpl extends JavaCADAuth implements AuthServer,Remote protected PrivateKey provPrivKey; public byte[ ] decrypt(byte[ ] data) return decrypt(data,provPrivKey);

public ProviderAuthServer() provPrivateKey = priv key;

[1] M. Dalpasso, et al., “Virtual simulation of distributed IP-based designs,” in DAC, pp. 50–55, 1999. [2] D. Gajski, “IP-based design methodology,” DAC, pp. 43, June 1999. [3] M. Keating, P. Bricaud, Reuse Methodology Manual for System-on-a-Chip Designs. 2nd ed., Kluwer 1999. [4] R. Seepold, A. Kunzmann, eds. Reuse Techniques for VLSI Design. Kluwer 1999. [5] A. Reutter, et al., “An efficient reuse system for digital circuit design,” DATE, pp. 38–43, 1999. [6] P. Chou, et al., “IPCHINOOK: an integrated IP-based design framework for distributed embedded systems,” DAC, pp. 44–49, 1999. [7] J. Lipman, “Protecting IP,” EDN Magazine, pp. 60–65, June 1998. [8] A. Kahng, et al., “Watermarking techniques for intellectual property protection,” DAC, pp. 776–781, 1998. [9] A. Caldwell, et al., “Effective iterative techniques for fingerprinting design IP,” DAC, pp. 843–848, 1999. [10] Synopsys Inc., Verilog Model Compiler datasheet, 1999, http://www.synopsys.com/products/lm/ip/vmc ds.html [11] Topdown Inc., TopProtect datasheet, 1999, http://www.topdown.com/topprotect/tp dsheet.htm [12] M. Dalpasso, et al., “Specification and validation of distributed IP-based designs with JavaCAD,” in DATE, pp. 684–688, 1999. [13] S. Segars, et al., “Embedded Control Problems, Thumb and the ARM7TDMI,” IEEE Micro, vol. 15, no. 5, pp. 22–30, 1995. [14] J. O’Connor, et al., “PicoJava-I: the Java virtual machine in hardware,” IEEE Micro, vol. 17, no. 2, pp. 45–53, 1997. [15] J. Gosling, B. Joy and G. Steele, The Java Language Specification, Addison-Wesley, 1996. [16] http://www.rsa.com