wherec=¬active(A)∨ ¬scheduledT o(n, A).
For the erasure policies to work they have to be build into the middle ware (trusted code base). The middle ware must perform checks of the two predicates, each time the data is read or written to. These run-time checks are necessary as the availablity of a principal can never be guaranteed.
5.10 Decentralized Splitting
In the framework proposed so far, it has been assumed that a central splitter, which all principals have complete trust in, exists. However, this might not always be the case. If not, decentralized splitting can be applied.
Decentralized splitting means that every principal participating has a splitter.
They can then verify any split suggested by any other principal using this split-ter. The trust graph is also decentralized and every principal can access it. This can be achieved by each principal maintaining the global trust graph. The trust graph must be synchronized, so every principal has the same trust graph at all times.
Example 5.8 (Decentralized Splitting) Consider two principals, an online store and a customer. The customer does not trust the store, and vice versa.
Using decentralized splitting they are still able to make a transaction.
The store has a program, which transfers money from the customer’s account to the store’s account. This program is split by the store. The customer now uses his or her own splitter to check if the split is valid. If the split is valid, the customer knows that his personal information will be kept safe, as the split program will obey the policies imposed on the information. The transaction can then be carried out.
Compared to current scenarios for online trade, this allow you to engage in trans-actions, with stores you do not trust to protect your information. A significant improvement to the uncertainty of todays online transactions.
This concludes the theoretical description of the Secure Dynamic Program Par-titioning framework. In the next chapter, a design for a prototype is presented, which implements the concepts from this chapter.
Chapter 6
Design
Never put off till run-time what you can do at compile-time.
– D. Gries
Based on the theoretical concepts presented in previous chapters, a design will be developed, which shows how Secure Dynamic Program Partitioning can work in practice.
The design is a prototype, and is intended for experimenting with the concepts.
The design should, however, be kept as generic as possible, so it allows for future improvements and extensions.
The design will not be specific to any language. Modeling of the design, however, will follow the functional paradigm. Functional modeling is concise, precise, easy to understand, and can fairly easy be extended to imperative and object-oriented languages.
Before the design is specified, the design requirements will be listed.
6.1 Requirement Specification
In this section the requirements for our design are listed. The requirements are high level, and they leave room for design issues to be dealt with later on. Some of the terms and concepts are not explained when they are introduced. They will, however, be explained when the design is presented.
6.1.1 Information flow
An independent library with support for the Decentralized Label Model must be developed.
• Labels consist of a confidentiality and an integrity part.
• The operatorslowest upper bound (t),greatest lower bound (u), and less restrictive (v) must be supported.
• Labels must always be minimal, i.e. no superfluous policies exist.
• Principal identification must be extend-able. I.e. new id types can be introduced: number, certificate, etc.
6.1.2 Parser
• The parser must be able to parse sflow programs. Only well-typed sflow programs will be accepted.
• The parser produces anabstract syntax tree (AST) andsymbol table.
• The symbol table contains: type, label, and aDefinition-Use chain.
6.1.3 Verifier and Splitter
• The verifier can detect illegal data flow, both explicit and implicit.
6.1 Requirement Specification 69
• The splitter splits programs based on the AST, symbol table, trust model, and the principals currently active in the system.
• The trust model must be parameterized, i.e., different trust models can be used.
• If more than one possible split exist, the splitter must find the optimal split. The optimization component is also parameterized.
6.1.4 Trust model
• The trust model must support both confidentiality and integrity.
• The simple trust model from [ZZNM01] (cf. Section 5.3) and the proba-bilistic trust model from [SPJH06] (cf. Section 5.7) must be implemented.
6.1.5 Optimizer
• The optimizer must determine the optimal split, when multiple possible splits exist.
• Each optimizer component defines what is optimal.
• Specifically, optimization based on the metric from section 5.8.2 must be implemented.
6.1.6 System manager
A system manager tool will be developed, which is able to respond to changes in the network. Additionally, it must provide an interface for interaction with the user.
• Principals should be able to join and leave the network. When joining the trust graph must be updated. If necessary the program is re-split using the Splitter.
• Programs can be submitted either by principals, or loaded from a file.
• For testing purposes, it should be possible to load trust graphs from files.
• It should be possible to change trust model and optimizer.
6.1.7 Erasure policies
• The splitter must have the ability to add erasure policies to data.
• Themiddleware must support the two predicatesactive andassignedTo.
• Erasure policies must be added to data that is not assigned to its owner (only owner).
Based on these requirements, the system will be designed.