To show our model in action, we give a sample architectural description in our syntax. As an example, we use the homebanking application StarMoney 5.0 by Star Finanz – Software Entwicklung und Vertriebs GmbH. We expose the software structure based on analysis without knowledge of the source code or internal design documentation. The full analysis is documented in section 7.2.
4.4.1
Components
Homebanking transactions are prepared at a local machine where they are signed by help of a smart card and then transmitted to the bank’s server. Architecturally, the homebanking application with a total size of ca. 50 MB consists of three small executable modules, StartStarMoney.exe [60 KB] for preparing the start of the main executable StarMoney.exe [172 KB], and SCRSetup.exe [132 KB] for configuring smart card read- ers attached to the system. (five additional executable modules perform peripheral functionality: Conversion of older versions’ data (smkonv.exe), T-Online Classic access (CLGate32.exe, sfkclgateslave.exe, sfktonac.exe), remote support (NetViewer.exe))
The executable modules are supported by 89 executable library files that extend the functionality of the main executable along 6 function groups: Core banking, Smart card communication, Database access, Communication, User interface, Miscellaneous.
4.4.2
Configuration: interaction and dependencies
We present the architectural description of the SCRSetup.exe utility software as a sample. This includes executable and data components, execute and data transfer connectors, and parts of the access control configuration.
In addition to the single executable file SCRSetup.exe, more than a dozen files are linked at runtime. These are 14 files provided by the manufacturer that are stored in the same folder as the main application, 2 third party files (ct32.dll and np*.dll), as well as 16 files that belong to the operating system (two of which are shown in the figures: winscard.dll and scarddlg.dll).
Some configuration data influences the execution of the application. It is stored in three files and imported by several modules.
Figure 4-2 shows executable data components and executable connectors of applica- tion SCRSetup.exe, i.e., its call graph. In the upper right-hand part of a component rectangle the container in which the component resides is shown. An arrowhead repre- sents a LinkExecuted role, the tail of an arrow stands for a LinkExecutor role. Operating system data components that are linked are not shown in the figure. They do not of- fer an additional attack surface and are stored in operating system locations where they are protected by access rights against modification by malicious software with standard user rights. The only exceptions here are scarddlg.dll that interfaces with the local
4.4. EXAMPLE OF AN ARCHITECTURAL DESCRIPTION 85
Figure 4-3: Executable data components of SCRSetup.exe interfacing with the local hu- man user
human user and winscard.dll that could be substituted when linked with an incomplete reference. Strictly speaking, the arrows in the figure are an abbreviation for a reference connector with a reference component as target pointing a Reference rule–Search order to an executable data component. In addition, a filled circle represents a Data target role, a simple circle stands for a Data source role. There are no special access permissions set for these data components.
In figure 4-3 we present which components of the application communicate with the local human user via a shared user interface. Since the shared user interface does not offer protection against interference by other processes, each of the components can possibly receive malformed or forged input and must implement validation routines for the input it receives. An arrowhead represents a data target role. Dotted lines represent executable connectors, i.e., the call graph from figure 4-2.
The complete access control configuration is not shown for this sample. All components of the application enjoy the same level of protection, being either Access-observe ∧ Access- invoke or Access-modify ∧ Access-observe ∧ Access-invoke for standard users, depending on the location selected during install in the Microsoft Windows operating system file system.
Chapter 5
Formal model of generic computer
system
Chapter summary: In this chapter we present our model of a generic computer system and malware attacks in the formal specification notation Z . We develop our formal model based on the model derived from the Common Criteria security functional requirements in chapter 4. Its scope is a single system, e.g., a workstation in which benign and malicious applications co-exist. This restriction points out the contrast to large networks with many hosts – which are not the focus of this work. The formal model contains all the structures needed to capture a program’s architecture (i.e., its components and their relationships) and a malicious process attempting to violate security requirements of the program.
We start with a justification for the use of Z , followed by a bottom-up presentation of our formal model. We adhere to established Z style, i.e., we start the specification with given sets and global constants, followed by a definition of state, initial state, and finally operations. The last section discusses limitations of the model.
5.1
Formal specification in Z
The formal specification notation Z is based on Zermelo-Fraenkel set theory and first order predicate logic (cf. e.g. [Spi92], [Jac97], [PST96], [BSC94], [Bow96]). It has been developed by the Programming Research Group (PRG) at the Oxford University Com- puting Laboratory (OUCL) and elsewhere since the late 1970s. It is now defined by an ISO standard. [Z00]
More on Z and its applications to formal (security) and software architecture mod- eling can be found in section 2.5.3. We model a program’s architecture according to [AAG95]. An architecture is modeled as components and connectors. The structure of our model presentation follows the established Z style of starting with given sets and global constants, then defining state, initial state, and finally operations.
The reader is advised that there is an index of all types and schema definitions on page 127. It can be used when browsing the specification to easily retrieve the location of used types and schemas.