User Guide for SIFA v. 1.0

December 11, 2006

Contents

1 Introduction 1

2 Installation 1

3 Philosophy 2

3.1 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.1.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.1.2 Component graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Labelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.4 Instantiation and reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.5 Disabling component hierarchies . . . . . . . . . . . . . . . . . . . . . . . . 63.6 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Editing 7

4.1 Adding graph elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.2 Standard editing operations . . . . . . . . . . . . . . . . . . . . . . . . . . 84.3 Editing component operating modes . . . . . . . . . . . . . . . . . . . . . . 94.4 Instantiating components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.5 Types of components and ports . . . . . . . . . . . . . . . . . . . . . . . . 11

4.5.1 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.5.2 Disabling hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Opening, Saving, and Importing 12

5.1 SIFA XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.2 Converters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.3 Drag and drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Analysis 15

6.1 Topological . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156.1.1 Minimal cut-sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.1.2 Flow analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2 Deep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.2.1 Find all paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.2.2 Consistency analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.3 Evaluation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7 Obscure Features 24

7.1 Component transitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.2 α-Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.3 Command Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

i

8 Con�guration 24

8.1 Colours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258.2 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

9 Bugs 27

10 Legals 27

10.1 JGraph LGPL License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2810.2 JDom v1.0 Apache License . . . . . . . . . . . . . . . . . . . . . . . . . . . 3010.3 SIFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

ii

1 Introduction

SIFA (Secure Information Flow Analyser) uses a view-based approach to reason aboutthe possible vulnerabilities of a system from an information security perspective. SIFA isparticularly useful for the analysis and evaluation of hardware devices, but is generic enoughto support analysis over any interconnected structure of components. This documentprovides a brief introduction to the philosophy behind the tool and gives some guidancefor its use.

Figure 1: SIFA screenshot

2 Installation

SIFA requires the Java 1.5 runtime environment (JRE) to be installed � this can be down-loaded from http://java.sun.com. Additionally, the following �les and libraries arenecessary for the software to run:

sifa.jar SIFA applicationjdom.jar XML parsing libraryjgraph.jar JGraph library

Table 1: Files contained in a SIFA installation

These �les may be placed anywhere, so long as they are all together in a commonfolder or directory. To start the application under Windows, just launch the sifa.jar �le,

1

Figure 2: SIFA upon starting

or under Unix run java -jar sifa.jar. You should be presented with an initial screenas depicted in Figure 2; it is generally a good idea to maximise this window.

It is a good idea when working with large models to increase the amount of operatingmemory available to SIFA by launching Java with the command-line option �-Xmx512m�,where �512m� instructs Java to allocate 512 megabytes of RAM. This can be increased asnecessary, depending upon the amount of RAM available on the system. For example:

java -Xmx512m -jar sifa.jar

3 Philosophy

In essence, SIFA is a just tool that performs searches through graphs. The philosophybehind the program is quite simple: systems can be decomposed into views, and theseviews can be composed to construct systems. What may be surprising about SIFA is justhow many di�erent ways you can create and compose views. Indeed, it is exactly thisaspect of the program that gives it its power. Graphs are used to create views, and thissection will have a look at the way graphs are structured, as well as provide some high-levelinformation regarding general characteristics of the tool.

3.1 Graphs

A graph consists of components, ports, and edges, where a component may have a numberof ports, and ports can be connected together with edges. The relationships between thesegraph elements are illustrated in Figure 3.

The edges that connect the ports together indicate that information may �ow in thedirection that the edge is pointing, from one port to another. The components are thenresponsible for de�ning the connectivity between the ports that they `own'.

2

(a) Component (b) Port (c) Arc

Figure 3: Basic SIFA graph elements

(a)DPDTswitch

(b) 1st mode (c) 2nd mode

Figure 4: A DPDT switch, with two operating modes

3.1.1 Components

Components may represent anything � an electronic gate, an integrated circuit, an entiredevice, computer, or even a person. A component simply de�nes some system of connec-tivity between its ports. However, components di�er from edges because they are capableof being in one of several operating modes. A single operating mode of a component de�nesthe graph, internal to that component, that connects its ports. Because a single componentmay have an arbitrary number of such modes, we are capable of expressing the di�eringbehaviours that relate to alternate operating states of the system being modelled.

For example, Figure 4 shows a double-pole double-throw (DPDT) switch � a commonlyused electronic component. This switch has two normal operating modes, illustrated inthe �gure, that represent when the switch is in each of its possible positions. In SIFA,the di�erent connectivity produced by the alternate positions of the switch are directlycaptured by the component operating modes.

Whilst these modes are considered normal, we may also express modes which are not;for example, modes of connectivity that arise when the component has failed in some way.Accordingly, we refer to these as fault modes, and explicitly identify them as such in SIFA.It is important to distinguish between normal and fault modes so that the likelihood ofthe connectivity can be reasoned about, and we can di�erentiate the normal connectivity

3

(a) 3rd mode (b) 4th mode (c) 5th mode

Figure 5: Some possible fault modes for a DPDT switch

Figure 6: Component graph nesting

of an entire system from the connectivity resulting from one or more component failures.Figure 5 extends our de�nition of the DPDT switch with some fault modes.

3.1.2 Component graphs

A component need not be de�ned as having modes as described above. Instead, a com-ponent can just simply hold another graph. This allows for the nesting of graphs insidecomponents and components inside graphs � thus forming a hierarchy. In this way, theRoot component at the top of the hierarchy (see Figure 2) is a component like any other,except for the fact that it is impossible to remove it (for it has no parent from which tobe removed). When components are added to the Root component graph, these in turnbecome `roots' of their own sub-hierarchy. This recursive structure is an important conceptin SIFA, because all modelling and analysis is performed with respect to a certain `root'in the hierarchy, which may in fact be any component.

Using a component-graph to express the internal connectivity across the componentcan provide a great deal of expressiveness and richness in the component's de�nition. Forexample, the switch in Section 3.1.1 could have been de�ned using two SPDT (single pole,double throw) switches, these switches in turn being de�ned through operating modes(see Figure 6). However, this approach would not capture the functionality of the DPDTswitch synchronising the modes of the sub-switches. Generally, components should bedecomposed into subcomponents only in situations where the subcomponents' operatingmodes are independent from each other.

4

3.2 Labelling

In SIFA it is necessary to give every port, component, and edge in the graph a label. Theselabels not only assist with reading the graph visually, but are signi�cant in the way SIFAinterprets the graph. When two graph elements share a common label, this indicates toSIFA that they are representing the same object. Just what this means di�ers betweencomponents, edges, and ports, and even di�ers depending upon the context in which theyappear. It is always safer to use fresh labels for all graph elements unless the consequencesof reusing a label are well understood.

One important reason for using shared labels is to unify ports across graphs, particularlyover di�erent levels in a hierarchy. Ports with the same label are treated as if they wereone-and-the-same. For example, the port A on the left-hand side of Figure 6 would betreated as the same port as A on the right-hand side (which is nested inside the left-handside component).

The sharing of component labels ties in with libraries, which is discussed in Section 3.6.

3.3 Searching

Across an entire graph, or hierarchy of graphs, we are interested in how certain ports canpossibly connect � particularly the operating modes that each component has to be into enable a path from a particular port to another. To do this we identify sets of portsas sources and sinks, which represent endpoints of paths. SIFA will always start from asource port, and follow the graph until it �nds any sink ports. A port which is identi�edas either being a source or a sink cannot appear in the middle of any paths.

There are two types of searches that identify paths between sources and sinks: topo-logical and deep. These are detailed in Section 6.

When a deep search is performed, the resulting paths are organised by the number ofcomponent points-of-failure necessary for them to exist. This aids in focusing attention onthe most critical or vulnerable parts of the model.

3.4 Instantiation and reuse

Any component de�nition, so long as it appears somewhere within the scope of the analysis,can be reused any number of times in SIFA by creating an instance of it. An instance makesa complete copy of the component in the place where the instance appears, and gives ita new name. So that component instances do not interfere with each other when morethan one instance of the same component is created (the port labels would be the same), anamespace is introduced that pre�xes every port label in the component de�nition beinginstantiated with the instance name. The technicalities of namespacing are discussed inmore detail in Section 4.4.

This feature encourages the use of separate component libraries, where models arecompletely constructed through instantiation. The clear advantage to this approach is that

5

component de�nitions need only be modi�ed once, in the one place, and these changes arepropagated throughout the entire model.

A potential issue with this framework is the need for component de�nitions to be con-tained within the scope of analysis � the component de�nitions must not be incorporatedinto the model, but must still be referenced. To solve this dilemma, SIFA allows for com-ponents to be �agged as �libraries�. Libraries are elaborated upon further in Section 3.6.

3.5 Disabling component hierarchies

The liberal way in which SIFA uni�es graphs through ports encourages a view-based mod-elling approach. In this way, di�erent aspects of the system connectivity can be containedin di�erent graphs. This might be straight-forward hierarchical decomposition, or distin-guishing logical and physical connectivity, or a variety of other possibilities. The analysisof such models often needs to be focused, since all views may not be relevant at all times.Analysis in SIFA is performed by choosing the top-most level of the hierarchy that includeseverything necessary to construct a single uni�ed model (this need not be the absolute top),which makes it di�cult to exclude sub-hierarchies without removing them completely. Tosolve this problem, SIFA allows for entire component hierarchies to be disabled. Thismeans that, even though the hierarchy is in the scope of an analysis, it is ignored. Thiscan be a powerful mechanism for focusing analysis on certain parts or aspects of a system.

3.6 Libraries

In Section 3.4 is was mentioned that a mechanism was required for segregating libraries ofcomponents from the components whose connectivity is to be analysed. This is achievedthrough �agging components/hierarchies as libraries.

Component libraries almost have an inverse semantics from the way graphs are normallyinterpreted in SIFA � there is no label-based uni�cation of ports within a sub-hierarchythat is classi�ed as a library, and there is uni�cation of components that share the samelabel. The reason for the lack of port uni�cation is quite straight-forward: it allows forcomponents to be catalogued in a library without them interfering with each other. It isonly when the components are instantiated in a non-library graph that port uni�cation ispossible, but this is controlled through the instance namespacing mechanism. Whilst thisis convenient, the real power of libraries is provided by the component uni�cation process.

A component can be thought of as a system of connectivity between a number of ports,whether the component is described through operating modes, or as a graph of othercomponents and instances. When two components share the same label, the de�nitions ofthe components presents a choice to the analysis: all de�nitions are considered, but onlyone at a time.

Having multiple component de�nitions allows for the creation of views over componentsthat re�ect di�erent classes of operating modes. These views can then be disabled todisregard entire behaviours, allowing for very tight control over the analysis. For example,the DPDT switch in Figure 4(a) may be de�ned in two views (libraries) which both include

6

the normal modes (Figure 4(b) and 4(c)), but one described faults arising from solderbridges across adjacent pins (Figure 5(a)), and one described faults that occur internal tothe switching mechanism (Figure 5(b) and 5(c)). It is then possible to, upon inspecting thecircuit board to verify that there are no solder bridges, disable the library that containedthose fault modes. This is a good way to introduce assumptions or known informationinto an analysis in order to reduce the number of false positives. Multiple de�nitions arealso potentially useful for capturing di�erent operating environments that have slightlydi�erent fault pro�les, or for dealing with alternate component manufacturers, etc.

It is important to note that instantiation can be used within libraries to assist thecreation of complex de�nitions for components. The only restriction is that there mustbe no circular de�nitions, i.e. a component must not be instantiated anywhere that ishierarchically underneath itself. SIFA will provide a warning whenever a model is `deeply'analysed (see Section 6.2) if the model contains any circular de�nitions.

4 Editing

This section provides some practical insight for creating and analysing models in SIFA.

4.1 Adding graph elements

To add a component, �rst make sure a window is showing and active. This can be doneinitially by right-clicking on Root in the component tree explorer on left-hand pane ofthe desktop (see Figure 2) and choosing �Show�. Inside the component window, eitherclick the add-component icon (the blue one), or right-click on a blank part of the blockdiagram and select �Insert Component�. A component will appear in the block diagrameditor which can be moved, resized, and renamed.

Figure 7: A component

The component is given a default name to begin with, but can be renamed by eitherdouble-clicking on the component, or right-clicking on the component and selecting �Re-name�. Enter, or clicking elsewhere, commits the new name to the component.

Ports may be added to components by right-clicking on the component and selecting �Addport�.

7

Figure 8: A port

The name of any port may be altered in the same way that labels are changed forcomponents.

Ports are connected by clicking on the center of a source port and dragging a line to attachto a destination port (see Figure 9): this creates an edge1. The directionality of the newedge is dependent upon the edge mode, which can be toggled by clicking on the button:

Signi�es that a unidirectional edge will be added.Signi�es that a bidirectional edge will be added.

Figure 9: Connecting ports with an edge

Ports cannot be connected while the editor is in grasp mode (indicated by the blue handicon ). Grasp mode is useful for moving components around without accidentally editingthe model. To exit grasp mode and enter connect mode , click on this icon.

4.2 Standard editing operations

Components, edges, and ports can be deleted from a graph by selecting them and eitherclicking on the trashcan icon in the toolbar, or pressing the delete key. Similarly, otherstandard editing operations, like cut , copy , and paste , follow established conventions� notably, the keyboard shortcuts Ctrl-X, Ctrl-C, and Ctrl-V are supported.

If a graph element is removed it takes with it the other graph elements that dependupon it. For example, removing a port will remove any edges that connect to or from it,removing a component will remove all subcomponents, etc. However, the blue dashed linethat connects ports to their parent components indicates the ownership relationship, andthis behaves slightly di�erently. If a component is removed but its ports are not, then theseports will become orphaned. Orphaned ports are identi�able by their grey background �

1Sometimes edges are referred to as arcs.

8

Figure 10: Empty operation mode table

such ports must be either re-parented by clicking on the center of the port and draggingthe mouse into a component, or removed. If an orphan port exists on a graph, the portwill not be saved with the rest of the graph (orphaned ports are strictly transient).

4.3 Editing component operating modes

Whenever a component is added to a graph, it creates another level in the hierarchy,which can be seen in the component tree explorer on left-hand pane of the desktop. Thesecomponent windows may then be opened in exactly the same way that the Root windowwas opened, revealing a new graph canvas. Either a new graph may be placed there or thecomponent can be populated with operating modes, by selecting the appropriate tab fromthe top of the component window. Note that it is possible to both populate a componentwith a graph, and also de�ne operating modes over that same component � the componentwill express both forms of connectivity during analysis.

When the Modes tab is selected, a table is presented that lists the ports owned by thecomponent in the parent graph, and the ports that appear in the component's own graph.This will initially be empty, as illustrated in Figure 10. This �gure shows a component�Diode� that owns two ports: a and k. Assume we wish to model the �ow of electricalcurrent, where the diode normally conducts from a to k (anode to cathode) but not in thereverse direction, unless there is a �breakdown�, in which case the diode conducts currentin both directions.

The rows in the table represent inputs, and the columns represent outputs, such thatadding an entry in row a and column k represents a connection from a to k. The cell ispopulated with the operating modes for which that connection is active. To the right ofthe table is the operation mode editor, where the operating modes are added. To add anew mode, type a one word abbreviation in the Abbreviation �eld, and a more meaningfuldescription of the mode in the Description �eld. Select whether the mode is normal or afault, and then click Add. It is possible to associate a probability with a fault by enteringthe likelihood as a percentage in the Probability (%) �eld. The right-hand side of Figure 11shows two modes for the diode: normal, and breakdown. Note that any mode may be editedafter it has been added by selecting the mode from the list of available modes, changingits properties in the editor, and then clicking Edit.

9

Figure 11: Full operation mode table

In this case, the operating mode table2 is populated like so:

a k

a normal normalbreakdown breakdown

k breakdown normal

breakdown

The cells that form the identity of the matrix (italicised) always contain every possibleoperation mode, because a port is always connected to itself. These cells are not able tobe edited in SIFA: only the cells that describe connectivity between di�erent ports can bemanually populated.

To edit a cell, simply left-click on it. The Mode Set Editor (see Figure 12) will appearwith every available operating mode for the component listed on the right-hand side. Thechosen modes for the contents of the cell are listed on the left-hand side. Adding andremoving operation modes from the cell is achieved with the arrow buttons separatingthe two lists: these buttons will move the selected item from one list to the other in thedirection that the arrow is pointing. Moving an entry from right to left populates the cellwith that operation mode � a single cell (connection) may be associated with an arbitrarynumber of operation modes.

4.4 Instantiating components

Component de�nitions, like the diode above, need only be created once. It is then possibleto use instances of the component to reuse the de�nition in other parts of the model.Figure 13 shows the diode together with two instances: diode1, and diode2. All three

2The operating mode table is often referred to as the matrix.

10

Figure 12: Mode set editor

`components' behave in the same way, but derive their de�nition from Diode, and mapdi�erent ports together.

When any component is instantiated (and any component may be), for all intents andpurposes a straight copy of the component is created. However, all of the port labels inthe component's de�nition are pre�xed with the name of the instance and two colons (�::�).In Figure 13 for example, to create a port to represent a in diode1 it was necessary to usethe label diode1::a, and similarly for k with diode1::k.

This namespacing technique continues recursively. Assume we create a component�Recti�er�, which is de�ned by connecting four Diode instances: diode1, diode2, diode3,and diode4 together. If we then instantiate Recti�er with an instance named rect, wewould use port labels like rect::diode1::a, etc. It important to remember that all portnames have global scope, so ports unify with other ports that have the same label. Thus,two instances with the same name and the same type will interfere with each other.

To create an instance, click on the add-instance icon (the green one), or right-clickon a blank part of the block diagram and select "Insert Instance". An instance will appearin the block diagram editor which can be moved, resized, and renamed. The label must beformatted such that the instance name and the name of the component it is instantiatingare separated by a colon (�:�), where the instance name precedes the component name.

4.5 Types of components and ports

A port may be �agged as either a source or a sink by choosing the relevant option inthe context menu, which is accessed by right-clicking on the port concerned. At least onesource port and one sink port must be identi�ed in the model for any of the analyses toproduce results (see Section 6). Source ports are coloured red by default, and sink portsare coloured black.

11

Figure 13: Instantiation example

4.5.1 Libraries

A library is created by right-clicking on a component and selecting �Library�. Every com-ponent hierarchically underneath a library component will be in scope for instantiationpurposes, but the de�nitions themselves will not be directly analysed. Consequently, anyports in this hierarchy that share the same name will not unify with each other (see Sec-tion 3.6). Such ports will unify only when a component that contains them is instantiated.

4.5.2 Disabling hierarchies

The right-click context menu for a component o�ers the option to uncheck �Enable�. Thiswill result in the entire hierarchy underneath that component being completely ignoredfrom any `deep' analysis.

5 Opening, Saving, and Importing

5.1 SIFA XML

Models in SIFA are saved as compressed XML �les, using standard ZIP format compres-sion. In actuality, the XML �les always describe the contents of a single component. Whena model is saved using the Project .Save menu option, it is just saving the Root compo-nent. Components can be individually saved via the Component .Save menu option inthe component's window. It is crucial to realise that only the graph and the modes (thecontents) of the component are saved, not the component itself. So, when a component

12

is saved its top-level interface, which resides in the parent component graph, is lost. Thismakes no di�erence for the root component, but for other components this can lead tounexpected results.

To save a component C for later use, the component needs to reside in a new graph Pthat just houses that component (connected to nothing) � use copy and paste to achievethis if necessary. It is the parent graph P that must be saved, so that when the savedcomponent is reopened, the parent P becomes the Root and the component C appearsas expected on the Root graph's canvas. When using the Component . Import menuoption, the parent component in the �le is merged with the component invoking the importcommand. This results in the component C being placed on the graph canvas in the samelocation and with the dimensions that it had in P .

The DTD (Document Type De�nition) for the XML �le format is as follows.

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE Component [

<!ELEMENT Component (LocalFaultData, Schematic, Ports?)>

<!ATTLIST Component

name ID #REQUIRED

abstract (false|true) #IMPLIED

transitive (false|true) #IMPLIED

enabled (false|true) #IMPLIED

w CDATA #IMPLIED

h CDATA #IMPLIED>

<!ELEMENT LocalFaultData (Matrix?, FaultModes?)>

<!ELEMENT Schematic (ChildComponent*, Instantiation*, Connection*)>

<!ELEMENT Port EMPTY>

<!ATTLIST Port

name ID #REQUIRED

x CDATA #REQUIRED

y CDATA #REQUIRED

w CDATA #REQUIRED

h CDATA #REQUIRED

colour (red|black|none) #REQUIRED>

<!ELEMENT Ports (Port*)>

<!ELEMENT Cell (FaultSet)>

<!ATTLIST Cell

row CDATA #REQUIRED

column CDATA #REQUIRED>

<!ELEMENT Matrix (Cell*)>

<!ELEMENT FaultMode (#PCDATA)>

<!ATTLIST FaultMode

abbreviation CDATA #REQUIRED

13

normal (false|true) #IMPLIED>

<!ELEMENT FaultSet (FaultSet?, FaultMode*)>

<!ELEMENT FaultModes (FaultMode*)>

<!ELEMENT ChildComponent (Component)>

<!ATTLIST ChildComponent

x CDATA #REQUIRED

y CDATA #REQUIRED>

<!ELEMENT Instantiation (Ports?)>

<!ATTLIST Instantiation

name ID #REQUIRED

type CDATA #REQUIRED

x CDATA #REQUIRED

y CDATA #REQUIRED

w CDATA #REQUIRED

h CDATA #REQUIRED>

<!ELEMENT Connection EMPTY>

<!ATTLIST Connection

name CDATA #REQUIRED

source_prt IDREF #REQUIRED

source_cmp IDREF #REQUIRED

target_prt IDREF #REQUIRED

target_cmp IDREF #REQUIRED

direction (single|double) #REQUIRED>

]>

5.2 Converters

SIFA comes bundled with two open-source converters that can read from VHDL and writeto SVG respectively. A converter can be any program that translates standard input tostandard output, and SIFA can be extended to support any number of such converters. Anoutput converter must accept SIFA XML (uncompressed) as input, and an input convertermust produce valid SIFA XML as output.

Converters are con�gured via the �les �input.prop� and �output.prop�, and are indexedby �le extension. As an example, to add an input converter �conv.exe� for all �les withextension �ext�, the following entries would be added to the input.prop �le:

ext=conv.exe

ext.description=Some meaningful description (.ext)

Since the VHDL and SVG converters use Java 5, �java� must be accessible from thePATH environment. If this is not the case, the input.prop and output.prop �les may becustomised.

14

VHDL2SIFA

SIFA supports the direct importing of VHDL-AMS �les, so long as the VHDL is not tooadvanced (it doesn't support generators, for instance). SIFA will ignore any parts of theVHDL that are not necessary to provide the basic structure and connectivity information.Entities in VHDL are translated into components in SIFA and segregated into a library,whilst VHDL architectures instantiate the components in the library and connect themtogether according to the net-lists. In a typical circuit, the power rails can really obscurean analysis by producing too many false positives if they are enabled, so it is useful todisable these net-lists.

5.3 Drag and drop

The component tree explorer and the graph editor supports, to a limited extent, drag anddrop operations. Speci�cally, the component tree is a source of drag and drop data, andthe graph editor is a target. This can be a very useful feature for editing components usingsearch-and-replace. Simply drag the component3 into Word Pad (or similar), make thenecessary edits to the XML document, and the drag the text onto a graph canvas. In thissense, dragging a component from the tree explorer is equivalent to saving it, decompressingit, and then opening it as a text �le. Dropping is just equivalent to importing a component.Dragging straight from the tree explorer onto a graph is a useful way to quickly copycomponents or graphs around the model.

6 Analysis

Analysis jobs in SIFA always run in the background, giving progress information to thetask manager at the bottom of the main window. This allows you to continue workingwith the model while analytical jobs are being run. This is possible because SIFA takesa snapshot of the model at the time when the analysis is launched, and only during thistime is the program �frozen� to disallow any user interaction. When the analysis jobs arecompleted, they will create a new window containing the results. If SIFA is terminatedwhile jobs are running in the background, these jobs will also be terminated. If a job istaking too long or is mistakenly launched, it can be killed by right-clicking on the taskand selecting Kill from the context menu. Some types of analysis will still produce partialresults if they are killed, which can aid in trouble-shooting.

In the following sections we describe the analysis jobs that may be launched from SIFA.

6.1 Topological

A topological analysis will only look at the way a single graph is connected, and so are onlyavailable from a component window's menu bar. It treats components and instances as

3To avoid unexpected behaviour, leaf components cannot be dragged and dropped (see Section 5.1).

15

basic blocks � it does not consider in any way the internal connectivity that the componentor instance describes. If two ports belong to a common component or instance, they areconsidered to be connected. Such analyses are useful for getting an idea of how componentsare connected on a single sheet, disregarding subcomponent-graphs, operating modes, andinstantiation.

There are two types of topological analyses: minimal cut-sets, and �ow analysis. Wewill describe each in turn.

6.1.1 Minimal cut-sets

The minimal cut-sets of a graph are the smallest sets of components or instances that, ifremoved, would disconnect the sinks from the sources. In security related applications, theminimal cut-sets normally indicate the security-critical region necessary for enforcing do-main separation. To �nd the minimal cut-sets of a graph, select the Analysis .TopologicalMinimal Cutsets menu item4.

6.1.2 Flow analysis

Flow analysis identi�es the components and instances that lie on any path from source tosink through the graph topology. To invoke a �ow analysis, select Analysis .TopologicalFlow from the component window.

6.2 Deep

Deep analyses take operating modes, component de�nitions, and instantiation of compo-nents into account to trace paths through the graphs.

6.2.1 Find all paths

From the main window, select Analysis .Find All Paths to invoke this analysis job. Theresults will show a set of trees (as tabs) representing traces through components fromsources to sinks, where each tree corresponds to the number of points-of-failure requiredto enable every path in the tree.

For example, consider the model in Figure 14. The analysis �nds four distinct pathsthrough this model, as can be seen in Figure 15. For each path, the right hand pane showsthe operation modes enabled to activate the path and their respective probabilities, alongwith the combination of modes resulting in the highest probability for the path. Multipleentries in this pane (separated by a line of dashes) indicate that a choice was possiblebetween multiple component de�nitions of the same name, and consequently there aredi�erent results depending upon these choices. All possible choices are listed here, even ifthe probability/fault pro�les match.

4The algorithm for �nding the minimal cut-sets has exponential time-complexity in the worst-case, butwe intend to improve this in later versions of SIFA.

16

Figure 14: Example SIFA model

17

Figure 15: Results from Find All Paths for model in Figure 14

18

The maximum number of points-of-failure SIFA is willing to tolerate during the searchcan considerably a�ect the time it takes to perform the analysis. The smaller this limit,the faster the search time. This con�guration setting can be changed (see Section 8).

There are particular cases where edge labels become relevant (they normally have noa�ect on the semantics of the model). If an edge connects to a port with the same label asanother edge connecting from the same port, then the searching algorithm may not followthe second edge immediately after following the �rst one. For this reason it is generallya good idea to use di�erent names for edges, but in some models there are good reasonsfor taking advantage of this property (especially for controlling search time complexity).This is a con�gurable option (�FollowArcLabelDupes�), and so can be disabled or enabledas desired. It is enabled by default.

6.2.2 Consistency analysis

Consistency analysis allows you to check for consistency between two models, which arereally just sub-hierarchies of the same model. This is useful for comparing abstract modelswith concrete models, where the concrete models contain much more detail than the ab-stract models. Consistency is measured in terms of paths (see Section 6.2.1) through eachof the models.

Point-point versus Trace There are two types of consistency analysis that can be run:point-point and trace. A trace consistency analysis is much like a `di�' between the all-paths analysis results of both models, except that connectivity over the concrete model isconsidered only in terms of the ports that also appear in the abstract model. Point-pointconsistency analysis, on the other hand, will consider all concrete subpaths between pairsof abstract ports that are reachable in the concrete model from a source, and also exist ona path from source to sink5. For each of these subpaths, a path must be found throughthe abstract model which `matches' the concrete subpath.

Point-point matching paths A concrete path is considered to match an abstract pathif every port on the abstract path appears in the concrete path, in the same order � i.e.the concrete path may contain more ports than a matching abstract path. Further, theports in the concrete path are either in the abstract path or not in the abstract model atall. Since the point-point analysis is conducted between pairs of abstract ports, a matchingconcrete path will begin and end with an abstract port but may contain any number ofexclusively concrete ports in between.

For paths to match, there is also consideration given to the number of faults requiredto enable the paths. An abstract path that matches a concrete path must have a fewernumber, or equal number, of points-of-failure compared to the concrete path. For example,consider an analysis run on the three models in Figure 16(a). Here the concrete model is

5Full reachability from sources, without regard to sinks, can also be considered. This is a stronger formof consistency and can be enabled as a con�guration option.

19

(a) Model

(b) Middle vs Concrete (c) Abstract vs Middle

Figure 16: Matching paths � point-point consistency analysis

20

the same as the model presented in Figure 14, but two possible levels of abstraction arebeing checked for consistency. In these abstractions a component is introduced that justconnects the ports on its left side to the ports on its right side with a single fault. InFigure 16(b), it can be seen that for one path through the concrete model, the abstractiondirectly above can match that path, and for each subpath there is a fewer or equal numberof points-of-failure. Similarly, the top-most model can match the path in Figure 16(c) �here, the middle model is considered as the concrete model. Thus, for that particular path,all of the abstractions are consistent. If this is true for all paths in the concrete model,then the models are completely consistent.

Multiple overlapping component de�nitions In the case where multiple componentde�nitions are used, there can exist di�erent possibilities with points-of-failure counts forthat same paths. Here, the minimum is always considered, so that for every concrete paththere must exist a matching abstract path where the minimum number of points-of-failurein the abstract path is less than or equal to the minimum number of points-of-failure inthe concrete path.

Probabilistic consistency analysis The point-point consistency analysis can option-ally be performed with respect to the probabilities associated with faults, rather thanjust considering the number of faults to form a connection. The probability of a connec-tion/path is calculated to be the product of the probabilities of the constituent faults thatcause the path to exist. If a path exists with zero points-of-failure, this is interpreted tohave a probability of one (100%).

Consistency over probabilities has a slightly di�erent interpretation in the presence ofmultiple overlapping component de�nitions than the simple point-of-failure count. Here,the maximum is always considered, so that for every concrete path there must exist amatching abstract path where the maximum probability of the abstract path is greaterthan or equal to the maximum probability of the concrete path.

Launching A consistency analysis is invoked by selecting Analysis .Consistency Analysis(trace) or Analysis .Consistency Analysis (point-point) from the main menu bar. Thesetup dialogs (see, for example, Figure 17) have two component tree explorers that allowyou to select an abstract model and a concrete model. For obvious reasons, these modelsmust not be the same (otherwise consistency is guaranteed!). At the top of this windowis a combo-box that conveniently allows you to override the default maximum number ofpoints-of-failure that SIFA is to consider.

Point-point results The output from the point-point consistency analysis is in theform of counter-examples arising from concrete subpaths that cannot be matched by apath through the abstract model, or alternatively a dialog box indicating that the twomodels are consistent.

21

Figure 17: Simulation setup dialog

Trace results The results from the trace consistency analysis are presented in a treewhich shows paths through the abstract model as sequences of ports, from root to leaf.These paths are not highlighted if they are in both models, but appear bright red if partof a path is exclusively in the concrete model, or italicised if part of a path is exclusivelyin the abstract model. If the two models are consistent, the simulation results will showno highlighted ports.

6.3 Evaluation Process

This section describes the typical process that a user would employ to help perform abottom-up evaluation of a hardware device. These steps do not consider probabilisticpro�ling.

1. Import VHDL into SIFA. Rename the top-level �Entities� view to give the device asensible name.

2. If power circuitry is to be ignored, identify the net-lists used for the power circuitry(VCC/GND), and disable these components. It is probably a good idea to documentthis as a major assumption.

3. In some VHDL models, SIFA will generate default component de�nitions more thanonce (under di�erent architectures). Disable any repeated de�nitions so that they donot interfere with the analysis. A good idea might be to cut and paste the de�nitionsinto a single uni�ed library.

4. Create an instance of the imported VHDL, and add the source and sink ports. Thetype of the instance is the 'sensible' name that was chosen in Step 1. This instanceis probably best placed in the top-level �Architecture� view.

22

5. Optional : Create a custom component library, and disable the VHDL defaults. Al-ternatively, the VHDL defaults may be edited. The component de�nitions form acritical part of the assumptions made when evaluating a device, and should be care-fully documented.

6. Run an all-paths analysis for zero points of failure over this model.

7. Create a new abstract view from the root.

8. Find the key ports and components along the paths and add them to the abstractmodel, including the source and sink ports. Give the ports exactly the same namesas they appear in the analysis (fully-quali�ed). If there are no paths found, this mayindicate a either a bug in the model, or an ideal model. Care should be taken toensure which is occurring.

9. Connect the abstract components as per the connectivity of the all-paths analysisresults. Use as much detail as necessary to convincingly convey the key parts of thearchitecture relevant to the security argument.

10. Perform a point-point consistency analysis comparing the abstract and VHDL mod-els, for zero points of failure. This will con�rm the correctness of the abstract model.Since it was derived from the all-paths analysis, there should be no problems withthe consistency.

11. Perform a point-point consistency analysis comparing the abstract and VHDL mod-els, for one point of failure.

12. If there are results from this analysis (most likely), create a new sub-view of theabstract model to contain the connectivity resulting from a single fault. For eachconnection in the results of the point-point consistency analysis, add this connectivity(by creating a `faulty' abstract component) to the new view.

13. As each connection is acknowledged, its possible impact on the security of the deviceshould be noted. It is probably a good idea to distinguish (using views) betweenfaults that are critical and faults that are not.

14. Repeat from Step 10 with greater limits on the number of points-of-failure until theresultant connectivity becomes too unlikely to be plausible.

15. Optional : In the preferences window, enable �Search.ConsiderFullReachability� andre-run the consistency analyses to make sure there is nothing in the abstract modelsthat does not apply to the security argument but is a deceptive representation of theVHDL all-the-same.

23

7 Obscure Features

This section contains features that are relatively obscure, but warrant explanation.

7.1 Component transitivity

By default, components are 'transitive'. During deep searching, transitive components willallow transitive connectivity internally. For example, consider a component that has threeports: A, B, and C, where in a certain mode, A connects to B and B connects to C. In thismode, the search will normally consider the internal path from A to C to be connected,i.e. allow transitive internal connectivity. This can be disabled by right-clicking on acomponent de�nition and choosing �Transitive�.

7.2 α-Features

This section deals with some of the more obscure or untested aspects of SIFA. Features thathave not been completed, tested thoroughly, or lack stability are classi�ed as α-features.These features can be enabled via the con�guration settings (see Section 8), but by defaultthey are disabled.There are currently no α-features.

7.3 Command Line Options

java -jar sifa.jar [--export] file

Argument Description

file Load �le upon starting--export file Load �le and send unzipped XML to standard output.

8 Con�guration

Customisation of SIFA is possible by opening the con�guration dialog SIFA .Preferences.All preferences are saved in a �le named `sifa.prop', which is created the �rst time SIFA islaunched. To restore the default con�guration, simply delete this �le.

24

8.1 Colours

Property name Description

Editor.ComponentColour Component colourEditor.ComponentLabelColour Component label colourEditor.ComponentLibraryColour Library component colourEditor.ComponentDisabledColour Disabled component colour

Editor.GridColour Grid colourEditor.Uncon�rmedArcColour Normal arc colour

Editor.PortLabelColour Port label text colourEditor.PortConnectorColour Colour of line from ports to componentsEditor.PortOrphanColour Colour to highlight orphaned portsEditor.PortBorderColour Port border colourEditor.BackgroundColour Colour of graph backgroundEditor.InstanceLabelColour Component label text colour

Editor.InstanceColour Instance �ll colourEditor.DesktopColour MDI desktop background colour

Editor.PortSourceColour Source ports (nominally red)Editor.PortSinkColour Sink ports (nominally black)

Editor.PortHighlightColour Colour of highlighted ports

8.2 Values

Property Name Description

Search.POFLimit Limits the number of points-of-failure considered by default.

Search.DebugLevel 0 = None; 1 = Some; 2 = Lots.Search.MeanAbstractPathLength Useful for optimisation of point-

point consistency analysis.

Search.MaxPathLength Used to bound searching capabilitiesof SIFA.

SIFA.ProcessorCount Determines number of spawnedthreads for searching.

25

8.3 Conditions

Property Name Description

SIFA.AlphaFeatures Features of SIFA considered too un-stable can be accessed by enablingthis condition.

Search.ConsiderFullReachability Consider all reachable ports inpoint-point consistency analysis,rather than just those ports whichexists on a path from source to sink.

Search.FollowArcLabelDupes Set to true if all-paths search is toimmediately follow an arc with thesame label as arc it has just tra-versed.

Search.HighlightPaths Highlight ports in the editor thatcorrespond to selected results in theresults windows.

26

8.4 Properties

Property Name Description

SIFA.LookAndFeel This is the fully quali�ed class nameof the look and feel SIFA will loadupon starting. If SIFA is unable toload the speci�ed look and feel, thedefault one will be used.

9 Bugs

There is a web page for SIFA which is kept up to date, and includes a list of known bugs andfeature requests. This will be accessible from http://www.itee.uq.edu.au/~infosec/SIFA/.

10 Legals

SIFA utilises some third-party libraries and plug-ins that have the following licence condi-tions. The last subsection includes a disclaimer for SIFA itself.

27

10.1 JGraph LGPL LicenseGNU LESSER GENERAL PUBLIC LICENSE

Version 2.1, February 1999

Copyright (C) 1991, 1999 Free Software Foundation, Inc.59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Everyone is permitted to copy and distribute verbatim copiesof this license document, but changing it is not allowed.

[This is the first released version of the Lesser GPL. It also countsas the successor of the GNU Library Public License, version 2, hencethe version number 2.1.]

Preamble

The licenses for most software are designed to take away yourfreedom to share and change it. By contrast, the GNU General PublicLicenses are intended to guarantee your freedom to share and changefree software--to make sure the software is free for all its users.

This license, the Lesser General Public License, applies to somespecially designated software packages--typically libraries--of theFree Software Foundation and other authors who decide to use it. Youcan use it too, but we suggest you first think carefully about whetherthis license or the ordinary General Public License is the betterstrategy to use in any particular case, based on the explanations below.

When we speak of free software, we are referring to freedom of use,not price. Our General Public Licenses are designed to make sure thatyou have the freedom to distribute copies of free software (and chargefor this service if you wish); that you receive source code or can getit if you want it; that you can change the software and use pieces ofit in new free programs; and that you are informed that you can dothese things.

To protect your rights, we need to make restrictions that forbiddistributors to deny you these rights or to ask you to surrender theserights. These restrictions translate to certain responsibilities foryou if you distribute copies of the library or if you modify it.

For example, if you distribute copies of the library, whether gratisor for a fee, you must give the recipients all the rights that we gaveyou. You must make sure that they, too, receive or can get the sourcecode. If you link other code with the library, you must providecomplete object files to the recipients, so that they can relink themwith the library after making changes to the library and recompilingit. And you must show them these terms so they know their rights.

We protect your rights with a two-step method: (1) we copyright thelibrary, and (2) we offer you this license, which gives you legalpermission to copy, distribute and/or modify the library.

To protect each distributor, we want to make it very clear thatthere is no warranty for the free library. Also, if the library ismodified by someone else and passed on, the recipients should knowthat what they have is not the original version, so that the originalauthor's reputation will not be affected by problems that might beintroduced by others.----------------------------------------------------------

Finally, software patents pose a constant threat to the existence ofany free program. We wish to make sure that a company cannoteffectively restrict the users of a free program by obtaining arestrictive license from a patent holder. Therefore, we insist thatany patent license obtained for a version of the library must beconsistent with the full freedom of use specified in this license.

Most GNU software, including some libraries, is covered by theordinary GNU General Public License. This license, the GNU LesserGeneral Public License, applies to certain designated libraries, andis quite different from the ordinary General Public License. We usethis license for certain libraries in order to permit linking thoselibraries into non-free programs.

When a program is linked with a library, whether statically or usinga shared library, the combination of the two is legally speaking acombined work, a derivative of the original library. The ordinaryGeneral Public License therefore permits such linking only if theentire combination fits its criteria of freedom. The Lesser GeneralPublic License permits more lax criteria for linking other code withthe library.

We call this license the "Lesser" General Public License because itdoes Less to protect the user's freedom than the ordinary GeneralPublic License. It also provides other free software developers Lessof an advantage over competing non-free programs. These disadvantagesare the reason we use the ordinary General Public License for many

libraries. However, the Lesser license provides advantages in certainspecial circumstances.

For example, on rare occasions, there may be a special need toencourage the widest possible use of a certain library, so that it becomesa de-facto standard. To achieve this, non-free programs must beallowed to use the library. A more frequent case is that a freelibrary does the same job as widely used non-free libraries. In thiscase, there is little to gain by limiting the free library to freesoftware only, so we use the Lesser General Public License.

In other cases, permission to use a particular library in non-freeprograms enables a greater number of people to use a large body offree software. For example, permission to use the GNU C Library innon-free programs enables many more people to use the whole GNUoperating system, as well as its variant, the GNU/Linux operatingsystem.

Although the Lesser General Public License is Less protective of theusers' freedom, it does ensure that the user of a program that islinked with the Library has the freedom and the wherewithal to runthat program using a modified version of the Library.

The precise terms and conditions for copying, distribution andmodification follow. Pay close attention to the difference between a"work based on the library" and a "work that uses the library". Theformer contains code derived from the library, whereas the latter mustbe combined with the library in order to run.----------------------------------------------------------

GNU LESSER GENERAL PUBLIC LICENSETERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

0. This License Agreement applies to any software library or otherprogram which contains a notice placed by the copyright holder orother authorized party saying it may be distributed under the terms ofthis Lesser General Public License (also called "this License").Each licensee is addressed as "you".

A "library" means a collection of software functions and/or dataprepared so as to be conveniently linked with application programs(which use some of those functions and data) to form executables.

The "Library", below, refers to any such software library or workwhich has been distributed under these terms. A "work based on theLibrary" means either the Library or any derivative work undercopyright law: that is to say, a work containing the Library or aportion of it, either verbatim or with modifications and/or translatedstraightforwardly into another language. (Hereinafter, translation isincluded without limitation in the term "modification".)

"Source code" for a work means the preferred form of the work formaking modifications to it. For a library, complete source code meansall the source code for all modules it contains, plus any associatedinterface definition files, plus the scripts used to control compilationand installation of the library.

Activities other than copying, distribution and modification are notcovered by this License; they are outside its scope. The act ofrunning a program using the Library is not restricted, and output fromsuch a program is covered only if its contents constitute a work basedon the Library (independent of the use of the Library in a tool forwriting it). Whether that is true depends on what the Library doesand what the program that uses the Library does.

1. You may copy and distribute verbatim copies of the Library'scomplete source code as you receive it, in any medium, provided thatyou conspicuously and appropriately publish on each copy anappropriate copyright notice and disclaimer of warranty; keep intactall the notices that refer to this License and to the absence of anywarranty; and distribute a copy of this License along with theLibrary.

You may charge a fee for the physical act of transferring a copy,and you may at your option offer warranty protection in exchange for afee.----------------------------------------------------------

2. You may modify your copy or copies of the Library or any portionof it, thus forming a work based on the Library, and copy anddistribute such modifications or work under the terms of Section 1above, provided that you also meet all of these conditions:

a) The modified work must itself be a software library.

b) You must cause the files modified to carry prominent noticesstating that you changed the files and the date of any change.

28

c) You must cause the whole of the work to be licensed at nocharge to all third parties under the terms of this License.

d) If a facility in the modified Library refers to a function or atable of data to be supplied by an application program that usesthe facility, other than as an argument passed when the facilityis invoked, then you must make a good faith effort to ensure that,in the event an application does not supply such function ortable, the facility still operates, and performs whatever part ofits purpose remains meaningful.

(For example, a function in a library to compute square roots hasa purpose that is entirely well-defined independent of theapplication. Therefore, Subsection 2d requires that anyapplication-supplied function or table used by this function mustbe optional: if the application does not supply it, the squareroot function must still compute square roots.)

These requirements apply to the modified work as a whole. Ifidentifiable sections of that work are not derived from the Library,and can be reasonably considered independent and separate works inthemselves, then this License, and its terms, do not apply to thosesections when you distribute them as separate works. But when youdistribute the same sections as part of a whole which is a work basedon the Library, the distribution of the whole must be on the terms ofthis License, whose permissions for other licensees extend to theentire whole, and thus to each and every part regardless of who wroteit.

Thus, it is not the intent of this section to claim rights or contestyour rights to work written entirely by you; rather, the intent is toexercise the right to control the distribution of derivative orcollective works based on the Library.

In addition, mere aggregation of another work not based on the Librarywith the Library (or with a work based on the Library) on a volume ofa storage or distribution medium does not bring the other work underthe scope of this License.

3. You may opt to apply the terms of the ordinary GNU General PublicLicense instead of this License to a given copy of the Library. To dothis, you must alter all the notices that refer to this License, sothat they refer to the ordinary GNU General Public License, version 2,instead of to this License. (If a newer version than version 2 of theordinary GNU General Public License has appeared, then you can specifythat version instead if you wish.) Do not make any other change inthese notices.----------------------------------------------------------

Once this change is made in a given copy, it is irreversible forthat copy, so the ordinary GNU General Public License applies to allsubsequent copies and derivative works made from that copy.

This option is useful when you wish to copy part of the code ofthe Library into a program that is not a library.

4. You may copy and distribute the Library (or a portion orderivative of it, under Section 2) in object code or executable formunder the terms of Sections 1 and 2 above provided that you accompanyit with the complete corresponding machine-readable source code, whichmust be distributed under the terms of Sections 1 and 2 above on amedium customarily used for software interchange.

If distribution of object code is made by offering access to copyfrom a designated place, then offering equivalent access to copy thesource code from the same place satisfies the requirement todistribute the source code, even though third parties are notcompelled to copy the source along with the object code.

5. A program that contains no derivative of any portion of theLibrary, but is designed to work with the Library by being compiled orlinked with it, is called a "work that uses the Library". Such awork, in isolation, is not a derivative work of the Library, andtherefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Librarycreates an executable that is a derivative of the Library (because itcontains portions of the Library), rather than a "work that uses thelibrary". The executable is therefore covered by this License.Section 6 states terms for distribution of such executables.

When a "work that uses the Library" uses material from a header filethat is part of the Library, the object code for the work may be aderivative work of the Library even though the source code is not.Whether this is true is especially significant if the work can belinked without the Library, or if the work is itself a library. Thethreshold for this to be true is not precisely defined by law.

If such an object file uses only numerical parameters, datastructure layouts and accessors, and small macros and small inlinefunctions (ten lines or less in length), then the use of the objectfile is unrestricted, regardless of whether it is legally a derivativework. (Executables containing this object code plus portions of theLibrary will still fall under Section 6.)

Otherwise, if the work is a derivative of the Library, you maydistribute the object code for the work under the terms of Section 6.Any executables containing that work also fall under Section 6,whether or not they are linked directly with the Library itself.----------------------------------------------------------

6. As an exception to the Sections above, you may also combine orlink a "work that uses the Library" with the Library to produce awork containing portions of the Library, and distribute that workunder terms of your choice, provided that the terms permitmodification of the work for the customer's own use and reverseengineering for debugging such modifications.

You must give prominent notice with each copy of the work that theLibrary is used in it and that the Library and its use are covered bythis License. You must supply a copy of this License. If the workduring execution displays copyright notices, you must include thecopyright notice for the Library among them, as well as a referencedirecting the user to the copy of this License. Also, you must do oneof these things:

a) Accompany the work with the complete correspondingmachine-readable source code for the Library including whateverchanges were used in the work (which must be distributed underSections 1 and 2 above); and, if the work is an executable linkedwith the Library, with the complete machine-readable "work thatuses the Library", as object code and/or source code, so that theuser can modify the Library and then relink to produce a modifiedexecutable containing the modified Library. (It is understoodthat the user who changes the contents of definitions files in theLibrary will not necessarily be able to recompile the applicationto use the modified definitions.)

b) Use a suitable shared library mechanism for linking with theLibrary. A suitable mechanism is one that (1) uses at run time acopy of the library already present on the user's computer system,rather than copying library functions into the executable, and (2)will operate properly with a modified version of the library, ifthe user installs one, as long as the modified version isinterface-compatible with the version that the work was made with.

c) Accompany the work with a written offer, valid for atleast three years, to give the same user the materialsspecified in Subsection 6a, above, for a charge no morethan the cost of performing this distribution.

d) If distribution of the work is made by offering access to copyfrom a designated place, offer equivalent access to copy the abovespecified materials from the same place.

e) Verify that the user has already received a copy of thesematerials or that you have already sent this user a copy.

For an executable, the required form of the "work that uses theLibrary" must include any data and utility programs needed forreproducing the executable from it. However, as a special exception,the materials to be distributed need not include anything that isnormally distributed (in either source or binary form) with the majorcomponents (compiler, kernel, and so on) of the operating system onwhich the executable runs, unless that component itself accompaniesthe executable.

It may happen that this requirement contradicts the licenserestrictions of other proprietary libraries that do not normallyaccompany the operating system. Such a contradiction means you cannotuse both them and the Library together in an executable that youdistribute.----------------------------------------------------------

7. You may place library facilities that are a work based on theLibrary side-by-side in a single library together with other libraryfacilities not covered by this License, and distribute such a combinedlibrary, provided that the separate distribution of the work based onthe Library and of the other library facilities is otherwisepermitted, and provided that you do these two things:

a) Accompany the combined library with a copy of the same workbased on the Library, uncombined with any other libraryfacilities. This must be distributed under the terms of theSections above.

29

b) Give prominent notice with the combined library of the factthat part of it is a work based on the Library, and explainingwhere to find the accompanying uncombined form of the same work.

8. You may not copy, modify, sublicense, link with, or distributethe Library except as expressly provided under this License. Anyattempt otherwise to copy, modify, sublicense, link with, ordistribute the Library is void, and will automatically terminate yourrights under this License. However, parties who have received copies,or rights, from you under this License will not have their licensesterminated so long as such parties remain in full compliance.

9. You are not required to accept this License, since you have notsigned it. However, nothing else grants you permission to modify ordistribute the Library or its derivative works. These actions areprohibited by law if you do not accept this License. Therefore, bymodifying or distributing the Library (or any work based on theLibrary), you indicate your acceptance of this License to do so, andall its terms and conditions for copying, distributing or modifyingthe Library or works based on it.

10. Each time you redistribute the Library (or any work based on theLibrary), the recipient automatically receives a license from theoriginal licensor to copy, distribute, link with or modify the Librarysubject to these terms and conditions. You may not impose any furtherrestrictions on the recipients' exercise of the rights granted herein.You are not responsible for enforcing compliance by third parties withthis License.----------------------------------------------------------

11. If, as a consequence of a court judgment or allegation of patentinfringement or for any other reason (not limited to patent issues),conditions are imposed on you (whether by court order, agreement orotherwise) that contradict the conditions of this License, they do notexcuse you from the conditions of this License. If you cannotdistribute so as to satisfy simultaneously your obligations under thisLicense and any other pertinent obligations, then as a consequence youmay not distribute the Library at all. For example, if a patentlicense would not permit royalty-free redistribution of the Library byall those who receive copies directly or indirectly through you, thenthe only way you could satisfy both it and this License would be torefrain entirely from distribution of the Library.

If any portion of this section is held invalid or unenforceable under anyparticular circumstance, the balance of the section is intended to apply,and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe anypatents or other property right claims or to contest validity of anysuch claims; this section has the sole purpose of protecting theintegrity of the free software distribution system which isimplemented by public license practices. Many people have madegenerous contributions to the wide range of software distributedthrough that system in reliance on consistent application of thatsystem; it is up to the author/donor to decide if he or she is willingto distribute software through any other system and a licensee cannotimpose that choice.

This section is intended to make thoroughly clear what is believed tobe a consequence of the rest of this License.

12. If the distribution and/or use of the Library is restricted incertain countries either by patents or by copyrighted interfaces, theoriginal copyright holder who places the Library under this License may addan explicit geographical distribution limitation excluding those countries,so that distribution is permitted only in or among countries not thusexcluded. In such case, this License incorporates the limitation as ifwritten in the body of this License.

13. The Free Software Foundation may publish revised and/or newversions of the Lesser General Public License from time to time.Such new versions will be similar in spirit to the present version,but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Libraryspecifies a version number of this License which applies to it and"any later version", you have the option of following the terms andconditions either of that version or of any later version published bythe Free Software Foundation. If the Library does not specify alicense version number, you may choose any version ever published bythe Free Software Foundation.----------------------------------------------------------

14. If you wish to incorporate parts of the Library into other freeprograms whose distribution conditions are incompatible with these,write to the author to ask for permission. For software which iscopyrighted by the Free Software Foundation, write to the FreeSoftware Foundation; we sometimes make exceptions for this. Our

decision will be guided by the two goals of preserving the free statusof all derivatives of our free software and of promoting the sharingand reuse of software generally.

NO WARRANTY

15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NOWARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OROTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANYKIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THEIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THELIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUMETHE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO INWRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFYAND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOUFOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL ORCONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THELIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEINGRENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR AFAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IFSUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCHDAMAGES.

END OF TERMS AND CONDITIONS

10.2 JDom v1.0 Apache License

Copyright (C) 2000-2004 Jason Hunter & Brett McLaughlin. All rightsreserved.

Redistribution and use in source and binary forms, with or withoutmodi�cation, are permitted provided that the following conditions aremet:

1. Redistributions of source code must retain the above copy-right notice, this list of conditions, and the following dis-claimer.

2. Redistributions in binary form must reproduce the above copy-right notice, this list of conditions, and the disclaimer thatfollows these conditions in the documentation and/or othermaterials provided with the distribution.

3. The name "JDOM" must not be used to endorse or pro-mote products derived from this software without prior writ-ten permission. For written permission, please contact <re-quest_AT_jdom_DOT_org>.

4. Products derived from this software may not be called "JDOM",nor may "JDOM" appear in their name, without prior writ-ten permission from the JDOM Project Management <re-quest_AT_jdom_DOT_org>.

THIS SOFTWARE IS PROVIDED �AS IS� AND ANY EXPRESSEDOR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITEDTO, THE IMPLIED WARRANTIES OF MERCHANTABILITY ANDFITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. INNO EVENT SHALL THE JDOM AUTHORS OR THE PROJECTCONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, IN-CIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAM-AGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, ORPROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSEDAND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OROTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THISSOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCHDAMAGE.

10.3 SIFA

SIFA is licensed for academic use only.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLD-ERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IM-PLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THEIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS

30

FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENTSHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LI-ABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUTNOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODSOR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESSINTERRUPTION) HOWEVER CAUSED AND ON ANY THEORYOF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARIS-ING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVENIF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

31