kerr_daniel_thesis.pdf

8/22/2019 Kerr_Daniel_Thesis.pdf

1/323

Space Computing with

Group Key AgreementBy

Daniel Robert Kerr, B.S.

A Thesis in Computer Science

Submitted to the Graduate Faculty of

Texas Tech University in Partial Fulfillment

of the Requirements for the Degree of

MASTER OF SCIENCES

Approved

Michael SobolewskiChairperson of the Committee

Phillip Smith

Yuan-Lin Zhang

Fred Hartmeister

Dean of the Graduate School

May, 2008


2/323

Copyright 2007

Daniel Robert Kerr


3/323

Texas Tech University, Daniel Robert Kerr, May 2008

ii

Acknowledgements

I would like to thank my advisor Dr. Michael Sobolewski. His efforts and knowledge have

helped me maintain a clear perspective on my goals, and accomplishments. I would also

like to thank Dr. Phillip Smith, Dr. Yuan-Lin Zhang for serving on my committee, and

supporting my work.

I would also like to thank my friends and family for allowing me to spend so much time

away from them. As well, I would like to thank my fiance Amy Petrovich for being

patient and always supporting.


4/323


iii

Table of Contents

Acknowledgements .............................................................................................................. ii

Abstract ............................................................................................................................... vi

List of Tables ...................................................................................................................... vii

List of Figures .................................................................................................................... viii

List of Diagrams ................................................................................................................... ix

List of Universal Modeling Language Diagrams .................................................................. xi

List of Abbreviations .......................................................................................................... xii

1. Introduction .................................................................................................................... 1

Problem Statement ......................................................................................................... 2

Thesis Outline .................................................................................................................. 2

2. Background and Literature Review ................................................................................. 4

Distributed Computing .................................................................................................... 4

Space Computing ......................................................................................................... 8

Encryption ..................................................................................................................... 12

Symmetric Encryption ............................................................................................... 12

Asymmetric Encryption ............................................................................................. 15

Key Agreement .......................................................................................................... 17

Packages .................................................................................................................... 19

Federated Intelligent Product Environment (FIPER) ..................................................... 20

Service Protocol Oriented Architecture (SPOA) ............................................................ 22

Service Object Oriented Architecture (SOOA) .............................................................. 22

Jini Network Technology ............................................................................................... 23

Service Oriented Computing Environment (SORCER) ................................................... 24

SGrid .......................................................................................................................... 26

3. Requirements Analysis .................................................................................................. 29

Space Environment ....................................................................................................... 29


5/323


iv

Dual Space Environment ........................................................................................... 31

Single Space Environment ......................................................................................... 31

Exertion Envelope ......................................................................................................... 32

Encryption ..................................................................................................................... 34

Symmetric Encryption ............................................................................................... 34

Asymmetric Encryption ............................................................................................. 35

4. Architecture and Design ............................................................................................... 36

Four Blocker .................................................................................................................. 36

Problem ..................................................................................................................... 36

Conclusion ................................................................................................................. 36

Objective .................................................................................................................... 36

Approach ................................................................................................................... 36

Schedule .................................................................................................................... 36

Benefits ...................................................................................................................... 37

Use Case Diagrams ........................................................................................................ 38

Component .................................................................................................................... 64

Entities ....................................................................................................................... 67

Existing Components ................................................................................................. 68

LOKI Components ...................................................................................................... 68

Component Diagrams ................................................................................................ 71

Interaction ..................................................................................................................... 80

Package .......................................................................................................................... 86

Class ............................................................................................................................... 88

Deployment ................................................................................................................... 98

Technical Architecture .................................................................................................. 99

Architectural Attributes .............................................................................................. 101

Availability ............................................................................................................... 101

Modifiability ............................................................................................................. 101


6/323


v

Performance ............................................................................................................ 101

Security .................................................................................................................... 102

Testability ................................................................................................................ 102

Usability ................................................................................................................... 103

Encryption Multi Diffie Hellman ............................................................................... 104

Data Store .................................................................................................................... 114

User Interfaces ............................................................................................................ 121

5. Validation .................................................................................................................... 129

Test Case ..................................................................................................................... 129

Verification, Validation and Accreditation .................................................................. 139

6. Conclusion ................................................................................................................... 142

7. Future Work ................................................................................................................ 144

Alternate Scalable Key Agreements ............................................................................ 144

Alternate Group Request Analysis .............................................................................. 144

Multiple Space Model ................................................................................................. 145

Replicated Group Components ................................................................................... 145

Bibliography .................................................................................................................... 146

Appendix A: Loki System Interfaces ................................................................................ 150

Appendix B: Loki API Specification ................................................................... ............... 167


7/323


vi

Abstract

Space computing environments, being inherently public, have an increasing need to be

secured. One way of successfully implementing security in a space computing

environment is through the use of groups. Although groups would successfully secure

the environment, there are several complications in group creation as well as the

method for encryption.

Location independent group Key Interactive management (LOKI) provides an efficient,

minimal framework for implementing groups in a space computing environment, thus

providing ironclad security, mobility, scalability, as well as group administration. In order

to show how Loki will do this, the following questions will be answered in this thesis:

Can a secure generic method for group creation be created for all spacecomputing environments?

Can all space computing functionality be maintained with the implementation ofgroups?

Is there an asymmetric encryption method that is scalable to larger numbers ofcontributing key pairs?


8/323


vii

List of Tables

1: Linda Functions ............................................................................................................... 9

2: Javaspace Functions ...................................................................................................... 10

3: Symmetric Key Algorithms ............................................................................................ 14

4: Use Case Template 1 - Create Group ............................................................................ 40

5: Use Case Template 2 - Leave Group ............................................................................. 42

6: Use Case Template 3 - Join Group ................................................................................ 44

7: Use Case Template 4 - Get Group User Agent .............................................................. 47

8: Use Case Template 5 - Pickup Exertion ........................................................................ 49

9: Use Case Template 6 - Drop Exertion ........................................................................... 51

10: Use Case Template 7 - Execute Exertion .................................................................... 53

11: Use Case Template 8 - Get Admin User Agent ........................................................... 56

12: Use Case Template 9 - Delete Worker ........................................................................ 58

13: Use Case Template 10 - Delete Exertion .................................................................... 60

14: Use Case Template 11 - Delete Group ........................................................................ 62

15: Client Mode Encryption Timings ............................................................................... 104

16: Server Mode Encryption Timings .............................................................................. 105

17: Multi Diffie Hellman Group Size Timings .................................................................. 106


9/323


viii

List of Figures

1: NASA Cluster ................................................................................................................... 6

2: Grid Computing ............................................................................................................... 6

3: Peer to Peer Computing .................................................................................................. 7

4: Pipe Cryptography ........................................................................................................ 89

5: Multi Diffie Hellman Client Mode Time Curve ............................................................ 106

6: Multi Diffie Hellman Server Mode Time Curve ........................................................... 107

7: Multi Diffie Hellman Compound Key Creation Algorithm .......................................... 109

8: SGrid Execution Activity .............................................................................................. 130

9: Loki SGrid Execution Activity ...................................................................................... 132

10: Sargent's Circle .......................................................................................................... 140


10/323


ix

List of Diagrams

1: Javaspace Functions ...................................................................................................... 11

2: Symmetric Encryption v0.1 ........................................................................................... 13

3: Asymmetric Encryption v0.1 ........................................................................ ................. 16

4: Diffie-Hellman Key Exchange ....................................................................... ................. 18

5: FIPER Organizational Architecture ................................................................................ 21

6: Service Object-Oriented Architecture .......................................................................... 23

7: Service Oriented Architecture ...................................................................................... 25

8: SORCER Technical Architecture .................................................................................... 26

9: SGrid Component .......................................................................................................... 27

10: SGrid Technical Architecture ...................................................................................... 28

11: Dual Space Environment ............................................................................................. 31

12: Single Space Environment .......................................................................................... 31

13: Exertion Envelope v0.1 ............................................................................................... 33

14: Object to Exertion Envelope v0.1 ............................................................................... 34

15: LOKI Technical Architecture ...................................................................................... 100

16: Complementary Compound Key Protocol ................................................................ 112

17: Shared Key Generation Protocol .............................................................................. 113

18: LOKI Group Data Store v0.1 ...................................................................................... 118

19: LOKI Group Data Store v0.2 ...................................................................................... 120

20: Loki Group User Agent Group Display ...................................................................... 122

21: Loki Group User Agent Take Display ......................................................................... 123

22: Loki Group User Agent Write Display ....................................................................... 124

23: Loki Admin User Agent Main Display ........................................................................ 125

24: Loki Admin User Agent Group Display ...................................................................... 126

25: Loki Admin User Agent Member Display .................................................................. 127

26: Loki Admin User Agent Exertion Display .................................................................. 128


11/323


x

27: SGrid User Agent General Display ............................................................................ 134

28: SGrid User Agent Include Display ............................................................................. 135

29: SGrid User Agent Execution Display ......................................................................... 136

30: SGrid User Agent Context Display............................................................................. 137

31: SGrid User Agent Results Display .............................................................................. 138


12/323


xi

List of Universal Modeling Language Diagrams

1: Four Blocker .................................................................................................................. 37

2: uc LOKI .......................................................................................................................... 38

3: uc LOKI Group Creation ................................................................................................ 39

4: uc LOKI Execution .......................................................................................................... 46

5: uc LOKI Administration ................................................................................................. 55

6: cmp LOKI ....................................................................................................................... 64

7: cmp LOKI Group Creation ............................................................................................. 71

8: cmp LOKI Administration .............................................................................................. 73

9: cmp LOKI Execution ...................................................................................................... 77

10: sd LOKI Group Creation ............................................................................................... 80

11: sd LOKI Administration ............................................................................................... 82

12: sd LOKI Execution ........................................................................................................ 84

13: pkg LOKI ...................................................................................................................... 86

14: pkg sorcer.core.loki.crypt ........................................................................................... 88

15: pkg sorcer.core.loki.db ............................................................................................... 91

16: pkg sorcer.core.loki.group .......................................................................................... 92

17: pkg sorcer.core.loki.key .............................................................................................. 94

18: pkg sorcer.core.loki.member ...................................................................................... 95

19: pkg sorcer.loki.admin.ui .............................................................................................. 96

20: pkg sorcer.loki.group.ui .............................................................................................. 97

21: deployment LOKI......................................................................................................... 98

22: act LOKI ..................................................................................................................... 110


13/323


xii

List of Abbreviations

API Application Programming Interface

FIPER Federated Intelligent Product Environment

JCE Java Cryptography Extension

LOKI - Location Independent Group Key Interactive Management

P2P Peer to Peer

SGrid SORCER Grid

SOA Service Oriented Architecture

SOOA Service Object Oriented Architecture

SORCER Service Oriented Computing Environment

SPOAP - Service Protocol Oriented Architecture


14/323


1

Chapter 1

Introduction

Security in networking has been a serious issue since the dawn of networked systems.

With the increasing trust in computers for the use of storing sensitive data (account

numbers, social security numbers, criminal records, health history, etc) security has

drastically increased in order to coordinate with the importance of the information

being exchanged. Along with the growth in computer networking is the growth in

distributed computing. Distributed computing presents many challenges to the world of

computer science.

A rather new concept in distributed computing is the concept of space computing.

Space computing helps to solve several of the significant problems with distributed

computing, but still leaves room for improvement. The space computing environment

starts by being completely public so that all services can access objects in the publicly

shared space. The space broker is also oblivious to who is a member of the space

environment.

The question at hand is whether or not a minimal solution to public space encryption

that implements group creation and maintenance services can be implemented in a


15/323


2

space computing environment. This will be done by developing a methodology and

framework for all space computing environments, and then proven by coding the

methodology in a particular space environment. The test case will be coded in the

SORCER (Service Oriented Computing Environment) developed by Doctor Michael

Sobolewski at Texas Tech University.

The Loki framework will successfully introduce group management, and exertion level

encryption in an ad hoc public space computing environment.

Problem Statement

In space computing, all items in the space are inherently public, all members are ad hoc,

and the service broker does not explicitly know group members. Thus, a secure

communication that can be initiated by a space service broker with management of ad

hoc group of service is needed.

Thesis Outline

This thesis is divided into seven chapters, each with its own intent. Chapter one gives a

basic introduction to the problem the thesis is trying to solve, as well as an outline of

the thesis. Chapter two provides background information and literature on the topics

discussed throughout this paper. Chapter three discusses the requirements necessary to

implement groups in a generic space computing environment. Chapter four gives the

design and modeling of the Loki framework. Chapter five discusses the means for


16/323


3

validation, and the test case. Chapter six describes the conclusions reached through the

research. Lastly chapter seven discusses future work in the implementation of groups in

a generic space computing environment.


17/323


4

Chapter 2

Background and Literature Review

Distributed Computing

Distributed computing is an area in computer science that is not only increasing in

popularity but also in importance. Distributed computing is the process of dividing a task

into individually computable smaller tasks and deploying them or distributing them to

multiple systems, thus creating one large system. Tanenbaum defines a distributed

system as a collection of independent computers that appear to the users of the

system as a single computer (Tanenbaum and Van Steen 2002). The main difference

between a distributed system and a series of networked computers is that a distributed

system tries to hide the fact that it is a composition of individual computing units

(Nadiminti, Dias de Assuncao and Buyya n.d.). Although this is the case, the process of

connecting computers through networking in order to establish collaborative

computation is a job that is rather complex, but increasingly important. The following

paragraph from Antony Davies succinctly describes the development of distributed

systems and why they are emerging as much as they are in terms of computer science

theory and modern economics.

Over the past 30 years, there has been a decentralization occurring in the production

of computational power. Large, stand-alone supercomputers have been overtaken by

cluster computers networks of personal computers that are linked together to provide

more power than traditional supercomputers at a fraction of the cost. The next step in


18/323


5

the evolution of cluster computers has been the advent of Internet distributed computing

an industry in which a computational intermediary purchases idle processing power

from individual personal computer owners (via Internet connection), bundles the power,

and resells the power as high-performance computation.6 This industry has emerged dueto a confluence of events: (1) following Moores Law, the computational power of

personal computers is doubling (on average) every 18 months; (2) digital

communications speed is doubling every 12 months;7and (3) over time, the performance

gap between high-performance computers (HPC) and personal computers (PC) has

closed due to dramatic improvements in integrated circuit technology.8 The combination

of these events creates an environment in which hardware has become so inexpensive

that personal computer owners can afford to purchase levels of computational power

and bandwidth that satisfy their peak demands. Because computation and bandwidth

demand is extremely peaky, as PC owners purchase hardware to satisfy peak demand,the amount of idle computational power and bandwidth increases dramatically.

(Davies 2004)

Some of these distributed systems include but are not limited to clusters, grids, peer to

peer networks, and distributed storage systems (Nadiminti, Dias de Assuncao and Buyya

n.d.). Several of these are shown in the following figures. Clusters are a form of

connecting sub systems, whether they are personal computers, servers,

supercomputers, etc, together via a network interface in order for them to act as a

single system (Nadiminti, Dias de Assuncao and Buyya n.d.). Grids are much like clusters

in that they are a connection of subsystems except that grids balance performance with

task load, in order to compute the given process in the fasted amount of time. Peer to

peer distribution has been used in media sharing, research, and is the process of linking

terminals directly to each other via the network without central management.


19/323

Figure 1: NASA Cluster

Figure 2: Grid Computin

Texas Tech University, Daniel Rob

6

(Computational Science & Engineering Resear

rt Kerr, May 2008

ch Institute n.d.)

(Yao 2006)


20/323

Figure 3: Peer to Peer C

Distributed computing h

money in most cases wh

equivalent computing po

systems, which allows le

are both cost effective a

inherent redundancy (N

benefits there are still pi

based Peter Deutschs ei


7

mputing

(Peer-to-Peer (P2P)

s been shown to be a cost effective solution th

n compared to the alternative of purchasing n

wer. Distributed computing also allows for the

s to be wasted. In addition to the fact that dist

d conserve resources, they are scalable and al

diminti, Dias de Assuncao and Buyya n.d.). Reg

falls to be aware of in distributed computing.

ht fallacies of computer networking. They are

rt Kerr, May 2008

omputing 2006)

at actually saves

ew systems of

reuse of

ributed systems

o provide

ardless of these

hese would be

as follows:


21/323


8

1. The network is reliable.

2. Latency is zero.

3. Bandwidth is infinite.

4. The network is secure.

5. Topology doesn't change.

6. There is one administrator.

7. Transport cost is zero.

8. The network is homogeneous.

(Rotem-Gal_Oz n.d.)

Several implementations of distributed systems attempt to resolve some if not all of

these issues. CORBA and DCOM attempt to resolve these by implementing a software

layer to moderate the use of different platforms and languages (Nadiminti, Dias de

Assuncao and Buyya n.d.).

Space ComputingSpace computing is a paradigm for the development of parallel and distributed

computing, which originated from the language Linda. Linda was the first language to

introduce a logically global associative memory structure known as a tuplespace.

Multiple client-like services access the global tuplespace for the mutual exchange of

tuples, Lindas object container. In order to do this, Linda requires that both the tuple

and the tuplespace be public. This allows for global access but inherently causes security

vulnerabilities. In Linda specifically, there are four main functions used for the exchange

of objects with the space. They are as follows:


22/323


9

Table 1: Linda Functions

out outputs a tuple from a process into the tuple space

in removes a tuple from the tuple space and returns it to a process,

blocking if a suitable tuple cannot be foundrd returns a copy of a tuple from the tuple space to a process, blocking if a

suitable tuple cannot be found

(Wells n.d.)

The use of these four functions for tuple object manipulation eliminated several

inherent problems with distributed computing. By client services requesting tuple

objects when they are free to do so, the problem of load balancing is reduced out.

Slower services may request less tuples per time period, but there performance will not

impact or hinder the performances of faster services, who may request more tuples per

time period. As well, Linda provides mutual exclusion. All client services first remove a

tuple from the public domain tuplespace before making any modifications to it. This

only allows for one object to access the data at a time, thus preventing invalid data

without the use of semaphores, mutexes, or any other form of data blocking.

JavaSpaces, being based on tuplespaces from LINDA, adopt the same functionality with

different nomenclature. The idea of a tuplespace is known as an object space, a tuple is

known as an object, and the functions specified above are as follows:


23/323


10

Table 2: Javaspace Functions

write outputs an object into the object space

read returns a copy of an object from the object space to a process, and

blocks if desired object cannot be foundtake removes an object from the object space and returns it to the

requesting process, and blocks if desired object cannot be found

(Arnold, Freeman and Hupfer 1999)


24/323

Diagram 1: Javaspace Fu

Other adaptations use th

space environments tho

originated. These imple

and these have been exe

Space computing is inter

balancing, but with the i

drastically growing in po

computing solution.


11

nctions

(Arnold, Freeman

e same core functions, with slightly different n

gh, do maintain the core framework and bene

entations are Linda, Rinda, Tuple Spaces, TSpa

cuted in C, Prolog, Smalltalk, Ruby, Python, an

sting because not only does it have mutual ex

creasing rate at which information can be pas

ularity. It is proving to be a beneficial low cos

rt Kerr, May 2008

nd Hupfer 1999)

menclature. All

its that Linda

ces, JavaSpaces

Java.

lusion and load

ed, it is

distributed


25/323


12

Encryption

Encryption is the process of taking a designated segment of data, and mutating it in a

standard way so the data is no longer logical. This is usually done with a standard

method that may or may not use a key to do so. In modern day cryptography there are

many different methods of encryption but the two most researched for the Loki

platform are symmetric and asymmetric, two of the largest families of cryptography.

Symmetric Encryption

Symmetric encryption is simply the use of a single shared key for the encryption of

mutually shared data. The major benefits of symmetric encryption are that it takes a

relatively small key to ensure a high level of security, that both encryption and

decryption are fast processes, and lastly there are many well established symmetric

encryption methods native to java, c, and many other languages making development

simpler. Although powerful and fast, the use of symmetric encryption creates a

problem when it comes to the distribution of the shared key. Even though the

encryption is secure even with a rather small key, it truly creates a problem on how to

distribute the key so that the key is not accidentally leaked out.


26/323


13

Diagram 2: Symmetric Encryption v0.1

It is for this reason that symmetric encryption is often mixed with other forms of

cryptography. A common practice is to use asymmetric encryption to encrypt the

symmetric shared key. This process will be explained in greater detail later in this

section. The following table shows a list of symmetric key encryption algorithms, along

with their creator, and key size.

Service A

Encrypted

Data

Service B

Encryptor

Decryptor

Shared Key


27/323


14

Table 3: Symmetric Key Algorithms

Cipher Author, Year Key length Comments

DES - Data

Encryption Standard

IBM, 1970, in

1977 as FIPS 46-2standard

DES 56 bits, 64-

bit block

Originally known as

Lucifer. Too weak forgood security

TripleDES or

DESede

IBM, 1999 as FIPS

46-3 standard

168 bits (112

effective)

DESede is three rounds

of DES (encryption,

decryption, encryption)

RC4 - Rivests Code

4

Ron Rivest, 1987 1-2048 bits,

typically either 40

or 128 bits

A stream cipher used in

SSL implementations

RC5 - Rivests Code

5

Ron Rivest, 1994 Up to 2040 bits,

typically 128 or

256 bits

Improved RC4

RC6 Rivest, Sidney,

and Yin, 1996

Up to 2040 bits,

typically 128 or

256 bits

A block cipher based on

RC5 designed to meet

the requirements of the

AES

IDEA -International

Data Encryption

Algorithm or IPES

Improved Proposed

Encryption Standard

Xuejia Lai and

James L. Massey,

1991

128 bits, 64-bit

block

A block cipher, patent

protection, slow

Blowfish Bruce Schneier,

1993

32 bits to 448

bits, 64-bit block

A block cipher, much

faster than DES andIDEA

Twofish Bruce Schneier,

John Kelsey, Doug

Whiting, David

Wagner, Chris

Hall, Niels

Ferguson, 1998

Up to 256 bits,

128-bit block,

typically

128, 192, or 256-

bit key

A block cipher by

Counterpane Labs. It

was one of the five AES

finalists

AES (Rijndael) Joan Daemen and

Vincent Rijman,

2000

128, 192, and 256

bits, blocks with a

length of 128,192 or 256 bits.

AES mandates a block

size 128 bits and a

choice of key size: 128,192 and 256.

(Sobolewski, Secret Key Cryptography 2007)


28/323


15

In symmetric key encryption the level of security is directly related to the size of the key,

so it is easy to see that algorithms like AES, Blowfish, and RC6 are more secure than say

DES.

Asymmetric Encryption

Asymmetric Encryption is a more complex level encryption than that of symmetric

encryption, but complexity comes with its benefits. In asymmetric encryption each

party in the information exchange has a public private key pair. The public key is readily

accessible to any other party who wants access to it and the private key is stored locally.

The main difference between asymmetric and symmetric is that the key used for

encryption and decryption is a shared key that is generated from the accessing

members private key and the public keys from the other members in the transaction.

This allows us to never actually pass the encryption/decryption key. We only pass

components of the recipe that individually do not reveal anything. The major downfalls

to using asymmetric encryption over symmetric encryption are that of computation

complexity and key size. Not only do the computations take longer time, but the

asymmetric keys are typically ten times larger than there equally secure symmetric

encryption counterpart.


29/323


16

Diagram 3: Asymmetric Encryption v0.1

McEliece Public Key Encryption

McEliece Encryption is based on the fact that solving arbitrary linear code is of NP-hard.

The transform of the solving code serves as the public key whereas the linear code itself

solves as the private key (Menezes, Oorschot and Vanstone 1996). The McEliece

Encryption is known for being the first public key encryption to use true randomization

for cryptography. Although very efficient, the McEliece Encryption public keys are very

large and thus have not been given much attention. The following shows the algorithm

for encryption and decryption using McEliece Encryption.

Service A

Private Key

Encrypted

Data

Service B

Private Key

Encryptor

Decryptor

Locally Calculated

Shared Key

As

Public

Key

Bs

Public

KeyLocally Calculated

Shared Key


30/323


17

Key Agreement

Key agreements are a method of cryptography in which parties agree for the method in

which they will share a key. Each member of a key agreement should impact the key,

and any outside member to the agreement should not be able to logic, or calculate the

McEliece Public-Key Encryption Algorithm

Summary: B encrypts a message m for A, which A decrypts.

Encryption: B should do the following:

1) Obtain As authentic public key ( b G; t).2) Represent the message as a binary string m of length k.3) Choose a random binary error vector z of length n having at most t 1s.4) Compute the binary vector c = mbG + z.5) Send the ciphertext c to A.Decryption: To recover plaintext m from c, A should do the following:

1) Compute bc = cP1, where P1 is the inverse of the matrix P.2) Use the decoding algorithm for the code generated by G to decode bc to bm.3) Compute m = bmS1.Proof:

Since bc = cP1 = (mbG + z)P1 = (mSGP + z)P1 = (mS)G + zP1; and zP1 is a vector

with at most t 1s, the decoding algorithm for the code generated by G corrects bc tobm = mS. Finally, bmS1 = m, and, hence, decryption works.

(Menezes, Oorschot and Vanstone 1996)


31/323

key. As well Key Agreem

between the parties in t

Diffie Hellman Key Ag

Diffie Hellman is a specifi

prime numbers and the

encrypt the information

communication between

Diagram 4: Diffie-Hellm

As you can see in the gra

Alices private key is a a

public key is gb. The exc


18

nts should not require any previously shared i

e agreement.

reement

c implementation of asymmetric encryption th

odulus function. Diffie Hellman in its truest fo

etween two parties. The following graphic sh

Alice and Bob.

n Key Exchange

(Diffie-Hellman K

phic the encryption is based on the idea of fun

nd her public key is ga, whereas bobs private

hange can happen because:

rt Kerr, May 2008

formation

at is based on

r is meant to

ws the

y Exchange n.d.)

tion equality.

key is b and his


32/323


19

(ga

mod p)b

(mod p) = (gb

mod p)a

(mod p)

It is this fact that allows the encryption to occur without passing the shared key.

Expansions of Diffie Hellman attempt to add more than two parties to the key creation.

This is completed by expanding on the original equation, replacing the private key with

the newly created shared key from the two party key creation. This is increasingly more

complex than that of the two party Diffie Hellman key creation. The three party key

creation is shown below.

(gab

mod p)c

(mod p) = (gbc

mod p)a

(mod p) = (gca

mod p)b

(mod p)

gab

= (ga

mod p)b

(mod p) = (gb

mod p)a

(mod p)

gbc

= (gb

mod p)c

(mod p) = (gc

mod p)b

(mod p)

gca

= (gc

mod p)a

(mod p) = (ga

mod p)c

(mod p)

The complexity of adding more parties to the agreement is linear in nature. Even

though this is the case, there is no standard method for asymmetric Diffie Hellman

based encryption beyond two parties.

Packages

Java Cryptography Extension

The Java Cryptography Extension adds security functionality to the core java language.

The API includes implementations of encryption methods, decryption methods,

password based encryption, ciphers, key agreements, and message authentication code.

Of these, we will be most interested in the key agreements, encryption, and decryption


33/323


20

policies, including ElGamal, Diffie Hellman, Elliptic Curve Diffie Hellman, DES, RSA, and

TripleDES.

Bouncy Castle

Bouncy Castle is a security package much like the JCE but with a larger set of security

and cryptographic services. Bouncy Castle provides both a java and a C# package which

supply the same services. Much like the Java Cryptography Extension we are most

interested in key agreements, encryption and decryption services, which include

ElGamal, Diffie Hellman, Elliptic Curve Diffie Hellman, DES, RSA, and TripleDES. In

comparison to the JCE, Bouncy Castle has the same functionality but is a little slower in

most implementations.

Federated Intelligent Product Environment (FIPER)

FIPER describes an environment in which everything is located on a network, and

everything on the network is viewed as a service. In this environment all inter service

activity utilizes a special object known as an exertion interface, and all objects that

execute exertions are known as servicers. A compound group of exertions and

information can be stored in a service context. A job in FIPER can then be broken down

into a federation of services where federation members are linked to processes, which

are in turn linked to tasks and contexts (Sobolewski, SORCER Publications 2002).


34/323

Diagram 5: FIPER Organi

The organization chart o

It uses network technolo

order to manage and lau

FIPER are equally as scal

combination of these co

centricity, and web centr

implementation (Sobole


21

zational Architecture

(Sobolewski, SORCER P

the FIPER environment shows how FIPER is sc

gies like Jini and Rio, which will be described in

nch a scalable number of services. The other c

ble and each maintains focus on their specific

ponents helps FIPER to maintain service centr

icity. FIPER is also neutral to service location, p

ski, SORCER Publications 2002).

rt Kerr, May 2008

blications 2002)

lable in nature.

greater detail, in

mponents in

ask. The

icity, network

rotocol and


35/323


22

Service Protocol Oriented Architecture (SPOA)

In SPOA providers and requestors where a communication protocol between the two

objects is fixed and known beforehand. This protocol is initiated as a generic protocol,

large enough to handle any network communication, which in some cases can lead to

inefficiency. A requester in SPOA can use the established protocol as well as a service

description, usually the service name, to obtain a proxy for binding to the provider.

Typically the requestor and provider need to know the location of the service registry,

either by URL or IP address. (Sobolewski, SORCER Publications 2007)

Service Object Oriented Architecture (SOOA)

SOOA adopt the provider, requestor, and proxy network objects from SPOA with several

key differences. The proxy implements the same interfaces as the provider and remains

registered with the registry awaiting a requestor. Since the requestor receives the active

surrogate object from the service registry, the bind operation is not needed. The

protocol neutral SOOA environment requires lookup services as well as standardized

interfaces do to the dynamic nature of the architecture. Providers in SOOA can really be

viewed as separate network objects that find each other through a service registry, and

communicate through message passing. (Sobolewski, SORCER Publications 2007)


36/323

Diagram 6: Service Obje

Jini Network Tech

Jini is a Java based suppo

systems consisting of fed

to Jini 2006). Jini is prim

providing support for ser

etc. These concepts are i

Starter Kit v2.0.1 2004)


23

t-Oriented Architecture


ology

rt technology for the construction of secure,

erations of well-behaved network services and

rily designed for the building of service orient

vice creation, lookup services, discovery, leasin

mplemented in the Jini Technology Starter Kit.

rt Kerr, May 2008

blications 2007)

istributed

clients. (Intro

d architectures

g, code mobility,

(Jini Technology


37/323


24

Service Oriented Computing Environment (SORCER)

SORCER is developed on top of FIPER and includes design features from both SOOA and

SPOA. SORCER uses dynamic discovery protocols to locate available registries (lookup

services) as defined in the Jini architecture. Neither the requestor who is looking up a

proxy by its interface nor the provider registering a proxy needs to know specific

locations, (Sobolewski, SORCER Publications 2007). The combination of SOOA and

SPOA in the SORCER environment leads to SOA, or Service Oriented Architecture. The

SOA process of discovery is shown in the following diagram where the service requestor

uses find discovery to get the published proxy of the desired service provider. It is

passed back to the service requestor where a bind and execute is then performed by the

service requestor on the service provider.


38/323

Diagram 7: Service Orie

SORCER implements exe

distribution in the netwo

discover, leasing, joining,

main focus of SORCER be

environment. (Sobolews


25

ted Architecture


tion based programming in order to handle th

rk. SORCER does all this by adopting the Jini se

and etc to mutate Jinis focus of service mana

ing exertion oriented programming and exerti

i, SORCER Publications 2007)

rt Kerr, May 2008

blications 2007)

metasystemic

antics of

ement to the

n execution


39/323


26

Diagram 8: SORCER Technical Architecture

(Sobolewski, SORCER Publications 2002)

SGrid

The SORCER Grid or SGrid is a federated service metacomputing grid environment. The

SGrid uses a combination of task exertions, job exertions, and service exertions, that

when combined with dynamically bound service providers needed, form an exertion

federation. This differs from the object oriented paradigm of the exertion space in

several ways. In the object oriented paradigm the object space is the program and in

SGrid the object space is the execution environment, hosted by a network of computers

(Sobolewski, SORCER Publications 2007). The environment is described in the following

passage, The overlay network of service providers is called the service provider grid

and an exertion federation is called a virtual metacomputer. The metainstruction set of

the metacomputer consists of all operations offered by all service providers in the grid.


40/323


27

Thus, a service-oriented program is composed of metainstructions with its own service-

oriented control strategy and service context representing the metaprogram

parameters. (Sobolewski, SORCER Publications 2007).

The following diagram shows the component architecture of SGrid. As discussed in the

previous paragraph the combination of the job exertions and providers such as the

Jobber, Grider, Cataloger, Caller, File Storer, Spacer, and Transaction Manager, come

together to form the SGrid exertion space.

Diagram 9: SGrid Component(Alger n.d.)


41/323


28

Diagram 10: SGrid Technical Architecture

(Malladi-Venkata, Rai and Sobolewski, SORCER Publications 2004)


42/323


29

Chapter 3

Requirements Analysis

Space Environment

In developing the methodology for Loki, there were two major choices for space

implementation. The first being a single space environment, and the second being a

dual space environment. The dual space environment consists of an exertion space and

a Loki management space. The separate spaces allow group management and creation

to happen in a secure environment outside that of the public exertion space. Once

group creation is complete than the exertion space is used in its normal fashion, for

writing reading and taking encrypted exertions. The Loki management space would at

this point be used for group administration, functions like the deletion of a worker in

which a new group key needs to be assembled. The Loki management space would be

closed to group administrative services in order to ensure security, but would not

mandate that exertions be encrypted for trusted services. In comparison, the single

space environment uses the public exertion space for both group administration and

exertions reading writing and taking. One of the main differences is that any

administrative exertion placed into the public space environment will be encrypted

asymmetrically with the key of its receiver.

Loki group key implementation utilizes the single space environment. Although there is

more overhead computation in the encryption and decryption of administrative


43/323


30

exertions, the use of a single space is beneficial in many ways. The use of single space

decreases coupling since all service objects will communicate with the space, regardless

of environment. Using one space also allows for Loki to be used in any space computing

environment including java spaces, t-spaces, tuple spaces, etc, thus aiding in the

scalability of the Loki methodology. Lastly the use of a single space demands that

security be enforced on the service/exertion level, as opposed to the space level

security needed in the dual space environment. Although service/exertion level security

demands more overhead encryption and decryption, it is inherently less vulnerable to

attack. In addition, if compromised service/exertion level security only allows for access

to minute components, while a breach in space level security would allow for total

information access. For these three reasons, the more complex single space

environment was chosen for the Loki group key solution.


44/323


31

Dual Space Environment

Diagram 11: Dual Space Environment

Single Space Environment

Diagram 12: Single Space Environment

Exertion

Space

LOKI

User

A ents

LOKI Group

Services:

EncryptionManager

Key Generator Executor Dispatch

Manager

Services

LOKI

Encryption

Layer

Exertion

Space

LOKI

Space

LOKI

User

A ents

LOKI Group

Services:

EncryptionManager

Key Generator Executor Dispatch

Manager

Services


45/323


32

Exertion Envelope

Loki utilizes the idea of an exertion envelope in its message passing communication.

This means that all volatile content in a message is separated from the non volatile

information so that the volatile information can be encrypted with the appropriate

encryption method. The unencrypted information acts as the address for the private

encrypted data, forming the envelope model. This allows data to be passed more

efficiently between members in the communication transaction while maintaining

confidentiality of all private data.

Exertion envelopes maintain data integrity due to the fact that the raw data is only

encrypted and decrypted once in a transaction. The original sender will package by

sending it to the Loki Encryption Manager and addressing the envelope. All intermediary

members will only need to reference the public address information in the envelope and

the final receiver will unpack the data by sending it to the Loki Encryption Manager with

the correct key. In comparison to the alternative method of having the address

information encrypted with the raw data, exertion envelopes guarantee lossless data

transfer and decreased coupling, due to the fact that the alterative would have to

decrypt the entire data package with each transfer. The alternative method would have

a high probability of data corruption, increased coupling, as well as the increased

transfer time due to the number of times the data would have to be unencrypted.


46/323


33

Diagram 13: Exertion Envelope v0.1

Exertion Envelopes are a standard data structure in the proof case space computing

environment SORCER, but are easily implemented in all space computing environments.

The idea of an exertion or an object is a standard structure in space computing, and the

exertion envelope is simply a nested object. The original object, which is now

encrypted, is placed inside of an unencrypted object with some addition address data.

The only requirements necessary to implement an exertion envelope, are that the space

computing environment desired support nested object structures.

Exertion Name:

To:

From:

Encrypted

Data


47/323


34

Diagram 14: Object to Exertion Envelope v0.1

Encryption

The goal of Loki is to implement secure channels for group members to exchange

sensitive data, and the grunt of this task falls on the ability to encrypt the groups data,

and retrieve it when necessary, while maintaining the inability of outside threats being

able to crack the group data. This being said it was apparent, early on in the

development of Loki, that a strong and rather complex encryption method would be

necessary.

Symmetric Encryption

If Loki were to use symmetric encryption it would first have to start at the group request

level. The Loki Group Manager would then have to send the group information to the

Loki Key Generator which would develop the symmetric key for encryption and

decryption and either dispatch this key to all group members, or dispatch it to the Loki

Exertion Name:

To:

From:

Encrypted

Object

Original

Un-Encrypted

Ob ect

Object

Exertion Envelope


48/323


35

Encryption Manager along with group information so the Encryption Manager would be

responsible for access validation. In the first case, there is security vulnerability in the

dispatching of the key, to which asymmetric encryption is needed to solve (which is

talked about in the next section). In the second case, even though the information is

encrypted you are not relying on the encryption for security; you are relying on the

ability of the Loki Encryption Manager to authenticate the service.

Asymmetric Encryption

If Loki were to implement asymmetric encryption, the process would have to start with

the service requestor requesting an exertion be executed. The exertion would be

dropped to the Group Manager who would analyze and dispatch an invitation to all

services that need to be in the group. The Group Manager would then receive the

group invitation responses, and dispatch the combined public keys of all group members

who accepted the invitation. Each service would then be able to calculate the shared

key with the key generator by passing its private key and the set of public keys. This

would allow services to encrypt and decrypt group data without having to pass the key,

thus preventing possible corruption.


49/323


36

Chapter 4

Architecture and Design

Four Blocker

Problem

Shared spaces are inherently public Members in space computing can come and go (ad hoc) Space service broker doesnt explicitly know group members (workers)

Conclusion

Secure Communication that can be initiated by a space service broker with management

of ad hoc group of services is needed

Objective

A group key agreement framework (Loki) for space computing environments (Loki

Location independent group Key Interactive management)

Approach

Literature Reviewo Group Key Agreemento Space Computing

Analysis of space group management Loki requirements and architecture Develop Loki methodology Loki design Loki implementation Verification and validation of Loki

Schedule

Literature Review August 2007

Analysis September 2007

Loki requirements and architecture October 2007

Develop Loki methodology November 2007


50/323

Loki design

Loki implementat

Verification and v

Thesis Defense

Benefits

Secure ad hoc sp Secure space exe Simplified manag Secure communi Friendly and intui

Friendly and intui

UML Diagram 1: Four Bl


37

December 2007

ion January 2008

alidation of Loki February 2008

March 2008

ce group management

tion oriented programming model

ement of group keys

ation between inherently public object space

tive user agent attached to space service broke

tive user agent for space-oriented grid computi

cker

rt Kerr, May 2008

r

ng


51/323


38

Use Case Diagrams

The Loki use cases fall into three major components. The first is group creation, which is

the most important of the three main components, and outlines the establishment and

protocol of the instantiation of a group. This is followed by the administration

component of the Loki framework, which outlines the management of group members

and group objects. This includes deletion, addition, and persistent data storage. The last

of the three major components is that of member execution, which outlines the

members interaction with the space.

UML Diagram 2: uc LOKI

The first classification of use cases that we will be addressing is that of the Group

Creation use cases. These are shown in UML Diagram 3.


52/323


39

UML Diagram 3: uc LOKI Group Creation


53/323


40

Table 4: Use Case Template 1 - Create Group

Goal in Context Successfully create a group in a space computing environment

Scope & Level Loki, Summary

Preconditions Submitter must be running in a Loki secured space computing

environment

Success End

Condition

Successful group creation

Failed End

Condition

Failed group creation

Primary,Secondary

Actors

Primary: SubmitterSecondary: Exertion Space, Worker

Trigger Submitters request

Description Step Action

1 Submitter dispatches a group creation exertion

2 Future group members are invited to group

3 Key is created based on qualified members

4 Group key is dropped

5 Results are generated

Extensions Step Branching Action

2a Worker leaves group

3a Worker joins group


54/323


41

Description

The group creation use case is initiated by a submitting service that will do so by

dispatching an initial exertion. The Loki framework will then manage this exertion and

send the appropriate invitations to the necessary group members. It will then receive

the members responses and create a key agreement based on the received responses.

At this point the group is created but all members need the necessary information to

generate the keys for themselves. This is the key point in the security of the Loki

framework; the key itself is not passed back out to member services, only superfluous

public data is broadcast out to member services. Once the public keys are dispatched,

the framework will then encrypt and handle the initial exertion.

Analysis

The group creation use case is extended by two worker use cases, leaving and joining a

group, which will be described in detail in subsequent descriptions. The group creation

use case is the most complex of all the use cases in the Loki framework, due to the fact

that it has multiple levels of dependency. The initial submission is made, and then the

actual dispatching of the initial exertion occurs after all invitations are sent, received,

and processed. This means that this will be the most time intensive part of the

framework, yet if completed successfully will make all other use cases and components

of the framework simpler.


55/323


42

Table 5: Use Case Template 2 - Leave Group

Goal in Context Successfully leave a group


Preconditions Must be running in a Loki secured space computing environment

Success End

Condition

Worker leaves a group

Failed End

Condition

Worker remains in group

Primary,

SecondaryActors

Primary: Worker

Secondary: Submitter

Trigger Worker chooses to leave a group


1 Pickup group join request exertion

2 Drop leave exertion

Description

The leave group use case is the workers response to the invitation sent in use case 1. In

this case the worker does not want to be a member of the group, for some reason local

to the worker. What will happen is that the worker will first pick up the group

membership request from the exertion space, and then write a leave group exertion in

the exertion space.


56/323


43

Analysis

The original idea for the Loki framework was to have the worker be able to leave a

group at any given time. Although this adds functionality, it adds unnecessary

complexity to the proof that groups can be implemented in order to secure a space

computing environment. It is for this reason that a worker can only leave a group in

response to the initial invitation upon group creation.


57/323


44

Table 6: Use Case Template 3 - Join Group

Goal in Context Successfully join a group



Success End

Condition

Worker joins a group

Failed End

Condition

Worker does not join group

Primary,

SecondaryActors

Primary: Worker

Secondary: Submitter

Trigger Worker chooses to join a group


1 Pickup group join request exertion

2 Drop join exertion

Description

The join group use case is the workers response to the invitation sent in use case 1. In

this case the worker wants to be a member of the group. What will happen is that the

worker will first pick up the group membership request from the exertion space, and

then write a join group exertion in the exertion space.


58/323


45

Analysis

The original idea for the Loki framework was to have the worker be able to request to

join a group at any given time. Although this adds functionality, it adds unnecessary

complexity to the proof that groups can be implemented in order to secure a space

computing environment. It is for this reason that a worker can only join a group in

response to the initial invitation upon group creation.


59/323


46

The next classification of use cases that will be discussed is those for group member

execution and exertion processing. These are shown in UML Diagram 4.

UML Diagram 4: uc LOKI Execution


60/323


47

Table 7: Use Case Template 4 - Get Group User Agent

Goal in Context Successfully open group user agent



Success End

Condition

Group user agent is successfully retrieved

Failed End

Condition

Group user agent retrieval fails

Primary,

SecondaryActors

Primary: Worker

Secondary: Exertion Space

Trigger Worker requests to open UA


1 Worker requests group user agent

2 User agent sends back UA


5a Worker picks up exertion

6a Worker drops exertion

7a Worker executes exertion

DescriptionThe open group user agent use case is initiated by a Loki Worker or User requesting to

see the User Interface from the Loki Group User Agent. The interface is published by


61/323


48

the Loki Group Manager (which will be described in the class diagram description), and

extends the functionality for group functionality monitoring.

Analysis

The group user agent allows for the monitoring of group services, and is helpful in

validation, verification, and accreditation. It is also helpful in the viewing the progress of

operations that take longer amounts of time. Even though this seems like a superficial

function of the Loki framework, it is valuable to success of group creation.


62/323


49

Table 8: Use Case Template 5 - Pickup Exertion

Goal in Context Successfully retrieve an exertion from a space computing

environment



Success End

Condition

Worker successfully retrieves exertion

Failed End

Condition

Worker does not retrieve exertion

Primary,Secondary

Actors

Primary: WorkerSecondary: Exertion Space

Trigger Worker requests exertion


1 Worker sends take request

2 Exertion space return encrypted exertion

Description

The pickup exertion use case is executed by the Loki Worker, who picks up an exertion

from the exertion space. The Loki Worker does so through the use of services provided

by the group manager, which monitors and logs the exertion pickup.


63/323


50

Analysis

The structure of having the Loki Group Manager monitor and log the picking up of

exertions in the group allows all monitoring to be local to one component, and aids in

decreasing coupling and increasing cohesion.


64/323


51

Table 9: Use Case Template 6 - Drop Exertion

Goal in Context Successfully drop an exertion from a space computing environment



Success End

Condition

Exertion is successfully dropped space

Failed End

Condition

Exertion remains in space

Primary,

SecondaryActors

Primary: Worker


Trigger Worker requests to drop exertion


1 Worker sends exertion to Loki Encryption Manager

2 Loki Encryption Manager return encrypted exertion

3 Worker drops encrypted exertion in Exertion Space

Description

The drop exertion use case is executed by the Loki Worker, who drops an exertion into

the exertion space. The Loki Worker does so through the use of services provided by

the group manager, which monitors and logs the dropping of an exertion.


65/323


52

Analysis

The structure of having the Loki Group Manager monitor and log the dropping of

exertions in the group allows all monitoring to be local to one component, and aids in

decreasing coupling and increasing cohesion.


66/323


53

Table 10: Use Case Template 7 - Execute Exertion

Goal in Context Successfully execute an exertion from a space computing

environment



Success End

Condition

Exertion is successfully executed

Failed End

Condition

Exertion is no executed

Primary,Secondary

Actors

Primary: WorkerSecondary: Exertion Space

Trigger Worker requests exertion execution


1 Worker sends encrypted exertion to Loki Encryption

Manager

2 Loki Encryption Manager return exertion

3 Worker sends exertion to provider

4 Provider executes exertion

Description

The execute exertion use case is completed by the Loki Worker by first picking up an

exertion from the space (use case 5) and then executing through the use of the Loki

Workers appropriate provider. The Loki Worker notifies the Loki group manager of the

execution, which in turn monitors and logs the execution.


67/323


54

Analysis

The execution is the most complex of the worker services do to the fact that it

incorporates an external provider for execution. The original design of the Loki

framework was to have an additional component called the Loki Executor for exertion

execution. In the process of minimizing components and communication, it was

apparent that the only thing necessary for exertion execution was the Loki Worker,

which is a wrapped generic worker. The Loki Worker adds encryption and decryption on

all exertion passing with the space. Execution is inherited from the generic worker,

seeing as once the worker has the exertion, the process is the same as in the generic

case.


68/323


55

The last set of use cases that to be discussed is those necessary for group

administration. These are shown in UML Diagram 5.

UML Diagram 5: uc LOKI Administration


69/323


56

Table 11: Use Case Template 8 - Get Admin User Agent

Goal in Context Successfully open admin user agent



Success End

Condition

Admin user agent is successfully retrieved

Failed End

Condition

Admin user agent retrieval fails

Primary,

SecondaryActors

Primary: Worker


Trigger Administrator requests to open UA


1 Administrator requests admin user agent

2 Admin Agent sends back UA


8a Admin deletes worker from group

10a Admin deletes exertion from group

11a Admin deletes group

Description

The open admin user agent use case is initiated by the groups administrator requesting

to see the User Interface from the Loki Admin User Agent. The interface is published by


70/323


57

the Loki Group Manager (which will be described in the class diagram description), and

extends the functionality for group administration.

Analysis

The admin user agent allows for group administration, which consists of the deletion of

exertions, workers, and the groups themselves. Although group administration is not

necessary for the implementation of groups in a space computing environment, it helps

with the usability of the framework. Without group administration, the group members

and administrator are blind to their membership in any specific group.


71/323


58

Table 12: Use Case Template 9 - Delete Worker

Goal in Context Successfully delete a worker from a group in a space computing

environment



Success End

Condition

Worker is deleted from a specific group

Failed End

Condition

Worker is still a member of a specific group

Primary,Secondary

Actors

Primary: Administrator

Trigger Administrator chooses to delete worker from group


1 Delete worker request is sent to UA

2 Delete worker request is sent to Loki Group Manager

3 Worker's group's exertions are retrieved from Exertion

Space

4 Worker's group's exertions are decrypted

5 Group key is recalculated

6 Worker's group's exertions are encrypted with new group

key

7 Worker's group's exertions are written to space


72/323


59

Description

A group administrator can choose to delete a worker from a group through the Loki

Admin User Agent. This is one of the three administrative tasks that can be executed in

the admin user agent; the others will be described in the next two use case descriptions.

The process of deleting a worker from a group is a rather intense and costly operation

and will be described in greater detail in the appropriate communication diagram.

Analysis

The deletion of a worker from a group is a not a critic function to the success of the Loki

framework, but helps in the debugging and administration of the framework as well as

validation, and is thusly included in the core implementation.


73/323


60

Table 13: Use Case Template 10 - Delete Exertion

Goal in Context Successfully delete an exertion from the space computing

environment



Success End

Condition

Exertion is deleted from space

Failed End

Condition

Exertion is not deleted from space

Primary,Secondary

Actors


Trigger Administrator chooses to delete an exertion


1 Delete exertion request is sent to UA

2 Delete exertion request is sent to Loki Group Manager

3 Loki Group Manager takes exertion from space

Description

The administrator initiates the deletion of an exertion from the space which is an

extension of the Admin User Agent. In this case, this selection initiates the

communication necessary to simply remove the specified exertion from the space.


74/323


61

Analysis

Similar to the deletion of a worker, the deletion of an exertion from the space is not a

critic function to the success of the Loki framework, but helps in the debugging and

administration of the framework as well as validation, and is thusly included in the core

implementation.


75/323


62

Table 14: Use Case Template 11 - Delete Group

Goal in Context Successfully delete a group in a space computing environment



Success End

Condition

Group is deleted from space

Failed End

Condition

Group is not deleted from space

Primary,

SecondaryActors


Trigger Administrator chooses to delete a group


1 Delete group request is sent to UA

2 Delete group request is sent to Loki Group Manager

3 Group's exertions are retrieved from exertion space

4 Group's exertions are decrypted

5 Group's exertions are written to space

Description

The administrator initiates the deletion of group from the space which is an extension of

the Admin User Agent. In this case, this selection initiates the communication necessary

to retrieve all exertions owned by the group, decrypt them, and then return them to the

space.


76/323


63

Analysis

Similar to the deletion of a worker and the deletion of an exertion, the deletion of a

group is not a critic function to the success of the Loki framework, but helps in the

debugging and administration of the framework as well as validation, and is thusly

included in the core implementation.


77/323


64

Component

The original design of the component diagram is shown below:

UML Diagram 6: cmp LOKI


78/323


65

Group creation starts at the submitter who utilizes the javaspace interface to drops a

group creation exertion in the space which the Loki Group Manager picks up. The Loki

Group Manager then drops a generate group key exertion in the exertion space via the

kerr_daniel_thesis.pdf

Documents