<%BANNER%>

A Computation Paradigm for Multiple Mobile Agent Systems

xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110115_AAAACR INGEST_TIME 2011-01-15T17:30:25Z PACKAGE UFE0008327_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 62037 DFID F20110115_AABXIF ORIGIN DEPOSITOR PATH onbilger_o_Page_151.QC.jpg GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
88025aeeee1f4a5942e09bea4d812a6b
SHA-1
7700b592b8bf874b64ae1d741309be7252ce2f3c
48034 F20110115_AABXHR onbilger_o_Page_148thm.jpg
468da193549d508ae60f37d4161fa1a5
e1206e5b907f4ea337adba535114c7e9826f9af3
55962 F20110115_AABWFD onbilger_o_Page_010.QC.jpg
9020caa4b73720272d77ba1930124035
0c2fc382fd4694857cccb0988cb28e24ac20238e
149229 F20110115_AABWEP onbilger_o_Page_081.jpg
6141fba9a5b59bc254e1e174f768d955
a82712ce3d49898d080cb0587f8cc43b216f4ab8
22894 F20110115_AABVZJ onbilger_o_Page_165thm.jpg
34ba07302ac9072a47c84ed02c447609
b022f5e21b2f9512a800131c8592c7bca55a5c7f
95191 F20110115_AABVYU onbilger_o_Page_047.jp2
588bfc2041516156595a96fd448f5580
9fb8ef98352c19578a9fb197b2eb2fdabc73564a
3197 F20110115_AABXIG onbilger_o_Page_002thm.jpg
2dcb508fb88d7f8fc2e50ee72fba267f
d99ee413470bf90352deda7ecd1f021d69fc73e6
72910 F20110115_AABXHS onbilger_o_Page_050.QC.jpg
bac5edc6cdb67a8dd4f84787fe3f6ac6
76afad5f9d5b127b3bcdf4f2396a934c5528d856
62936 F20110115_AABWFE onbilger_o_Page_056.QC.jpg
357e183d9465cfd47dd56ac57a264d07
4210b8929929e59bb3aaece8a6aefca7793c558d
45250 F20110115_AABWEQ onbilger_o_Page_127thm.jpg
066a6392df74a56445530af50c603072
c0f19a2cc9f1d83b5716672c6ae0e13f457c2108
2445 F20110115_AABVZK onbilger_o_Page_009.txt
b3399df04d85de421d4c0795630060f7
4037243a4b3f39d913b923774ef8202f7c492b0d
201115 F20110115_AABVYV onbilger_o_Page_052.jpg
2a37d625c1b67686590e92f12bf86254
2d92adb84a8d220a9b99d0b57a433e8827556803
74455 F20110115_AABXIH onbilger_o_Page_106.QC.jpg
0fd7fb6567c5fcaec0def95771020721
099f5958e42eebf8ca67a7a2cebe18700ca586dc
76444 F20110115_AABXHT onbilger_o_Page_023.QC.jpg
1724d78d46db96b97cc347e335c6b243
1aa5618946d74ffff3139b70157c26f9309f2462
75894 F20110115_AABWFF onbilger_o_Page_072.QC.jpg
6313513ed38ab7db57ded7f3fc9b8155
b12604db3f57eca624befe321e8511fcc2d36beb
157180 F20110115_AABWER onbilger_o_Page_011.jpg
8b01b6f79667621dae8f22bafcc5675d
27e85bf11376c2c279f8d11845ff3c46009e3cb8
110277 F20110115_AABVZL onbilger_o_Page_068.jp2
13dfc7d6a0a3516ba7da604a25165511
a1b64a97f6ea76364d5b188f11db341afc641c61
107815 F20110115_AABVYW onbilger_o_Page_071.QC.jpg
08df7afed2daa9771fc9574ac0d0c98b
31777a9ef70dd565f6a9f7d6ddd955f5689c1c3b
70419 F20110115_AABXII onbilger_o_Page_013.QC.jpg
a072ef3aa5d6f8af49c3984a560aa4ec
8e3a198c0e4dc8160c36ded6cf0990195f6b7503
46268 F20110115_AABXHU onbilger_o_Page_009thm.jpg
5105a31afa2404c0154c64fea1433b6e
5f4c2aa4fb94ad6178ba842732ca24d386494c27
203195 F20110115_AABWFG onbilger_o_Page_016.jpg
df26dc6376675c85ff4a9a6febc1657b
9403b447e71bf4e28641f6e4a3ee101e46379ea8
1954 F20110115_AABWES onbilger_o_Page_109.txt
89a836fbc0a0b27dc40e8cee9729dfc3
87428516e768262ab845d02859eb4db7cdad530e
54391 F20110115_AABVZM onbilger_o_Page_079.QC.jpg
18eaef40d3c125b9c854ea978a71bcdd
98b603c6dd3139ff547bee431480ecd3b4a82f8d
46811 F20110115_AABVYX onbilger_o_Page_128thm.jpg
196605685c4c151e25d794791104dce9
629e3f0ec38052e8358af9da5c2dcaa4c87003ec
25465 F20110115_AABXIJ onbilger_o_Page_069thm.jpg
fb157b33469ffe54aa0c1d3bdd15bc7c
4ede3ba0332aa8287019ddf78a8c0f66b5a231b9
74477 F20110115_AABXHV onbilger_o_Page_017.QC.jpg
55f877998f905b23e4d317c6cd6bb14d
42bb7f3ee6768bfc3be4e660d6e75ff20a18064b
1053954 F20110115_AABWFH onbilger_o_Page_104.tif
c9990c1fbe2a93ce811a2a8e9b2822e8
f6b7e7c8594c005ecacece06c7c1fae03bc08392
51594 F20110115_AABWET onbilger_o_Page_108.pro
fee32c88cd60157aae3365944f4691ad
10edd6b1eb1890f827ad5ddf2ae11ac1dbd8a072
86369 F20110115_AABVZN onbilger_o_Page_096.jp2
640030ffb475dbce55cb13621eaaac5b
2659c912d99801892f70a4739a6b41dd00a91cae
F20110115_AABVYY onbilger_o_Page_022.tif
1434f611424e413c6f9dbc7fda06b800
cd2bbdceb61211f164038fe5c3ed5f9f5a3e915a
63533 F20110115_AABXIK onbilger_o_Page_129.QC.jpg
8639a3f6db6afc72dc22d634473f376b
59392222f873e41a463eaca75d86c267784ff1f9
40314 F20110115_AABXHW onbilger_o_Page_007thm.jpg
e789222419e03924178368ec3e44036d
82baf261fe1f2509713b80aa032428c968432674
69261 F20110115_AABWFI onbilger_o_Page_144.QC.jpg
88e8e44596d86bfe9c588662df664005
5bbae6437abb4af3a99079c10ff69ba2db2ef1a9
F20110115_AABWEU onbilger_o_Page_003.tif
7d9d63c449e5dccb3f6af1657717cfc1
be44f4896e0c554ff2c4d472b9c7c769f2bbe697
F20110115_AABVZO onbilger_o_Page_166.tif
bda6b5620c8bea3ff2398d50482aa4a4
994a43c794162915c3e26e7d24704bc98fba7479
2078 F20110115_AABVYZ onbilger_o_Page_143.txt
14e93229d14a866b0bc7329ac1f50ffa
f1eca353800fd28156b2c2ab9619e4486062d692
24800 F20110115_AABXIL onbilger_o_Page_040thm.jpg
dae35d14779091eac1f19a5eeaed04ae
7a8f164f2678ae6a1c653a75bb2ce80b5cea8056
18526 F20110115_AABXHX onbilger_o_Page_146thm.jpg
a1874cee3962428083e522560478b16f
adf46450594e13352e34356e4db66731092b1a4f
205701 F20110115_AABWFJ onbilger_o_Page_030.jpg
f21e7dc4c19585bb7afc3cfe3d800a36
9ed2a6b75554b8be2bb49b658455ebc07a75ead6
21408 F20110115_AABWEV onbilger_o_Page_144thm.jpg
56c11dde090cf2e12e1affc0ddd3067d
a4f135113f4aa69317fb64687c0ac4cdffd6c1f6
85309 F20110115_AABXJA onbilger_o_Page_166.QC.jpg
b30c1efdf2568b73a9935546b111ee11
7a4a32591753fd2be2d92f139980d3d54fbc68f0
79859 F20110115_AABXIM onbilger_o_Page_108.QC.jpg
b9ece74147806feba3a414521d785f6a
558d0d636435b9bce1f9ddfd86c89f4baad02eee
24638 F20110115_AABXHY onbilger_o_Page_017thm.jpg
4fe97434098e13de13206c10914177bc
b2022bb892bdba8cc08e027007317f5720a6b5b0
39906 F20110115_AABWFK onbilger_o_Page_102.pro
eb829b82d67357e3f5c56a0e9a561a12
afcbc4688c66ade40ae5984b944667f9cb40470e
199312 F20110115_AABWEW onbilger_o_Page_085.jpg
e45aad23bc04f79bf49a8c268443adc3
f495de07dc0096b26bdffda1ba89b358c60cccf9
F20110115_AABVZP onbilger_o_Page_103.tif
65d882e05b21b69246cac3f0b60b17be
7e53c6cf375067842e26ffd220bd4ffdb429804d
74658 F20110115_AABXJB onbilger_o_Page_097.QC.jpg
85030504d23d0fe11a1c4f5358d18ca8
f99c1cf07e2da8d397ef256f6ef70d2d8a5b81f3
78665 F20110115_AABXIN onbilger_o_Page_154.QC.jpg
60fb4150564898264ad844cb3d86eec2
56b213c659f320408764206a24393ed8b696c1f7
78766 F20110115_AABXHZ onbilger_o_Page_036.QC.jpg
9b8404bf7d662eafc0143b5f2e737040
0adc07e8422934a63017c3fbdf277d5e993eef04
24982 F20110115_AABWFL onbilger_o_Page_099thm.jpg
3d562e546c7ae8279cd08f409ca9e942
3446cc0497fecfb24116c1e4a02c35f63cc03270
121734 F20110115_AABWEX onbilger_o_Page_151.jpg
f5aabb35398ba8bb99e2abe022afaa08
c1a89a82c10b1f191e624fc151d827002ad21250
F20110115_AABVZQ onbilger_o_Page_138.tif
2020bcb992bc313ffd77d06bc4aaa736
0451db555f7ada4693b3077423070479389ee8df
22333 F20110115_AABXJC onbilger_o_Page_159thm.jpg
f1fd388b09d3e8f14892cda650acb72b
603ce847140c3d19fa7296441515562686d1fcc9
73905 F20110115_AABXIO onbilger_o_Page_007.QC.jpg
7c55d7944093ed8bd68c28d324437d9b
60ec3d4cba1087de41984338fc44104d8381e6c0
19706 F20110115_AABWFM onbilger_o_Page_024thm.jpg
709bf8b5199b87e35c39e338244a7185
35a20ff75fcf05dff16cf15f07f59a3c25c7d9b9
189225 F20110115_AABWEY onbilger_o_Page_093.jpg
62aad60ac76d5e3aac72ea5f75d86f8a
d1d6a9b1accac21dc865890bdb97637e06a30439
580090 F20110115_AABVZR onbilger_o_Page_115.jp2
a8fdefc172f258f3702eb763c50d15ac
89aa61de8d52ee64c34e39f86a28af67bbf62a10
104851 F20110115_AABWGA onbilger_o_Page_038.jp2
f585bb505d6676a9df6293a0e7793794
c8f0867203186ef8dbf4f4029af49a183bdedfd9
51166 F20110115_AABXJD onbilger_o_Page_071thm.jpg
4c0a3ac1f4397fc303e01bc8da2fc0ff
1265fb28688c7b2ef8a52946a3543bd7f22ab617
81892 F20110115_AABXIP onbilger_o_Page_138.QC.jpg
3513ccddbe2ac96a0ec25d0638de7102
4ec9f69eb06e5ce93f74afc5afe25974d42f4fb4
87195 F20110115_AABWFN onbilger_o_Page_157.QC.jpg
f579db8f4bde5ce46259f60cfb8acbb0
64026e713a1f036276ee09ac3a93717a04232a88
1051980 F20110115_AABVZS onbilger_o_Page_007.jp2
40e3050148421a20bbff7c86076b5d7d
00577a4e3cb9b049aaa58494bccc3d0eec56e98c
2384 F20110115_AABWGB onbilger_o_Page_156.txt
e50734a092a88a11f5e00cbd225f579c
d609cfe6bf857d4be2bec616b28c882fe99fdbff
20646 F20110115_AABXJE onbilger_o_Page_102thm.jpg
9ae47db6e430b62d8b872e31352e9072
4fd6fde38e12116f4b31b970799647df18ab1b88
72831 F20110115_AABXIQ onbilger_o_Page_123.QC.jpg
19b6ec764803aee98957a2a8161db344
263eb4fbf77fa7b8f5e2ae652a6238e48255e61a
43914 F20110115_AABWFO onbilger_o_Page_095.jp2
31f47b8670d738dee6aa2ae8ce745739
4a798b0d99bd4fbf2960ed2f65bcf33edb81c1ee
2112 F20110115_AABWEZ onbilger_o_Page_092.txt
000c2049b6732e9dc1a52e1270e05409
62c3ea3271e734b731c2d3237cf6dfbac47df42c
101097 F20110115_AABVZT onbilger_o_Page_123.jp2
016f03aae4195e23bb34330aa24a9c6a
6ec6634144ae242366a51f824687e49a26bb855f
1957 F20110115_AABWGC onbilger_o_Page_043.txt
944e5dbd335f43e3c7b72bcbf1351cdb
3ac5e25a7d127e80a91c30daab10d6d5b79a43f4
75666 F20110115_AABXJF onbilger_o_Page_131.QC.jpg
792d038cd7f4232189b5371bbfea08a5
55aa689b19f2e53c6c2ca2f47daa5d757884402b
23070 F20110115_AABXIR onbilger_o_Page_107thm.jpg
3259801d0d116e8c26284a4e072e4605
b26ddc6b9dabdc425627220e3a6b98e28739c941
19099 F20110115_AABVZU onbilger_o_Page_055thm.jpg
3b2d61d121dc786b747a5510699907cb
dd7c11d7a476a2a19a0c3ff83b6feff5a69407c5
2299 F20110115_AABWGD onbilger_o_Page_105.txt
97d2937c2d7f790cecdcf956428bf86d
508edc823069012ff1ac944a13421adb3adcf8c8
1840 F20110115_AABWFP onbilger_o_Page_013.txt
dbd75411cfd208b81a7ebb697983a0dd
dc39835d30983c56dfb73b82dc6d65e384c3743f
82307 F20110115_AABXJG onbilger_o_Page_105.QC.jpg
a477844d3d5a8eca595992147c10472a
43bf24383a2b6cbad27993ddb7ac1bd1201cf7f5
22816 F20110115_AABXIS onbilger_o_Page_053thm.jpg
354803bb842ddb6b29152c4ec377cacb
86ab34fed9ae604c573e4e13f15109df841a03bc
50435 F20110115_AABVZV onbilger_o_Page_034.pro
b685ecd52de4d4dcba387a695b45982a
89b1f0710d187a81fe4d48e128e6b6b24faee0bb
13230 F20110115_AABWGE onbilger_o_Page_142thm.jpg
a3ce0aedc9d413021c3149e03cea2bea
d4d1c35830fa164c25f313940651123d47c523e2
48576 F20110115_AABWFQ onbilger_o_Page_112.pro
37ccd2a148743e11bce020da98f80197
e7bccebbb4fef822dc01a394382ea3d5857417ad
24649 F20110115_AABXJH onbilger_o_Page_164thm.jpg
54d3e4d0714aa75dcfbf5494ffd74077
360310189612789fb9e52fa9e69b3a97c44f6a9d
86356 F20110115_AABXIT onbilger_o_Page_152.QC.jpg
b23c9d0ce8bff3f76139835fee660ad2
762a4cc4848f328179baadc6299cc1afa646af91
208484 F20110115_AABVZW onbilger_o_Page_027.jpg
eca120937a118a0cdd56a2dedaf307d0
a4ed9298fc5ceffb2d0125f3daabcb8921ba5b44
77433 F20110115_AABWGF onbilger_o_Page_022.QC.jpg
643467502c931f89e8118e9067b0635e
80be3f85f531b3250fe3a53c5aceb674d63c5391
F20110115_AABWFR onbilger_o_Page_029.tif
1a2d403b9c51b0f7091335add48608a3
eacdb837ad36d107c3f0b06bdca74e96ccec3778
23898 F20110115_AABXJI onbilger_o_Page_052thm.jpg
2630b05b1dda39573a5d4902b8631c52
3d58b3240def9794a6a72f1f8bd55abd7eaf730c
83346 F20110115_AABXIU onbilger_o_Page_092.QC.jpg
f89e261926e01c19d1f0880c8836cd85
8bb1b81d49f9bfbe25bafe822e3915e154e54b75
81850 F20110115_AABVZX onbilger_o_Page_094.QC.jpg
bd0585cc337ba97c5d39cb09a1ad22c1
688cc83766c496897bfb0ef24dd265b334ba9e86
99284 F20110115_AABWGG onbilger_o_Page_062.jp2
25224b9adaedb7fd3a00ea7744d5ac8e
937a252223866d680f79559410e19bc68e4224c9
83519 F20110115_AABWFS onbilger_o_Page_124.QC.jpg
ead68b3f95505c8f1b5d44a9f2de2c49
0e545789186002f53d483e52f7b3d782c455c439
79619 F20110115_AABXJJ onbilger_o_Page_067.QC.jpg
09d9e676745fb1f1615a54545a28351d
6bbfb0a95e40e4870db85575c374a9de2285bb23
78914 F20110115_AABXIV onbilger_o_Page_045.QC.jpg
ea8f2ac1418d117b358c2304154ea675
9e6e2234bd6f269444f0b677f70a5efd5f48bb0a
211516 F20110115_AABVZY onbilger_o_Page_159.jpg
16256f23091805f1cade8accbb91e476
0298483e88b8ad669c5307beb0766223d81a54b1
79864 F20110115_AABWGH onbilger_o_Page_087.QC.jpg
9f54dd10a2d40cb2ff39696d424e7192
47e1602568ec2c8201d67e5ae2dbe7e8d3e9b608
F20110115_AABWFT onbilger_o_Page_153.tif
e397877226e07d43a57ef6bdeb20fbe1
5e55528685122b180eace8f6513cac815fcbe111
79681 F20110115_AABXJK onbilger_o_Page_070.QC.jpg
8acb375b146db22d2594b4a6ac07374a
8bd4f8695e5cec7f82006e987220ab601c5317a4
22791 F20110115_AABXIW onbilger_o_Page_134thm.jpg
ba25061d971e4dd9c31ce07ff1aa395b
7d139ac95f581280f1b0cd0b4e304ff363a621ed
57576 F20110115_AABVZZ onbilger_o_Page_018.QC.jpg
421a9f334ba32d5ce20e27ddd47d93c3
892b11bdd87fd9df5359d2422eb93db90d93ffb3
202648 F20110115_AABWGI onbilger_o_Page_098.jpg
2d147d1fc0a6efbfb6ac84f90eba03fd
09e5198127d2acd2c3019143dc52028f48c0e7eb
63543 F20110115_AABWFU onbilger_o_Page_140.jp2
5668356cefb74e78c62c987ababb96ad
05dded0a46de3e2162ea9903c48b866adc49dcf7
58340 F20110115_AABXJL onbilger_o_Page_055.QC.jpg
2b45ab453b44639c42fbb0be784b3872
23e1d1194961afd1f15a252055b4df7fb89c1ce9
58715 F20110115_AABXIX onbilger_o_Page_102.QC.jpg
1d2c9decaec244ddd79072dd2d370cee
28ef38cba77d79c681ae113b10c234e530eabcf7
72665 F20110115_AABWGJ onbilger_o_Page_085.QC.jpg
a9c1aacfdaa4a267406c4a7494b82873
c3601c4be4dc9504dcebabeacbf63bd7d8a9e0f0
238633 F20110115_AABWFV onbilger_o_Page_009.jpg
bfd8c5ad8090a98510e0eff3f6551048
0aec41fc198e7599e59f5ce3c6cd08b31d185c14
74223 F20110115_AABXKA onbilger_o_Page_020.QC.jpg
2cc6cb90249149874aeba20271eb2de9
a7b812e4efef653a751911c6e55efd69215ba735
82768 F20110115_AABXJM onbilger_o_Page_049.QC.jpg
6da43a5e98e48d257ca9879588e5f927
b8bef1c4a4bbafa889112517c57c0566936a3729
47767 F20110115_AABXIY onbilger_o_Page_149thm.jpg
39fb269b45ff25bc34f99e0d22d7c4ad
88fdc7b7526cd6a33a18d4cfa36d59f4c7160a97
103594 F20110115_AABWGK onbilger_o_Page_072.jp2
4ae6d5ce5864beb4b1fa648d007e2b73
41b3f2775e3d49741aa89f1cc21e491295bb30c5
103925 F20110115_AABWFW onbilger_o_Page_017.jp2
2fceb60b0861e0c9f9503e5da2971da0
7668e347902bf8968fb733945adbde1f6be2f0fd
23204 F20110115_AABXKB onbilger_o_Page_110thm.jpg
1041c7d9fd34b84b2a9e2d431cfb6603
16a98c1a11880a4200c805c82421ce7825599efe
F20110115_AABXJN onbilger_o_Page_116.QC.jpg
4c975d20286cf8a863802dcbb50e10ab
a6a9944722c22b908aff586528c035aebabc5a72
68215 F20110115_AABXIZ onbilger_o_Page_063.QC.jpg
be0c80e95ab0195e17ce5b2458573774
21fd9be15c5ad363ea3ba8e839d7f2cfb10a2288
211258 F20110115_AABWGL onbilger_o_Page_036.jpg
2b99fc41b297ac77d3e853469c867acb
2501b5574fff0eda87a4214c58990205b6993c6a
24253 F20110115_AABWFX onbilger_o_Page_051thm.jpg
4b7c055af1423cbddaa60cb0ecfffd6d
a02c4242d03a395adc835834624a2eea081ccea4
25126 F20110115_AABXKC onbilger_o_Page_035thm.jpg
d3e613629ba860655ed440133edc90ce
257d61caf7581955eb183d25b38e98afc01e67cd
79705 F20110115_AABXJO onbilger_o_Page_042.QC.jpg
ac48fe8350a2415a0070da988b687ac2
88d300f77c7ce7ff136f685ce8f34274c76c7cfa
F20110115_AABWHA onbilger_o_Page_135.tif
bbd1244b16999a460505f497d9e50578
9f6e0bdf6a930b5bdad139a62aa47ea0adafecff
6032 F20110115_AABWGM onbilger_o_Page_002.jp2
364c2d7e4b612ecdb40adb61126690f0
bd9aa5015b29517e7e62ac4ec23c2cbed06a9246
2026 F20110115_AABWFY onbilger_o_Page_132.txt
ef33a09335996a23036b31df0b20edd4
57a5d062a00fb782269d2f7386ef4eb5d560a9df
25464 F20110115_AABXKD onbilger_o_Page_043thm.jpg
776c5b6469fbe9f6f44573cb942d6665
2fd80e677fbadab2feaf4be56b9b3188d393a059
26328 F20110115_AABXJP onbilger_o_Page_061thm.jpg
baf25362acb28cd5e3c5d12f7df665b5
ad8aecf124b27bb9f9c7c63f832340e804ae6ea7
83440 F20110115_AABWHB onbilger_o_Page_141.jp2
9a25b29d992a7035e3688f44e8e312b8
cd2c3e1425604cff65f32e0613aa45fd01a4db2d
F20110115_AABWGN onbilger_o_Page_101.tif
93373f9cb6fcf7b3ce3e14c57ea970cb
b276499b08f25377559de878e4f671f4916208ff
35074 F20110115_AABWFZ onbilger_o_Page_010thm.jpg
0af9f8d284b0216a27094ca995e1c631
ce37684d0343844e0e1ee0db971862897c0c14fa
25285 F20110115_AABXKE onbilger_o_Page_037thm.jpg
ef6dabe93a69e0bbf3b5fbd62cf60014
9e06326d708596ecd68d70aca95eafb61fadf117
98366 F20110115_AABXJQ onbilger_o_Page_147.QC.jpg
7d94f358fcc2208b6f0b6ee13121da6f
fbe7f93392cf89776d6b31f692f391d096ef999f
58342 F20110115_AABWHC onbilger_o_Page_081.QC.jpg
26bafe2afafe8e0cc862862ba5425644
1de55bae59ba3d292ee44b4b56374a86628a839e
209227 F20110115_AABWGO onbilger_o_Page_154.jpg
402eaed3c54c04e9fdde27b7b88774b1
d85090fd0728c70f8a865f09fc2b17c51bac453d
70856 F20110115_AABXKF onbilger_o_Page_159.QC.jpg
b0ccb667561806f338270b72cf5064cd
a4d3aa21fff9ec2f87b1d3bff53c4887a3407d08
53389 F20110115_AABXJR onbilger_o_Page_004.QC.jpg
1403def20f88f25c654dcf9e2e0fd8e0
bb4b955880da69a0c22b7255c852c5d117289dee
111790 F20110115_AABWHD onbilger_o_Page_069.jp2
bd137ce0f06990beb54926f2e78d9f39
f7b3a63bd1c5f308f0c3f42d760a16677bcbc9c7
25908 F20110115_AABWGP onbilger_o_Page_092thm.jpg
a7f1d34679a10fd18877ffcca150af27
2ff85ebfb8a402aaa84c169171245a3b2bdab473
23952 F20110115_AABXKG onbilger_o_Page_086thm.jpg
77e9a14a174549d166a51690c7841401
6d33ea522a0cbf87195f30cc6d1ded20086020da
46091 F20110115_AABXJS onbilger_o_Page_150thm.jpg
4f7e26c682708f7386184aac4975d697
f994fe170c3c8be30a5ef7a40575300e1c94365c
55792 F20110115_AABWHE onbilger_o_Page_012.QC.jpg
ac97d767f027694fad45da4132468696
c5197b076972bcd6c34ca607f37e821ac589d030
70783 F20110115_AABWGQ onbilger_o_Page_137.QC.jpg
273ec70d872b0797131c17654aa2fa4d
7a5d9ce340003b4d10c248b78398be219755a698
78923 F20110115_AABXKH onbilger_o_Page_099.QC.jpg
608e90c5cfa9ce7ffea85eeaf4f18fc7
98f9faf0ece51a1bfea445295e80bbaed9fd5e94
78634 F20110115_AABXJT onbilger_o_Page_043.QC.jpg
3d135b180800cddbb2354abfc9846e14
eee92809389f0081d0362cfe2699a20d5f9a7461
2634 F20110115_AABWHF onbilger_o_Page_160.txt
2e51098a815d4c7d9a9e5d973f47ecb8
9e808b0c4732be2552e0d8fcb2d7db258d90330d
F20110115_AABWGR onbilger_o_Page_132.tif
449e9a82cb53cc7326ee6e4d03287f11
91316a2e1581b5db28b7a967a7ca83c9f4bdd4cd
53430 F20110115_AABXKI onbilger_o_Page_054.QC.jpg
39b97ad90cfbe4d6c13217216281f6a3
da1d469d83a6da07a0bea185185dd706f42a07f6
25929 F20110115_AABXJU onbilger_o_Page_160thm.jpg
ebbcd6faf8d302174a19e55c039ceaff
00bc6da0e4d438d3cd0abf5ca5fdd6883dede344
47809 F20110115_AABWHG onbilger_o_Page_038.pro
43e8a3a3c4e7bb58efd4ecfe852b8784
75bf1ed8db0ec97aae712c5267345a304dcc65cf
F20110115_AABWGS onbilger_o_Page_124.tif
50517f5a030248b2b966d21882e4ab1f
aa0159972e70610093c8b8c5cbfc041d31144762
112872 F20110115_AABXKJ onbilger_o_Page_161.QC.jpg
d82d52c43f538ed30637daa1aa0ab18e
db5f96784cd5d4f58c2c6800be57df586eb5f02d
18107 F20110115_AABXJV onbilger_o_Page_065.QC.jpg
7baad2443c4bb8af098e457573e25bde
da0f3c7a5b1a329079cab8926ec73826a2e62285
27415 F20110115_AABWHH onbilger_o_Page_058.pro
34579694d237ee0aa27e3bdc310218b5
de85bcfd6f59f78334b9f967a38a013f4a8ddb08
1838 F20110115_AABWGT onbilger_o_Page_059.txt
5673d6c51bb7a394fdf395219b0acea7
15c069b62b3204e715f4b9538dc2bf7f99e0481b
47301 F20110115_AABXKK onbilger_o_Page_098thm.jpg
b41f382eabf160bfc56edf0deee443a1
7bbb380dffa0a9628d189d49cd50da4d876cccdb
19467 F20110115_AABXJW onbilger_o_Page_081thm.jpg
9f85334a2efdf8cefb2f3064dc0733a7
b5a100aedbd785539951d13c829895925183bc3b
25091 F20110115_AABWHI onbilger_o_Page_068thm.jpg
d1e047b430401eeb7180b44721344c8f
d53f9880436339b118c9883478d00cc2a8673dc5
1760 F20110115_AABWGU onbilger_o_Page_019.txt
ca0dd6a2e1131329729e675ca0dbe6da
719d5fb198e86e5af3db4446558b3757db743140
79824 F20110115_AABXKL onbilger_o_Page_037.QC.jpg
7f9c10e204923bd48113c1fcad8013b6
0ee185d8adef6680aa063414437c93ec74550063
26181 F20110115_AABXJX onbilger_o_Page_048thm.jpg
5042f9dd2305d9c659138faaaadc4973
73fce06a9f5cc375a9907520436e841b78b9f5f0
216357 F20110115_AABWHJ onbilger_o_Page_020.jpg
ac97391428ee194bce192d0758b62152
a75439509f6d9808ce67e63afa5fdc311773c129
19015 F20110115_AABWGV onbilger_o_Page_168.pro
4b6c4e41323ddaaf3538624e12e94622
d685491ec7ab605ab8465c8afbdffcd16eb1259d
80461 F20110115_AABXLA onbilger_o_Page_035.QC.jpg
75f4e82a350afcb61c0ab6caad70fba3
daee76218af70aa897b96630510ec5d050823a7e
84876 F20110115_AABXKM onbilger_o_Page_100.QC.jpg
8606b61c8a35f3a6aaeac650055a711a
ac4a23ba1da3e29688b0ab0989bcd53f18acef2e
69328 F20110115_AABXJY onbilger_o_Page_076.QC.jpg
08050381f30346d13230d0e3e51be5ca
8f6c4285ebe5df21a05dbfe279f5fc10f6c7e9ba
79971 F20110115_AABWHK onbilger_o_Page_014.QC.jpg
0df120c27aeefeed4861a7b0757cc166
33bc65a5521c3184634472c177843333bf562247
24096 F20110115_AABWGW onbilger_o_Page_097thm.jpg
8d2df95f471b97b5e3d6ba9aa8a37c18
c50d25dc5d81dc9f16c2a4b6842d067162925a85
22394 F20110115_AABXLB onbilger_o_Page_076thm.jpg
7ebe07aec85c3e73a517b35d3563949b
3979d6b9e93cc9e234fe85fd7923c52a01c28acc
72873 F20110115_AABXKN onbilger_o_Page_053.QC.jpg
746710152e9c9be85f7ba151261be4d5
2e0afa0b584c6f975c43b601cc0a342e32dc6ddf
78532 F20110115_AABXJZ onbilger_o_Page_122.QC.jpg
3067664bc9e5c0e554174695c81f6027
c696828a89e56743a49db12b29d03033e130a57b
1897 F20110115_AABWHL onbilger_o_Page_038.txt
492f6548173a4cf40a55c3227c44caeb
d577b4fd882c41ea65af217b52199ff10d7ea41c
23896 F20110115_AABWGX onbilger_o_Page_101thm.jpg
1ee809da292e6afe9dc92e2a02a439b6
6ec939a09be4faeab0135ea981f5dd9bdd664524
24366 F20110115_AABXLC onbilger_o_Page_108thm.jpg
3e36c502ffa15e499c1b4f288752bea6
1555828c6f0ed801259442e1fd44ac11dedbe321
70165 F20110115_AABXKO onbilger_o_Page_084.QC.jpg
402ceac41e5f201e39a907baa1453696
2091cc0c0ca5c6c89475e66101049edccb6d8556
25271604 F20110115_AABWHM onbilger_o_Page_147.tif
e3ad60ced1df503bcf1dca76e5446b82
48d2bdac58e71c3782cec94ad6915034ea159036
21896 F20110115_AABWGY onbilger_o_Page_063thm.jpg
1ec024337e3d1017906000e1878c5574
a81ba47122158270ca84fa50b028d84abfa761f8
107391 F20110115_AABWIA onbilger_o_Page_074.jp2
fd244c8320f829f141794dc51fe227a0
ccdbad089cedc51f1b1b399763eaec13f89b27bc
39796 F20110115_AABXLD onbilger_o_Page_103.QC.jpg
42d581c3f1600755a66f3097811c32d5
8b088b48653481aeae3f01babfcc086fc54d80c6
48280 F20110115_AABXKP onbilger_o_Page_147thm.jpg
73f5a29bc92f5fa835174aa5d62c822b
f11318ca3b40dfe2fc2d54ff09ad2768793599d2
F20110115_AABWHN onbilger_o_Page_114.tif
7fcd04761662ce9ae9e3cde2c3e1a73f
03796d2125dcdf8376c293b9a963ce8cadadfcc5
F20110115_AABWGZ onbilger_o_Page_028.tif
6047c5e2468455f57a9e737f3475bdab
049e4251af6584c9c6b531dd6ba5efdbf0b95112
111370 F20110115_AABWIB onbilger_o_Page_048.jp2
f6e67dd18566eab5a95e7367add9eb50
7c72d172eced77a4220f4f09104b75ebfdf0c9cc
23121 F20110115_AABXLE onbilger_o_Page_033thm.jpg
0ff5df8b2f820fb8d939c8e71fb254c5
1eea53a7319a6366fad0ec1c3904db4eadd74a15
86937 F20110115_AABXKQ onbilger_o_Page_162.QC.jpg
a2970510e3d77ac6e3f53ca120b59abd
ce5c68d800d99657962de357811ad0c1a12d0dbb
79118 F20110115_AABWHO onbilger_o_Page_034.QC.jpg
c8ec99845f74e3446aaca38d8e74958b
58a09317e2b8cb3b6cf4919bb1159a3fbb95b177
F20110115_AABWIC onbilger_o_Page_070.tif
04a10426810a70a5fb73a0e64eee191d
22fa38c822f2cd93da191624cc158d48e2777131
26952 F20110115_AABXLF onbilger_o_Page_130thm.jpg
f5161a18364b6685d20bbd3b176fbe92
904d785a23b98700df73abfa64b53880725eda0b
128649 F20110115_AABXKR onbilger_o_Page_006.QC.jpg
8f77ef60f8a12065df5c8d338fe8b6e0
d5b90ca3401d66948f7526780a31b66f35e6adc3
106453 F20110115_AABWHP onbilger_o_Page_090.QC.jpg
0a057c8114c468d998d676964e9a0035
a93ad4c0adea5c616e713bd0bfb20241a126654a
77470 F20110115_AABWID onbilger_o_Page_132.QC.jpg
8d4b9152857532704daf1a6476bbed6d
e97a51e97f372fe778ce1037b07061fe4ca0f3fb
24926 F20110115_AABXLG onbilger_o_Page_087thm.jpg
cfed5e2c30d135669a9a7615211a6bbc
00aeff56f2a1bece86af197462ec1529b5436345
24458 F20110115_AABXKS onbilger_o_Page_034thm.jpg
938e06f4df00a92da12b0d57fdceb12a
3e6dc6010c2c0507764a6f5033e2d9c8886bde8d
153567 F20110115_AABWHQ onbilger_o_Page_018.jpg
0a0a2b5546e70c204d4c9c6b05c9c598
9a36d6216734522f9138a4cf10bef063ffb73039
194148 F20110115_AABWIE onbilger_o_Page_133.jpg
f14fc89d593dead0fea57e69f96f2e5e
476540e37245d9ff0ee45b9d513e4c4aa0280860
75029 F20110115_AABXLH onbilger_o_Page_038.QC.jpg
aebe6040f0defd27c2feccbbc65d98ed
1e94600d9daa12bdac79e00556e0da886a81173d
77541 F20110115_AABXKT onbilger_o_Page_052.QC.jpg
3c56291016ca6154773320dedcbc7330
ab8af52e9d5da2e16e9ce8d738b087e2db192800
49846 F20110115_AABWHR onbilger_o_Page_064.pro
dae8d97ca8e6285ca7fb1f86e4068840
6767529da0aaa812fe6b3098b2f20397637d6ad2
F20110115_AABWIF onbilger_o_Page_091.tif
a697ac941e6437d9081f5a861d6992cd
a22e62c7d8c3d1767a81c1ace1ef01a62dd8a71b
22221 F20110115_AABXLI onbilger_o_Page_111thm.jpg
2284f7f8d1be78e6913816072befa899
93eb291e8bad10a39e7b54172f2a30ee1f69c3c5
21229 F20110115_AABXKU onbilger_o_Page_020thm.jpg
dd00ffb27cc47d399da6f1eba162669b
9aa484a231efca8e23020fb5b4352f9c9aa6d842
2150 F20110115_AABWHS onbilger_o_Page_073.txt
b888862999485eaa58610fca89ee5e96
7649713b6d89bba48a79e8438ab8166e2580ef90
11825 F20110115_AABWIG onbilger_o_Page_117.jp2
e66a4e603ec7954ec0583278ca8fe34f
a2eacc99f56538c27f0590021e6a6719367d31be
77462 F20110115_AABXLJ onbilger_o_Page_051.QC.jpg
8bfc564e2c39704466b50de5268da5b5
8951d7732aa3d302b22464e817f05f6a6a734925
76620 F20110115_AABXKV onbilger_o_Page_109.QC.jpg
e95a6a0ed1cba12b6000438f489c4762
422fde8b34133301a07800285f21fa92f70435bd
16198 F20110115_AABWHT onbilger_o_Page_140thm.jpg
e31e48a6a92a549f8200f55129028a85
a714cf6fac0de9e8cc4eb4c87c42c808f264834f
132286 F20110115_AABWIH onbilger_o_Page_077.jpg
18a12d6d3e3bf7b3f46da21dc976983d
4f9dc0a7edc58812d889bbdc1ffa493e45a770f3
17557 F20110115_AABXLK onbilger_o_Page_011thm.jpg
c8e27665cf552c0fa020d3b48604a9b2
6e186c8937d8146a54efa78bf2ec7bd466056c7b
24483 F20110115_AABXKW onbilger_o_Page_157thm.jpg
e924bcd5956daeb7c93d9ebfff52df4a
73832c9e70e830758690767b8bbe99ab5b927261
F20110115_AABWHU onbilger_o_Page_053.tif
abdf0bd7c197ff4df7f8528f5ea2e811
b3b8b46fc2ce79e8f17956d10c2655d1953476d1
74958 F20110115_AABWII onbilger_o_Page_012.jp2
39bfac80eb8b7cf115759d50c0fb6473
8901ae97b3baa2ffe666c6b2d433f1b48d10484c
21825 F20110115_AABXLL onbilger_o_Page_013thm.jpg
829302edb06f99bf8de33334761dc094
6356e3e4d45d7df9fb7644e80efd9681c7663a23
45191 F20110115_AABXKX onbilger_o_Page_005thm.jpg
3c0eb9897659f12bba23990ef19cf439
a1746b53e511c82f85be95e79324dc43c1400b02
193119 F20110115_AABWHV onbilger_o_Page_062.jpg
ff4b41fc189eae074b28a83a114215e1
53544f169f156b370602ed27c8e8761b0138acd4
1767 F20110115_AABWIJ onbilger_o_Page_063.txt
52d8fad86345a8020293a6a03f438823
1f921926f00fcee1da1f0166c7451aedabf04ff5
40555 F20110115_AABXMA onbilger_o_Page_113thm.jpg
a8d8ce65475838c31564a1f4d8b8c759
448f19e14ec95a3fe61a26aff7f99b6b2327b86c
7043 F20110115_AABXLM onbilger_o_Page_001thm.jpg
5ae6380a683b31169064ac87137a21b1
3fbb8d249ef9f03e1c3475fce18686420a3795a8
86481 F20110115_AABXKY onbilger_o_Page_160.QC.jpg
a2546fa3ac9e8abab80e64504f9d6a19
28f8efd427b41c4b7383f35419fe5e740f1dc9e1
46183 F20110115_AABWHW onbilger_o_Page_032.pro
d43e7b69473a8eeaaf703a157f1b5393
41f8c6b8db432822ae21a34b3ee354527adc6ff7
206281 F20110115_AABWIK onbilger_o_Page_084.jpg
7dc9ba93120ca6a6070ab8c6b0331937
cb3ec87f9e8018db1d1a9960118d4059405a2461
71202 F20110115_AABXMB onbilger_o_Page_046.QC.jpg
1f4adac74826edc081331787709af4d1
245f56c275b1b4bd37201e535296b0176eb48381
76925 F20110115_AABXLN onbilger_o_Page_089.QC.jpg
6cf5f002e19262a33529bc8ef4dd4222
28590a97e2c46e7ba913735166db69a3044f9937
23729 F20110115_AABXKZ onbilger_o_Page_075thm.jpg
e5d45b9df3de460e8925aafd2d36b576
a77e3d4b47430133c1c91a99ebf3242706e7297f
51061 F20110115_AABWHX onbilger_o_Page_036.pro
05a8d20c06c3acb104f861a78c9e611f
670c7976e9e0baba1d1f4dd7554d3aad025f61c6
1574 F20110115_AABWIL onbilger_o_Page_083.txt
c48ddfe706040de0c04efec39c433eb0
1e3ad53e9fb692cab5a76c0917c455915e1d2baa
78846 F20110115_AABXMC onbilger_o_Page_028.QC.jpg
8e7d91cd439c4baf43672d665bbdf4c4
a6a77999bfe4b5ba4418898b5750d6eb82367ccb
69005 F20110115_AABXLO onbilger_o_Page_135.QC.jpg
677274009f7b950383c64b8410902a07
563d6fac8bd1c84f1c9c442d9021948bbc244a6c
214041 F20110115_AABWHY onbilger_o_Page_042.jpg
8dc21d0402c06b0433ef1fe1260f7486
cd8704e6d533c6d0f7ed04a393c445716f717931
143224 F20110115_AABWJA onbilger_o_Page_012.jpg
ae4b9d77204db98e465c3224bfc53f35
7861b57cff5d02225597fc84a4eeaaa7c595176a
110257 F20110115_AABWIM onbilger_o_Page_036.jp2
2a672b8641ef8edd7cc645ecaa814c86
551207f7260f8dcb1812219322fe016f9095dc25
18285 F20110115_AABXMD onbilger_o_Page_001.QC.jpg
401599f750487b5046ff46a7ddc5cc53
4333438eb2931a29355e23f2e37f6f5bdeff5432
74116 F20110115_AABXLP onbilger_o_Page_145.QC.jpg
d5f307d5c63da2c931956246570e569a
a65587e6d5c4457694a3597384ed30d720aa9049
53368 F20110115_AABWHZ onbilger_o_Page_159.pro
2c0247849017dc1ada3e1a4808421b57
acc874a7aab7760a917fdaa7a81b1123c52bcd62
212174 F20110115_AABWJB onbilger_o_Page_014.jpg
f61a9e27cccfd841abd26bb0f2c59f8d
1196c399f574976e781de5cdab62b8da83a66d65
20000 F20110115_AABWIN onbilger_o_Page_167thm.jpg
f000002b5ce2b64b19f701532a7180ae
b6fc148338530e1705ccc4249bdb562472670201
82076 F20110115_AABXME onbilger_o_Page_048.QC.jpg
ea99097906d4952cbd33393b06dc8e03
7689e92a29bc48465ca7686f672863ee6316cee9
24983 F20110115_AABXLQ onbilger_o_Page_119thm.jpg
ae0919ce7c316a0fe6124f1dce89109c
1c88e147f9444b682664be57fa606045270e54d3
176045 F20110115_AABWJC onbilger_o_Page_019.jpg
11d66c958293eb963a0578d13f1fbb57
b66df3906ee37559019206e2ad4f0abec554cdb5
71441 F20110115_AABWIO onbilger_o_Page_126.QC.jpg
4db99eacd37eb01ebae02b4d26b7c637
c9dc84d1e6b57d5019ceef7f986c19b3337b1d5a
60040 F20110115_AABXMF onbilger_o_Page_080.QC.jpg
e0730e126fc18605e8c3767a98c09466
980c38f83b476d256ba8d23e2a022b3157dc2c3e
23200 F20110115_AABXLR onbilger_o_Page_120thm.jpg
b7b0087b3791cb8b9c5ff1f95a96f1a6
735b166899cd034d33cd998ae7cf864a711065ea
195525 F20110115_AABWJD onbilger_o_Page_021.jpg
276fb84c130475b304540f242bdf1a2c
147742230ce3c5b53401987921dc22d35827c6a2
107982 F20110115_AABWIP onbilger_o_Page_022.jp2
9724449d81e1ac4b4e70cc52ae732af3
a6cdaf96261187700344f4d6434983d9d89e71d4
25491 F20110115_AABXMG onbilger_o_Page_030thm.jpg
48f00631bf77eba2a9dd82a13501446e
c448a9354c6558b7b3975540adcefb1931fe2039
19839 F20110115_AABXLS onbilger_o_Page_057thm.jpg
818c60d90da2422ca44a51c8a9c53437
2a7b1a9f37ddcb6e57cdcc871ddee156cc433293
205088 F20110115_AABWJE onbilger_o_Page_023.jpg
7585fde47d89297fd31d67cd1d593ba3
4237383b2156bb56be78e16b9a3a1a9edef8f83e
195073 F20110115_AABWIQ UFE0008327_00001.mets FULL
e1e9e920135d35d6c3f0f426cdd3aef3
5d768199e2dd952f4ad241ee27b1255d806c2a85
24057 F20110115_AABXMH onbilger_o_Page_088thm.jpg
5a4fb2e2d10688c21bb5c94abed8fe1f
8be59a80dc17099cfe708341dd556f2c3ef5d338
24131 F20110115_AABXLT onbilger_o_Page_109thm.jpg
b4662653d6f0967fe2b7d4ac67ef4aac
65dcea7f938f2521b193d8628e02c715d7a1fefd
162967 F20110115_AABWJF onbilger_o_Page_024.jpg
b396f3809850f0017615d79936b488db
553b1f4560aabe2222262a2241e6b8695b0e3634
69541 F20110115_AABXMI onbilger_o_Page_062.QC.jpg
86aebbffbe9cb0664ee08f4b2e434b41
1c8f61029eb6bcc1907407a9aa5ae58bbd641d52
21464 F20110115_AABXLU onbilger_o_Page_047thm.jpg
99d3dfb4446dfbd570705890c3fa708f
17b6b428d0d9c36922de6cd16370602d1a3d2e2e
201848 F20110115_AABWJG onbilger_o_Page_025.jpg
bfcdd4748a3ab8665bb3f9c5a3756a3c
810085d3052ca623a17fd0b78d89f94f7e2e5b29
86220 F20110115_AABXMJ onbilger_o_Page_130.QC.jpg
6c91ad5c002c784a391fc0c6439ad058
8a5fa734cddf12e9c16c07ec66b8c613f5089817
95278 F20110115_AABXLV onbilger_o_Page_148.QC.jpg
f80ab92e4e64dc085493406a507521e1
e5c0b6e9e14a11ee1509e0ddfcf03b437f043293
197293 F20110115_AABWJH onbilger_o_Page_026.jpg
dbd31a91313fd6c47679dc08d8ef3390
fc45dced1d14f67e3913b7947dc01e5e4be74ea0
50760 F20110115_AABWIT onbilger_o_Page_001.jpg
3ed1391fafd7d7af1ba7b2757ed0b233
4b7d7f8a57bf61b64694267d2cb1ad875db90535
23953 F20110115_AABXMK onbilger_o_Page_070thm.jpg
896b092e8640fce6c9257ed09d5250be
dede15ce787299cfd567aa50fee4ed31d73a8c15
48422 F20110115_AABXLW onbilger_o_Page_008.QC.jpg
aeb6c3ce51b4804886ee2eeef26da1c4
0255c5aa05987d24e5e3756da97eda496d4da983
167469 F20110115_AABWJI onbilger_o_Page_028.jpg
326d89ba3eac6bb3e2a7d26aadd3658a
3ffda91fb2c38a0a638dd7296399256de8f0d95c
15218 F20110115_AABWIU onbilger_o_Page_002.jpg
208f22d5b818e7ab444cd6b104f86726
26dcdc978b1dc3fcba93480000e4c26a0f7aa85f
74441 F20110115_AABXNA onbilger_o_Page_044.QC.jpg
955ba06549012a3db3c8bcafcd7f147d
5d1dc1cb43f9383ba0b3fd4905dec877e28fd8cc
77401 F20110115_AABXML onbilger_o_Page_075.QC.jpg
23a00e685b6cbd756e446dabdb690520
a50c6da917e900a56fbfa6acd46699e328c6f5ea
32263 F20110115_AABXLX onbilger_o_Page_008thm.jpg
720fb6f2587abf10dbfeb8d881430dfd
2625b71be0799777767cd7f2c0854a053aa3bfdb
200951 F20110115_AABWJJ onbilger_o_Page_029.jpg
6f146fd315581aa8d3b8c1b6182110c0
7a2dd447219afb32a940478c8dfe78456898ab1c
12469 F20110115_AABWIV onbilger_o_Page_003.jpg
c9ce66dfe6e700d772934a817f46f53c
ba5dc1d60e87460d81139ece5d33e97a1738a948
75729 F20110115_AABXMM onbilger_o_Page_025.QC.jpg
2c17e35459649763326141215277c977
d9391c03193f3253f3b3ef862d881eb65392cc56
82941 F20110115_AABXLY onbilger_o_Page_039.QC.jpg
e7133c3d3cbca26d8aaaed61e3dac6cd
11ac73bfd12838e115668186590374c1731b715d
209085 F20110115_AABWJK onbilger_o_Page_031.jpg
a6e67fba34c128565a68686bc703883f
7c689657bac74aed91a27fffe42c23287d462e4b
266417 F20110115_AABWIW onbilger_o_Page_005.jpg
b9609a21505c7b0a634842278857d021
1d6cd6cb862a971b2e19bf7ebd0f6a6601959c3a
22811 F20110115_AABXNB onbilger_o_Page_133thm.jpg
2eb8ab82e6c1c959ef892585959e8538
5f45694b1a703de07db753612f40f461aa5d52cd
24003 F20110115_AABXMN onbilger_o_Page_132thm.jpg
b5cd573a8b49f651f3ea9b3d0a1b570a
1dbe3de4e83872fef5b4d32ca69d3c93774be3c6
24104 F20110115_AABXLZ onbilger_o_Page_021thm.jpg
3289bb1a6caf99c1652a96b0e37c8ebb
f79f4003314d5dc59e8ee7f584804e11d3b23563
189741 F20110115_AABWJL onbilger_o_Page_032.jpg
85a298e74b6bd96dcaccf3eb4a076fb2
4c063659025d6214fbca1fd8d84d2f0ab74b33b8
195333 F20110115_AABWIX onbilger_o_Page_007.jpg
6c3c10956641bc684d21dff5e0f813aa
17a15f15bde1a37a411f18dc00eb5b1fad422d68
5070 F20110115_AABXNC onbilger_o_Page_003.QC.jpg
17f7a57138ec6309817ad0ec200ea688
84a4f0c522bd954fdc7c885dad247d8d0493da9f
21751 F20110115_AABXMO onbilger_o_Page_156thm.jpg
aad43e74b6668001b300f60bd140e4e6
accfefb42935f1be99739b4529efe7ba77d2d7d9
210243 F20110115_AABWKA onbilger_o_Page_051.jpg
10a92a734efd6a3b17b07458a213103a
1d893d5b30b46a03ee394ef377c714a79102d420
210866 F20110115_AABWJM onbilger_o_Page_034.jpg
3eb4a8d7bc74bc68a763a1b9e49fd8ed
4a396d45e63226e6bd6a9d5cd73c4b9dbecbbd2d
86599 F20110115_AABWIY onbilger_o_Page_008.jpg
3778ce930d4085755c71f15a16493e8f
af173dc7cd9cc9009d3a837d59ad99f787ef478f
80572 F20110115_AABXND onbilger_o_Page_068.QC.jpg
11c6686d22626f5ae52e2264fc379d09
9b395e2240d0b57b7a99517ebd513e27e5f2ad99
4416 F20110115_AABXMP onbilger_o_Page_117thm.jpg
dd77b5ee50bf8301c87f5b11a91de4a6
927f54b5731c5022928bb98e204b0913aec48904
186458 F20110115_AABWKB onbilger_o_Page_053.jpg
d239b04c3211f32f6ceabbf9117dfc24
7a01f23474651fc7d12fc86411b9e1d4fc0d4900
212490 F20110115_AABWJN onbilger_o_Page_035.jpg
6d66b31b85b224e51a5c85bef235a200
54878fe2e7b4879e6deb5783fe99ec4cf7cf94a9
119352 F20110115_AABWIZ onbilger_o_Page_010.jpg
4448b10610064a3fc5f3eeb8231ae22c
34c937b9b47d4290ab6a8fd64bf7ba495414c645
34904 F20110115_AABXNE onbilger_o_Page_168.QC.jpg
d5f4b1e59ec6c4906b14bf559879ae98
b903554d1b77a25565a4ac043058dee3be7d36c7
75320 F20110115_AABXMQ onbilger_o_Page_060.QC.jpg
b866f9fafca460414d152162847a4048
01177e3a87a8eb378268d68233abaa31247ff6fe
165232 F20110115_AABWKC onbilger_o_Page_057.jpg
076656b6208837b86e5cb494c6da0c33
bafb173716b57dad5590d741774610addd7340d0
212556 F20110115_AABWJO onbilger_o_Page_037.jpg
bc243e7a1042cba40ea541802d10d076
c16b4b970e93e7bfe146a11670977027f0fe649e
14973 F20110115_AABXNF onbilger_o_Page_155thm.jpg
8734bb942a6e932fe7db9d121ebac054
f9d5c41664d5220ea268abf71ac4f51fc5dd262e
76680 F20110115_AABXMR onbilger_o_Page_086.QC.jpg
e6c1cd81d51486ab5ea96b42a21feb12
973216dd7adf183e96bdec835a042dab37a8c56e
194517 F20110115_AABWKD onbilger_o_Page_059.jpg
6ef7868faa82c23e41a187077553f7ef
62cfd9f05bb2cb40e9a7990de7bd573d82f9c9a7
199320 F20110115_AABWJP onbilger_o_Page_038.jpg
0bc11bf2f0810cdbb16c5e6cc987bc62
1c665ca87d6c0791ef64898ea1c63af3a6cbc190
77145 F20110115_AABXNG onbilger_o_Page_040.QC.jpg
ef8e850321dcb3f13407c4633f7f7796
7ed04434d970878d2d1f186dbb583a50795a8d4a
35166 F20110115_AABXMS onbilger_o_Page_142.QC.jpg
38acdd41647f1537c38945d475a9834f
5fa6799c6e5d2ccb9c17e46f77f1d4280c92a6e3
198251 F20110115_AABWKE onbilger_o_Page_060.jpg
72540286a57b55ec50ea9fd34363afe6
bf01647f34c123c130dbadd13372034f67aa89bd
224701 F20110115_AABWJQ onbilger_o_Page_039.jpg
ae209a49eb62d2a60140bdb27fd45c8d
421efddd870239e2a8b95cc949770f0a8796202e
25273 F20110115_AABXNH onbilger_o_Page_131thm.jpg
4d235a436ff0c32ada7f19ab82e43b0b
29f9b575d1b6c65841df3387fe909bf1bf7022bf
23275 F20110115_AABXMT onbilger_o_Page_016thm.jpg
80ce84041885dc4932c525bba54d23c2
066774a954e81544d6032a2bfc7a7cc47019bc0e
219628 F20110115_AABWKF onbilger_o_Page_061.jpg
585614abb3fb39f334e19db6a983f92e
13777768bca235f187e8ba93301f85a0c9e0af48
186624 F20110115_AABWJR onbilger_o_Page_041.jpg
ed531aeab1d8669d87d3ebacd967fa85
e1c894b3868a89aecf693674b60ea311086e6fe9
41582 F20110115_AABXNI onbilger_o_Page_155.QC.jpg
809207cda08596749c150186a98fc9b5
cf8cc1e745725f410ca81810f6f900bc2ec6d3b4
60778 F20110115_AABXMU onbilger_o_Page_141.QC.jpg
f981fde3cd51a3026aa193d356c0a9ec
7f332678a66bebff947ad2b618bf631748b47711
183575 F20110115_AABWKG onbilger_o_Page_063.jpg
0c82a1948d3eaaa83ddbbfca3be29caa
24691a2b2584e2892fb1ef5fdc44d11639c84676
210428 F20110115_AABWJS onbilger_o_Page_043.jpg
23ab9806b41cba7e48b9c070e3b29425
894d7020373706a31c15e24f8a1d0d9ad2e662eb
20376 F20110115_AABXNJ onbilger_o_Page_078thm.jpg
95c23ce80e166aea209f2e9d98f51063
15e49987d3e084548acdae84ef3f2744623bf8ef
77927 F20110115_AABXMV onbilger_o_Page_112.QC.jpg
54612e9f393465f727d354bc835f3f9a
2abd9afdcd8441345567b19e77a423bcfc790d4c
206184 F20110115_AABWKH onbilger_o_Page_064.jpg
4b1ececc553aefa02199db7d6a4ace5f
651dae36adc0660a87118908f956430bb1794807
201989 F20110115_AABWJT onbilger_o_Page_044.jpg
7274470fa6d4af82c7c14778e1ea508e
95237c4f144c564fc33caeac0489c0d6a6240bc9
25015 F20110115_AABXNK onbilger_o_Page_042thm.jpg
e98132c89fa3cfedc24678620e960243
921805ac2f0a9d39a38e82294c8ccd88f168e010
23853 F20110115_AABXMW onbilger_o_Page_023thm.jpg
16f81f4f4788efac9a8528538c384824
d3f84de38a1a51624202e79ee21e1c0c79a54d40
47158 F20110115_AABWKI onbilger_o_Page_065.jpg
a47bfa538836a96e00c74506050eec3c
37eabfcd36e5cc09c00ce2352a61342f2be2604b
209333 F20110115_AABWJU onbilger_o_Page_045.jpg
1ef10d7ea260094e0047073f23090bdb
60f33e5e93b46858a49a070f57780caec00ff168
25077 F20110115_AABXOA onbilger_o_Page_060thm.jpg
1c6da517f7a692a9fd96a4b60945595a
d6e809a83b65ec531e32167091dbf177a53ba8ff
25736 F20110115_AABXNL onbilger_o_Page_039thm.jpg
eceb96c7581875b885e006c495a8b7a1
fe2be62959f0d35b1b399c0c1ba06660e3023c0f
90442 F20110115_AABXMX onbilger_o_Page_139.QC.jpg
103a85d994383d62a68c46773a656294
2849e7dd9457c1218ec6ce781af818518ab5365f
206697 F20110115_AABWKJ onbilger_o_Page_067.jpg
ba7d2f95b2e0b449ef74a827ea8a2033
dbea07fac44f77aab445e6e2d11a2078e0cfcd97
186641 F20110115_AABWJV onbilger_o_Page_046.jpg
6d7da23e1621fc7db0be29673110be48
f8dad9cc6363b80e50811a419e85cf55bea7b412
6612 F20110115_AABXOB onbilger_o_Page_065thm.jpg
c87d937e541a67f01bde92dc104aae36
bc75fb1c48aa747c7384c0653c18d7ce2c8325c9
22939 F20110115_AABXNM onbilger_o_Page_135thm.jpg
a13e9af4088bfe5a6ffe1520c3b8f400
3980aef87bc4b4ffb27d65f76b81eca2febe7150
19598 F20110115_AABXMY onbilger_o_Page_129thm.jpg
65916ed3529644ae354f01c17c90e529
271de0b930ee675803a80d086a18d0bb52697a7d
211857 F20110115_AABWKK onbilger_o_Page_068.jpg
d08cdf83422b7d8abac0b87b7cd6c446
42f6713b6d173743bb822c1787a9ef2164385333
188006 F20110115_AABWJW onbilger_o_Page_047.jpg
496ca239f55769b1d05946f5a8d185b6
cd00d7bb32fdf6c700eb8b896ab0dbd7948ba4c3
22256 F20110115_AABXNN onbilger_o_Page_093thm.jpg
2be190029935a86a2aeb2c221b9fe463
2a25ab891333bf0b69c7b0efa85ded75d6a6ab6f
23757 F20110115_AABXMZ onbilger_o_Page_123thm.jpg
9f7e422d571d6f2328fe9848f58554f5
9acdef4432e12d76c175d1eacd05442135ed21ad
219186 F20110115_AABWKL onbilger_o_Page_069.jpg
4ba8a53d2405a8c069309adba85160aa
853d16a47dba9ba617c7002644ceee55c073523a
215578 F20110115_AABWJX onbilger_o_Page_048.jpg
cd0bb2caa13631fb110d0f64962628df
7eb97c4649704cd7af9268b340f615ae1c34283e
67290 F20110115_AABXOC onbilger_o_Page_066.QC.jpg
acb225be6d1c1cac74eedbf2a26f79c5
d2ba60abd78b97e9c8c76ce6b05f0cc5a45f778c
46716 F20110115_AABXNO onbilger_o_Page_140.QC.jpg
33743a22fb0b0280658f0e8c51cdf540
a9c80f58e5c456b061941d27d48c5dce95929bd2
218875 F20110115_AABWJY onbilger_o_Page_049.jpg
e07fcefd278ffc3588665d52d77a5c34
18f675847ed647e01629b8a563fc9955909c446d
244161 F20110115_AABWLA onbilger_o_Page_090.jpg
0229759c15aa82b42e5c2879dafd48bf
a8336b59470b42e60423c452288f73fa30783478
210907 F20110115_AABWKM onbilger_o_Page_070.jpg
3e1fafa2db81f0ca75e070f03de25dfe
366767c8f577d36bb8cdc166ed14833d1bb8e93b
23127 F20110115_AABXOD onbilger_o_Page_072thm.jpg
ecdeb03969ae72844fca82be28f5e818
26a10a908d8544ea908bcec4d2c0156814d72ec6
83947 F20110115_AABXNP onbilger_o_Page_163.QC.jpg
a41041f89ed2ce4a48894229810f7e34
d7d913ab800c536d7d3fcb33fce7cdb9dd04e283
197013 F20110115_AABWJZ onbilger_o_Page_050.jpg
a82e937a94f269e3b470798bc796cbd3
94449c10a6b91ffb453c28c8f175010b934ede42
229503 F20110115_AABWLB onbilger_o_Page_091.jpg
0d8502f19b0ce4e6427b738d15f0f05a
1c43b62fb3e8a88ee8915dfa8c48c92594b9e356
245291 F20110115_AABWKN onbilger_o_Page_071.jpg
99228b30e49b2a2ea8026465121cde41
09e183e251933ee83c982ff3ca279c8ec03ad95c
25142 F20110115_AABXOE onbilger_o_Page_073thm.jpg
cc1da097f9c6e0d030f7ccf9bd33844a
d824492d66d2a99df5a4778f6a17b28ae38c6e8b
253226 F20110115_AABXNQ UFE0008327_00001.xml
81f27cb8b735d9f8bdcf1b5a9dac539b
18a639a13571e308fbe02c31fbc80cc436529c63
226409 F20110115_AABWLC onbilger_o_Page_092.jpg
42310d0585dcce02951c379540b23a3c
0c9a7f754c3de512d4264a0c4c63365e363ffde2
200028 F20110115_AABWKO onbilger_o_Page_072.jpg
c627cc434905c97f08a7dbd8dca688e2
603096d0c118c88227ff29d991811bf01bd98ab6
75768 F20110115_AABXOF onbilger_o_Page_074.QC.jpg
4289881996ac496b4e7b43b39fc406e1
01113ad1cd40bb1b111787aa40da6ca875f2e0fd
18202 F20110115_AABXNR onbilger_o_Page_004thm.jpg
5c528094e01dbbf4312db8ea17c300f5
d959a66b47007f34b997006c3c9f8083bf8a215a
217254 F20110115_AABWLD onbilger_o_Page_094.jpg
49219b9fc1611dceda6c813e05055d92
8092e81ea127f0df7374e28c31646114b581d466
208900 F20110115_AABWKP onbilger_o_Page_074.jpg
ead9ea93e723d5d6ccbcdb7baa2dd700
7bae50c5ae2b0e18ccb61b836d0ef1c75346249c
18203 F20110115_AABXOG onbilger_o_Page_077thm.jpg
98999b0a0ffe08c1ad680b102edb2e0c
87afebf3412ef281267c9483f9709ef2f8d23435
98168 F20110115_AABXNS onbilger_o_Page_005.QC.jpg
70df2bd1fb33ea6c3ee4c7536f0f1502
f05711eb2c6f8a1157e9e8938a5510046bf8e039
84566 F20110115_AABWLE onbilger_o_Page_095.jpg
ec7fc7691ffacd624c71864e554daca1
a0edcdcd591d142647c29f979151102d2d9aa3da
209055 F20110115_AABWKQ onbilger_o_Page_075.jpg
718f2104207c55fea2c33ff96361fda9
b28dea93b290bd1e8f2d06550f5b7aa5fe878b46
64103 F20110115_AABXOH onbilger_o_Page_078.QC.jpg
f707516ef3800cf3d96ec134eec3ceb5
9ea578ea0b2d4fc0f675019d1f95bbfe5713c8de
20818 F20110115_AABXNT onbilger_o_Page_019thm.jpg
8435076c8265c7e5bddd65313200b620
733e78cfaffb07d9f6c7faf85da160145fc3e8b0
166954 F20110115_AABWLF onbilger_o_Page_096.jpg
957bf2c7a03c90f44cb23bdc9a78681a
27074365d7e3e6f6115657ef0d0c1040612a6daf
182927 F20110115_AABWKR onbilger_o_Page_076.jpg
4e0bfa54ae4ddb1dc7b245a37bb1a587
5771cb9d67efc71984d14575bc3b484ffe7e0a54
31609 F20110115_AABXOI onbilger_o_Page_095.QC.jpg
66774d4358d90b8b289e9f1a239bbc34
7ceed9b70b176ce4d07a8c3c8d8ce3459998709e
62110 F20110115_AABXNU onbilger_o_Page_024.QC.jpg
4d432c656f76a5bb188ed443087e1b25
db21ab9249d166e145425c4dbe2e77177c872ba3
213187 F20110115_AABWLG onbilger_o_Page_099.jpg
b5d4dffb2141220c47279ffa1f8f23f9
d4d539c5b6f326120948c04c52fa785d1e9581dd
166137 F20110115_AABWKS onbilger_o_Page_078.jpg
09570ee02506b1d22d1c3576f5dd8d37
658186747620625d749cc18114419342f8f6bec8
62323 F20110115_AABXOJ onbilger_o_Page_096.QC.jpg
3265ff685de2a7ae7eaa007b178df214
6f5318040a27d23b4fc6e87648956fde2c9675ee
76604 F20110115_AABXNV onbilger_o_Page_030.QC.jpg
8c250e04f13226e01cd05214a19d8e31
271f9dd5d7596abe2229115ceb23a8e9fd298270
178661 F20110115_AABWLH onbilger_o_Page_100.jpg
6f7f67e79803a625dcf628c2dfb75d1c
128a3963ba46f5097765123ef4db01f727c46c9c
150130 F20110115_AABWKT onbilger_o_Page_079.jpg
af40aaa46d5479059c20bc312f69c5cb
49981e6acd9c2f6418041bebaa5a777908e4a29c
91037 F20110115_AABXOK onbilger_o_Page_098.QC.jpg
222dc5dac4be9ddecd21a6cc79e28277
41aebc59ff75821e913daf53d3fe860e92dce5d3
24170 F20110115_AABXNW onbilger_o_Page_032thm.jpg
8609cf231bbf30ca21fd791108e774f9
6ed3843de1725a2689137b698c86cec309fa789d
205462 F20110115_AABWLI onbilger_o_Page_101.jpg
12dff5be416c36233bee757d26cb9294
eac3a70b9df836f29d70a2fe9cebe09e22606c53
158169 F20110115_AABWKU onbilger_o_Page_080.jpg
0e49658db7db169fcd9a5eac02fb09bf
073265ff0a85eac7ba12e90fd233d5377fbae7c6
23343 F20110115_AABXOL onbilger_o_Page_104thm.jpg
410933cd5820408a98635003c6a7ed77
48cb3725ef660d934333ca8668a62cba94d1f82e
71453 F20110115_AABXNX onbilger_o_Page_032.QC.jpg
2ce368e0e4c48f615536b00e14884de6
e21f7f26cb406681eb5d07b764d1e8f16f06cf4f
165412 F20110115_AABWLJ onbilger_o_Page_102.jpg
4e0c94cc934f2b8209b8b860b53d051e
2f2c8522af271a888b934d2c91c6d7df1762684f
147954 F20110115_AABWKV onbilger_o_Page_083.jpg
1b530a4c9333e562b14ef6adec0bde25
336b105f0108f91f0b23a33369275c996d040354
72345 F20110115_AABXOM onbilger_o_Page_107.QC.jpg
f9febe52c01a69d349ca3cc797cd7fd1
603327846d9f8c51b31c27d8b0ab7dea7453eda6
20751 F20110115_AABXNY onbilger_o_Page_041thm.jpg
5f6729504aa8437baa0d2a7d3b9ce89b
8b36f4314612113b34d4e79fa686e839614c4a11
122299 F20110115_AABWLK onbilger_o_Page_103.jpg
03221d88d24b88b619171dfab51e22f7
5f716b43e5f2ac17c793adb0d3faa9667528c0f5
204240 F20110115_AABWKW onbilger_o_Page_086.jpg
e76ee7058284c4889a03780100012d77
6e361cff806a7e12b172f1ff05827e246d341f90
68621 F20110115_AABXON onbilger_o_Page_111.QC.jpg
a298ff67b81644b8bf11d0842aafc4d3
6636ab27ad3f6aad708c05c06541cc7e495ef5f4
22884 F20110115_AABXNZ onbilger_o_Page_059thm.jpg
1b155f997694818bc92e4d5f5416b6cd
8b8ad7a32276fa113cd0b3d41918812762e6cb90
190252 F20110115_AABWMA onbilger_o_Page_126.jpg
b1054232101e31affaa8e49e3427f760
19c2f0c29b3616f545a9283bc60bf7096407d6ec
226514 F20110115_AABWLL onbilger_o_Page_105.jpg
9de09e164e8bf991ca1b43e0c992a2bb
7c98b4c0b826f7d5bb3534d722f809d28faf263f
212608 F20110115_AABWKX onbilger_o_Page_087.jpg
c17324d09e209eb54236d3e191732b7b
cdbaf7f2b9718506dc53b63639364d35998bcc6d
23553 F20110115_AABXOO onbilger_o_Page_112thm.jpg
ecd32de4772c60145a5d2832c1a7a2b1
197e872d23e74ddf643ab44a56b2bd7a1504c936
192896 F20110115_AABWLM onbilger_o_Page_106.jpg
e3f3a26c459d104b920853e2ede8536e
4ecc6a8a5056b7f010d05dfd540ef5aafc36ce58
205601 F20110115_AABWKY onbilger_o_Page_088.jpg
b29a00ec0a27c5cb8bedef4d3827273e
09e92ec39e3364f1ce1ca43e52404123d0ae45d8
71563 F20110115_AABXOP onbilger_o_Page_113.QC.jpg
95cd37daa47c06dddbe38931a0054890
c589b36155080942d9c7b0a2a987026ead220df3
183949 F20110115_AABWMB onbilger_o_Page_127.jpg
af749902ba127a8a261a881d6f2bb19f
3dc465b1f348654c9e6fe8fdbbb395cfb4c6bc93
194279 F20110115_AABWLN onbilger_o_Page_107.jpg
79b55d6b3696cd04434c14be8f591c08
5d5090c2ab9373e6c8c74c25ea6f62044602c341
203543 F20110115_AABWKZ onbilger_o_Page_089.jpg
620a51abc318d22ac3317a7c0acd19d0
8e36b656533e9528bade1bb46a0233ac53feb29f
43081 F20110115_AABXOQ onbilger_o_Page_114thm.jpg
dede5d2c797c4f89b126b62a22f7cbe4
ea24506323fc7c2c0ee55de7f7aca4e5f0174db8
194766 F20110115_AABWMC onbilger_o_Page_128.jpg
b665929b6e3c95db1ee8846fbbe2f8d3
369f649c8f262cafca3674286712254be47b4a19
213445 F20110115_AABWLO onbilger_o_Page_108.jpg
986d4f8455271c08d736b4e894403bc8
9180862f62e0598db5c937b60eab818a5aadddb6
68408 F20110115_AABXOR onbilger_o_Page_115.QC.jpg
438a859f61e364bf032968c3ad345e63
69fe527552e4a8c4035a958cdfb797732cd39eaf
169016 F20110115_AABWMD onbilger_o_Page_129.jpg
c6f992791df96a63ecdc8a09d46837eb
cd2bf110ebbee33c9f400c01be93733c2aaeb067
203153 F20110115_AABWLP onbilger_o_Page_110.jpg
8dd86abfc9f30c6c3c86741e0c7e151e
1f3dfe754c24c2260146e231e5fcf6bee87b1d84
81952 F20110115_AABXOS onbilger_o_Page_119.QC.jpg
98dd13b3012ee09a7fa92cbd9248e281
8ab7eeed50cf4847a55a80fb4055e582af56556f
248160 F20110115_AABWME onbilger_o_Page_130.jpg
adc35e420c258ac5d5b13e09290b4599
51fd7b0af6f1875f564a7fda410e453d6c5c5197
187724 F20110115_AABWLQ onbilger_o_Page_111.jpg
4711b6ab9f8b96fe9d32b1f4bd572352
4fcc74c764534a096e11342f13cd3dbf57392418
F20110115_AABXOT onbilger_o_Page_136.QC.jpg
53b3d2c3f616cdced75c450325c82358
cc0d02f47721379060d961070b8f729ddcfb9da2
204138 F20110115_AABWMF onbilger_o_Page_131.jpg
9d0681cf9d61167d21f8e8e6ee210d84
52772c09ba3b327f86920c7e05ea95398ac5a857
204965 F20110115_AABWLR onbilger_o_Page_112.jpg
19d25938a3fec1b330a7f2f08c92a630
0d53ce4a1024692c8c2909e6ed8bb6e1f3e08ece
94054 F20110115_AABXOU onbilger_o_Page_149.QC.jpg
59db06b008b078c7c12e4f878c977783
6188f64c8c82d67385f54c00549f9f2b498e5097
208439 F20110115_AABWMG onbilger_o_Page_132.jpg
6ca503298040134d3f288c76b68d47b2
52bd6aec075287b9a5d231f259ebced492b58bf3
143795 F20110115_AABWLS onbilger_o_Page_113.jpg
949661483c786f785f5e5925148fbbd6
0bf44e3c8937f6085f79e69f1d5cfd4f30463d27
87481 F20110115_AABXOV onbilger_o_Page_150.QC.jpg
2bf98f9b5176d206dbf6abc4b1a373be
db5c7161645fb7dab0a5f4f9d04f28a30fef99e0
185795 F20110115_AABWMH onbilger_o_Page_134.jpg
5de4909dbad0043419d1adf76fe4e062
b886cd20f56a91892369ec0235d75831157a93cc
133529 F20110115_AABWLT onbilger_o_Page_115.jpg
0cfe0260a2febfad2bfbc121c1eb7483
139a9f7b0ce7b78e44b70f938eb4a185b783d928
25278 F20110115_AABXOW onbilger_o_Page_166thm.jpg
7a272005ec6f169ad6df3f8686ebd031
48e907d7657e62a36120ffce42b197341662a991
184204 F20110115_AABWMI onbilger_o_Page_135.jpg
45869bd766fe91708555b2f1d8d18822
fa5d5f27f8b3bd11e72168ec0d0dc6a9487021c4
24294 F20110115_AABWLU onbilger_o_Page_117.jpg
d23e8c235431c7baa494e04fc7bc50a1
1dce5c828ef766f70c28d847be1d7d225b72eb3d
67000 F20110115_AABXOX onbilger_o_Page_167.QC.jpg
bf4be3523f190e346a60af3c3fba34b1
5d518b69af5a2e7dd0e61da4c0104696faec3cc0
196779 F20110115_AABWMJ onbilger_o_Page_136.jpg
fb52cda6bfb20e4a9aa2f44908889c8c
492ea2e9eae5be6d6b1f0fffec57562a8237b544
174730 F20110115_AABWLV onbilger_o_Page_118.jpg
21f1456fa1bb932ea19f22f0201587b9
94ef8fe363eaf8a96e6def803c79f5f193f1a5bf
195006 F20110115_AABWMK onbilger_o_Page_137.jpg
ee3ca0830be8c9de03244a12c6d2e38c
303871bb8cd87312168530252f108f14d7f42920
219325 F20110115_AABWLW onbilger_o_Page_119.jpg
b8c9a72566a0eb9a58c39fbbc39d2ef3
8a91f02b8bdf04d59f8e7a75e472643be140429b
217765 F20110115_AABWML onbilger_o_Page_138.jpg
2341188fabd0cc21570d15d35e44bb30
ee2d969e7d2a2f0c458520932c58065a9d87272c
204831 F20110115_AABWLX onbilger_o_Page_120.jpg
702a9f232013ee22618c116d74eb8a13
974c863d8583b271a51c2d9bff0f36b5c4e4bfd9
275864 F20110115_AABWNA onbilger_o_Page_160.jpg
8358913419a7c1f8dc53f76caecc292b
ba353780d7bc3abea58a2f2541eeb6389f5a0352
197228 F20110115_AABWMM onbilger_o_Page_139.jpg
6c25342533d17673061f087098bfc314
517c3c59c50958f10a6404032058c1344b801c9c
200430 F20110115_AABWLY onbilger_o_Page_123.jpg
31b005c43a63c02bc443eb4f8795becb
150ea70c79a480f2da1878e98d2717fd2c4f26f2
290351 F20110115_AABWNB onbilger_o_Page_161.jpg
91668c4a80d7f446f5e762fd519d7b34
c01249f07c692eefa28e64924af0ca113c9ca008
122940 F20110115_AABWMN onbilger_o_Page_140.jpg
043dc898f133c78839797ce5f2821fd4
eac7cc3e2834a7e2856ca9f90a05e7f52772ec66
178094 F20110115_AABWLZ onbilger_o_Page_125.jpg
7f59ad5bd8b5857bedf406993b5b71d7
50ec986711a03975fa3201deca16bc94aebe7293
164843 F20110115_AABWMO onbilger_o_Page_141.jpg
245454707c1418579b3de9a8e64904fb
1f023d7febb836582d619414fb42c98b1b73b98a
251697 F20110115_AABWNC onbilger_o_Page_163.jpg
68915886c22c438e08ca15dc1a445c1c
76c2a3794694234394e790a1c144b4cc70de6ee2
88813 F20110115_AABWMP onbilger_o_Page_142.jpg
5c3c70b4e1bee7e3bc7f663eee8d4192
0fcdf642fee1f3820ec91c6c139d566d3376b89d
213008 F20110115_AABWND onbilger_o_Page_167.jpg
9ce547ac4ef93e3cbc1dbcbc85362fdb
a943538828a0cc9603a55b1adc64b1ec7d986b00
220063 F20110115_AABWMQ onbilger_o_Page_143.jpg
9f286f71cb876f9dcd32b92afaff8bfa
e3df7cdbefc4afe3a3720521c7053df77eee9900
90101 F20110115_AABWNE onbilger_o_Page_168.jpg
358cdc65c9d49f54fe8836cf3dbbbcf2
34db2497afd56c4dd16d26a5d4d9ae7614be753b
161296 F20110115_AABWMR onbilger_o_Page_146.jpg
9133289d7d471c928d2c5f47a6d3056f
50152ed5f9c34ca793eaec172bf36b92f75d09b6
22825 F20110115_AABWNF onbilger_o_Page_001.jp2
9a4ea730c7d0917de1e2bca5feaea83d
2cc9f17758cc67569cb06ca0a07ce1b7d0af4e04
214643 F20110115_AABWMS onbilger_o_Page_148.jpg
378ce8948a74e14fc9708899423c40b4
16cdbfbb1270de6c4439f17e000a6c9f7928695c
4814 F20110115_AABWNG onbilger_o_Page_003.jp2
de16dc955a4f81d614772bad49e65e9d
34fd9ade79ffa431a7a2242b260d14e66e4aa7f0
203103 F20110115_AABWMT onbilger_o_Page_149.jpg
e0e2ec200e647e229862b91acb1a30d8
bf116e772a04163c9531513684bea7a012617691
72477 F20110115_AABWNH onbilger_o_Page_004.jp2
b339565a7f1ce974869f762ba977d455
1ad27624e3eae189411ceafb9091699c0b9c3f31
187755 F20110115_AABWMU onbilger_o_Page_152.jpg
2133fb8a23c261c02c12e26b5c9ef9d0
42631fcd8cbe3cc698320d73097acccb494d1d28
1051969 F20110115_AABWNI onbilger_o_Page_005.jp2
86813b846ec73a294732b4287a144f5f
6866f7e2fb702704a7d1691af08246bcb3210caa
214656 F20110115_AABWMV onbilger_o_Page_153.jpg
47d834bed548b57e1141aa44959a0771
1a241dd3d7171436a569461fe554aa52588e3295
1051982 F20110115_AABWNJ onbilger_o_Page_006.jp2
d42aebf992531140062de2d785119032
069b1e8589b71315e366ebe6c4e89db91336746d
110577 F20110115_AABWMW onbilger_o_Page_155.jpg
c5e8dfd7f6c090a72c4a5f037a6dd67d
f030ff3756063e6068374e11d3060998e31db646
439252 F20110115_AABWNK onbilger_o_Page_008.jp2
2b2ba077e41a3a542a0ab40e9bb5fee7
68ec58fc03aa2c6c11224bf092464987dcdd2558
237160 F20110115_AABWMX onbilger_o_Page_156.jpg
fbc0a07008aae344daf1ed427dac7c63
bf4dccabdd8026b520fee536887547da60877fd1
107346 F20110115_AABWOA onbilger_o_Page_030.jp2
5fb90a71042288f2efe6414c41fc28d1
d88502bb4ce962ee614b4e1315092f06aba9ce91
1051964 F20110115_AABWNL onbilger_o_Page_009.jp2
c152ac216e2ee3e79e6dc9e52630e77d
e2b95ad4047957b0ac290c71dde0a2007b66990b
281606 F20110115_AABWMY onbilger_o_Page_157.jpg
52ce4606099ed7bb0ae75f9dde2257fb
f4ee29b0b24e29ae170359dc770e503ce44e6f9e
110041 F20110115_AABWOB onbilger_o_Page_031.jp2
c51b8fea178f48f0f4989bb5faffb0d2
2ef76f8f3702538827db471cdc053efd4ef88982
739238 F20110115_AABWNM onbilger_o_Page_010.jp2
5bd21f77aed8fc776b915c21ef6a641d
8b0ae03b791486ab56903b38eebd230dfe3d315f
36170 F20110115_AABWMZ onbilger_o_Page_158.jpg
d6e378668e463ab9de277ffd8cbba494
633942218ee0b74dac6a4bf22d8ce368298caf89
99492 F20110115_AABWOC onbilger_o_Page_032.jp2
d3c427f5e01a787b0dc8cbebb26ece45
80ff12048db725dd904c1b452b91db51f4234841
79771 F20110115_AABWNN onbilger_o_Page_011.jp2
5568cec588b4f3d0baa20f04c1436b50
7b19691c9b16282454066b16e87bb98b76fe2637
110781 F20110115_AABWNO onbilger_o_Page_014.jp2
0268840c60b0751ee593c94fc18f182a
5cb61fd5e0f427ace4bc63f228f54a990b11881c
110567 F20110115_AABWOD onbilger_o_Page_037.jp2
45dc683bfa6a688fc99de0c30f1a1606
5e02a4266a8721e44e77e46e96b2ca91fd18825c
106146 F20110115_AABWNP onbilger_o_Page_015.jp2
09b8731e5cd4bde81f7f24f48c0108af
6805ec3d52f33c13c476e8c11f77bbd8e0156922
115229 F20110115_AABWOE onbilger_o_Page_039.jp2
b99b5b0f8ca1d6d1b466d3f5223f01a6
4efc383d6025e08ae053e7c46dabdb02e3d691d6
107227 F20110115_AABWNQ onbilger_o_Page_016.jp2
4cba5b83a6d90bc4b62cedf725b2acde
b44a14b323abc431ee12270ab0be1d7a34d926a4
107351 F20110115_AABWOF onbilger_o_Page_040.jp2
db3a5a4e13c3a45fb41e3619a3f588c0
6088cf59aef1026efeb60afcf365101c7a5f8680
79704 F20110115_AABWNR onbilger_o_Page_018.jp2
fd9c9cc7a03bb54a14eac2ac252b13f8
2527684d9433ba0cfb93705d93c54f9356654e8d
108413 F20110115_AABWOG onbilger_o_Page_043.jp2
c2d917017f3b4e079f3378c260940471
1fa9dff77d0d215920b949df7740633483c6dd51
92747 F20110115_AABWNS onbilger_o_Page_019.jp2
37d6fa5ee55a916d673e7676eaf0b1ac
380a78a853a9df74df53f3e9571202d9e811e961
104072 F20110115_AABWOH onbilger_o_Page_044.jp2
4a571db80d93617fa743ba44b63e2ccd
41948d3e1559a160d7a32def74d39eff6529a4b1
102882 F20110115_AABWNT onbilger_o_Page_021.jp2
35eb0117dbb8e11521a2ce249cfc9a9e
fb7074f0c41c1b655963aa841bb3edee3c2c9683
107159 F20110115_AABWOI onbilger_o_Page_045.jp2
14c9b431d91262ac1942535fcad1d2cc
5e5549e555180170b933a9499eec326c5bfbf604
107412 F20110115_AABWNU onbilger_o_Page_023.jp2
866ba37e9f2e9d028c5a39be18006fc5
f260f3dc2c0a3d3d18ece91ea597690fedcdcd54
97433 F20110115_AABWOJ onbilger_o_Page_046.jp2
525e9f78c41c39f16d6c1f9dfe71b853
16d41c0313ecabeb212128c646eef1cde0d21114
83097 F20110115_AABWNV onbilger_o_Page_024.jp2
0a7206bf50162ad113fca08a6d9311fc
9232815229fafb9514eff36b245ebc9a619511ff
113207 F20110115_AABWOK onbilger_o_Page_049.jp2
703c01ab2224098f35476bb8c5265ff6
6f2ebaeecf4f2998a7b8fae3d7e60d0555900acc
106757 F20110115_AABWNW onbilger_o_Page_025.jp2
c12928153ad9c3228f54e42e738b7252
abdd89415dcc5b641a9a01c9ce9c40e16c2919a7
108378 F20110115_AABWPA onbilger_o_Page_067.jp2
4cfeaacdcb94ce3463ec4b3a50127ef1
f239a40220820eb98cbdda5ba9f465dcee2bfa86
102932 F20110115_AABWOL onbilger_o_Page_050.jp2
8bca4df200261fc5e7bb35b742679864
afa7bb3cbcd74bd41d34499d523be2da51aaf08d
108869 F20110115_AABWNX onbilger_o_Page_027.jp2
81eea1efefd3528952908d9d73ec8439
ec7c195589346d71ae5232657eb56e06672351a8
110396 F20110115_AABWPB onbilger_o_Page_070.jp2
7a57e79eaa4aa9c8338db17475443d3c
65dfd7bb6030e22058d5a0f61fdb040d7caf4f34
107786 F20110115_AABWOM onbilger_o_Page_051.jp2
af780665926ebcce424af3a3560a15e6
fd75227ef6451bc4bf6577e92e39bd844934a23b
742964 F20110115_AABWNY onbilger_o_Page_028.jp2
e74310179463a015cb04842146f0ce41
55b2b570124f933f5487da7a20e9b390e5729797
114339 F20110115_AABWPC onbilger_o_Page_073.jp2
03d5f7f1f663916d701eae0acaac37c5
8ff45bf034ec9a5dda38fc132d98ac220225608c
105061 F20110115_AABWON onbilger_o_Page_052.jp2
504289635e11198961573f9a24321c16
7aafd7703650900ccb3d8193a13e1458b8fa7a9d
103514 F20110115_AABWNZ onbilger_o_Page_029.jp2
6f8a07b1f19956fb1c5c6c5fd1affef9
c4fe4dec94bcec1abd5cfeef97009ba9d26958fa
94263 F20110115_AABWPD onbilger_o_Page_076.jp2
887ecd4b4b83af65bb13a535344791a2
47f8b0ae4e64568022c04cf68a986e9c2b398e70
99957 F20110115_AABWOO onbilger_o_Page_053.jp2
e9ae72883cf8df679350d78bbbd033b2
517e6637b567889b78131959ef168ba0c6d6d2da
74428 F20110115_AABWOP onbilger_o_Page_054.jp2
230f3cca3e0f8aade8cf06d85668adbd
d0dbc9d1090acdefc00caf082c6061148f44c659
72515 F20110115_AABWPE onbilger_o_Page_077.jp2
339bbffc87147329c5f710ca06e2844c
b5863b6eeaf95a11cb7c91f4cd07001cac07467d
73419 F20110115_AABWOQ onbilger_o_Page_055.jp2
fa232b173617ee2597437b198fd8623e
dbdbc100b51b18e85f8328ae07d95938262cc9e7
84635 F20110115_AABWPF onbilger_o_Page_078.jp2
e3cefb1ae21b32d93937a4f858c7082d
eb1449cd06f760a4cf8686515d082c84e828749c
85374 F20110115_AABWOR onbilger_o_Page_056.jp2
0d3a2285ba3cfb5e41cf88e724c6aa70
44f9ecf26db324623f91064f920a54e8fde20d4f
74884 F20110115_AABWPG onbilger_o_Page_079.jp2
b8c5eb1dab169a973b14a330adfdecee
3bd6d8c8a70d03565a129d25044056c842ae578f
84827 F20110115_AABWOS onbilger_o_Page_057.jp2
a82299c4ccdab830221b5cdf5d830295
0c6bf59a9c11e27f6ae24cbaa6f1bd0970b70d6e
82537 F20110115_AABWPH onbilger_o_Page_080.jp2
9bddefca672c189ecfc9e8a71245a5f6
2136d4ca40375b6f028a63bde26746412f88023a
849267 F20110115_AABWOT onbilger_o_Page_058.jp2
a8957524364589b2424a6b42c378d43e
2057cc00fecbbf5ef1098d1baafe083dbe0b557c
77557 F20110115_AABWPI onbilger_o_Page_081.jp2
289a58f8f7f09a092da85a888fccc1b2
288334686fa21c9f6b7704e20e7163137e91d9ce
100132 F20110115_AABWOU onbilger_o_Page_059.jp2
f1d1cc54f2accf9cff5f0319545608d6
e63e60e3cdc3b7bf1b61268d66fb9547bba23ef8
104575 F20110115_AABWOV onbilger_o_Page_060.jp2
08702abdb56f52ccb88c95746218a55a
e2508a37dd0e0a45bb068fdc24b7b70b121156d8
75743 F20110115_AABWPJ onbilger_o_Page_083.jp2
fd8de17efd4260e7a01f5ad654542123
73680a95eea10cee696763ea698cceba9067b2a3
111605 F20110115_AABWOW onbilger_o_Page_061.jp2
90b75225ea60607cacd8f8228657e106
7ac404cacbc4a54f34e5e21c5e15bf94d983cf0d
107410 F20110115_AABWPK onbilger_o_Page_084.jp2
db34fda318d16e661c25d24637758178
9074fad8be5f4d432ec8a7ab5c73fe47f10adb4d
96299 F20110115_AABWOX onbilger_o_Page_063.jp2
5e5cabcfb13aa77fa7168abfa299449b
6137d6b676bb63b77dd05ef976eb005b8bf6f8fa
101325 F20110115_AABWQA onbilger_o_Page_107.jp2
c10a758040381b9a1ffd9b7312dcfae9
a3f95386c213149d56afbdd9d692092936127b2e
106634 F20110115_AABWPL onbilger_o_Page_086.jp2
34b4651d913901e0055bd498328462cc
0b7066717dbf21b9d450010e7d8c7a892c64ede6
25177 F20110115_AABWOY onbilger_o_Page_065.jp2
c97594c048823ac8510eca9a87c8e35f
649f713430f3f19ed5f81a7a1f85ce29b8b74a6f
97753 F20110115_AABWQB onbilger_o_Page_111.jp2
44a78d2573d3e4b6820bb538677e62c5
1d336e3bd577d7acb58e172c6e223b8c77dfc66e
108572 F20110115_AABWPM onbilger_o_Page_087.jp2
1d6da85267609ca495822be4834ed671
df62cccf2f5a92f85b2f572cba9d81a299aea5dd
94740 F20110115_AABWOZ onbilger_o_Page_066.jp2
f7bd92029edc6143422c6adcac82258f
966f74337975870234f1615de802ba9924cea984
104919 F20110115_AABWQC onbilger_o_Page_112.jp2
aa15b2a11495f1be6683aa6dae5fc7a0
1416c2c6d64bb3cb1597785593949685c581fcb2
105730 F20110115_AABWPN onbilger_o_Page_089.jp2
e89721d251e83f7119e73637da891757
6356062c9227381ec7667d4e897f14c7f4f5ab6d
621953 F20110115_AABWQD onbilger_o_Page_113.jp2
9738727ee7bca7f60353df4f4bd50a21
76496829821ff78e81088b726604feb755c813d6
1051863 F20110115_AABWPO onbilger_o_Page_090.jp2
b05b66c5faabcaf51b749f0c69d5d520
a0d1dafb87b08fba418097553c94910a02ca484a
101339 F20110115_AABWQE onbilger_o_Page_116.jp2
fa0a27dd12f00d593872432876ea6c79
f90dad34f63e762e2c8391d52c1b02937bdb71ec
117439 F20110115_AABWPP onbilger_o_Page_091.jp2
4e5e769a9a17414fa0de4dc8e21a764d
f6f58831060f5f84e28895b7a600cfc3674f6348
115963 F20110115_AABWPQ onbilger_o_Page_092.jp2
07aaa1f192a9ddf6145cc8d5f7652dc5
60b214b7cbf9fcef874639e6d71fabecebf8ca53
113802 F20110115_AABWQF onbilger_o_Page_119.jp2
00785e3b01f89b426aad1a927d94ff7f
83de9157f617ca0d4e9eb6417518793b4ae6e0f8
97456 F20110115_AABWPR onbilger_o_Page_093.jp2
805661d7c4fc65ebbfd1a61f816420f9
9b3a0bda782ebe94af16e3430eb9cf9a2dc27bb9
106640 F20110115_AABWQG onbilger_o_Page_120.jp2
9fcafff96b784a8a6d528c85a97a2fa3
2035fceb7bb7ec785febbddc7aa753eb066c4a07
111055 F20110115_AABWPS onbilger_o_Page_094.jp2
9f93caa3c96009c38d530b06f6fe3c1b
6269dbbba32ed212b68b813af44adcc4fc3a9b08
103154 F20110115_AABWQH onbilger_o_Page_121.jp2
a9238456941f6493fa274b51a318cbe9
353ed92b023035d52b66623a0b4e1c5cb0df6cb8
103097 F20110115_AABWPT onbilger_o_Page_097.jp2
d90eafaf5ab2fc102cee1a89407652f4
9a90f4831f7a6e03933f7da0963acc6dcf6e44ee
105889 F20110115_AABWQI onbilger_o_Page_122.jp2
6d92d26ee6519c7ff2fb9af36bf22f37
4b2149471d525ac9b8d251948a52c1ac4ff3755a
973354 F20110115_AABWPU onbilger_o_Page_098.jp2
5165db3cca549b746c9b247db099c791
dcfbc135c7852764ae6534fb6ef73dc6225b475e
99348 F20110115_AABWQJ onbilger_o_Page_126.jp2
92eb05ab32f624e1e94db3fd9fbaaa4c
1da63a32e1ba84492b6acf0a7f7e3ef6e108b69c
109494 F20110115_AABWPV onbilger_o_Page_099.jp2
161305309077a798a532ae79348f97a5
3186dec062ed65a371ff2ec03baba68dcc1f5b55
869131 F20110115_AABWQK onbilger_o_Page_127.jp2
c63de32227765125356ac6d664700444
e28028e77a264596c9e868b938e84baab3347959
828396 F20110115_AABWPW onbilger_o_Page_100.jp2
53ff8fec80ed58291f65a50654dbe281
ccb2f4bddc16a11bac8894cd29b7499dff1ce837
108906 F20110115_AABWRA onbilger_o_Page_154.jp2
1bc26ecc48f89b5b58062c6eeb70fb77
55abfcf1c361cc7d721c360a536f06959d8ff5e1
86913 F20110115_AABWQL onbilger_o_Page_129.jp2
30653d37a1fa427df6ba3a1d4b3c6940
b703cb8f521ba9cdf40f300691dff4f9e2acd50e
58481 F20110115_AABWPX onbilger_o_Page_103.jp2
e36f287363e59d702c5d21bac1270048
f8c157da6c306f96dd0613a16be8e1560843150e
58098 F20110115_AABWRB onbilger_o_Page_155.jp2
3df5fcba7b7e85e6be4734c074596aa3
21b45b9af0ca994624dc0f7e3c8dd320cbb1ee91
113051 F20110115_AABWQM onbilger_o_Page_130.jp2
0fe7ea37f75003fdc12eccb01584c28b
26b480f79684e93588e621357bba5071c0d3c3f7
105867 F20110115_AABWPY onbilger_o_Page_104.jp2
26020b9a5ba65c3af35b53e13060489c
aaa68861aaa04a72d4bb2cad1420af5137949edb
120257 F20110115_AABWRC onbilger_o_Page_156.jp2
c18a9f1ce57f4959c21bc47a5b712e63
5e01be014a0e3512894484a90fcf2ee1e489bc7d
109047 F20110115_AABWQN onbilger_o_Page_132.jp2
9bf215b28771b55d54c2e2c3155ceb41
3b85bd66303e33d8c8c4d2f359f6e517d61d69b3
114061 F20110115_AABWPZ onbilger_o_Page_105.jp2
5b0342d7f6865a1e77f924627e80c25a
953b2d73f5887b7c8c1fcc9c4a0687d81fedada8
18784 F20110115_AABWRD onbilger_o_Page_158.jp2
c6cd2a4ae880fe2b82abd5981ca133d4
036382654c1aaa9446dcb60d1d2b07d288fc80a4
96872 F20110115_AABWQO onbilger_o_Page_134.jp2
b1769da4943e8c581d438c564c6bf61b
858f74d913061bbbce1c5dfd86233e428f6a02c5
118135 F20110115_AABWRE onbilger_o_Page_159.jp2
f766e009f436ca21956725a293401fd2
37d9829fadaca63a0c824edc7c55c1847b51e5fa
102887 F20110115_AABWQP onbilger_o_Page_136.jp2
43c860bb6b07b50910fd79c268a8668f
2e05bd2c6357f9c8a2c4a38195b8235f8beb246d
142508 F20110115_AABWRF onbilger_o_Page_160.jp2
e3f3d8abb68c7ad219f86eea8f585f5d
ca18167d9cda6ec963bf16f38d621fadd34503cc
101726 F20110115_AABWQQ onbilger_o_Page_137.jp2
879a10603485941af8f39a98c062b7df
b29878d7d8519d6cb38fac8fd1cabdf99726a246
887457 F20110115_AABWQR onbilger_o_Page_139.jp2
f1dea78b7554d0bc3f17a0ea9002ecb9
1313dc05b42a2941efbbbe4c51be2ceda754d725
1051970 F20110115_AABWRG onbilger_o_Page_161.jp2
2d37436272bdd24942d82a74eded2bd3
72d9d313145510f97fb6c78fc0aacb6a05980108
111623 F20110115_AABWQS onbilger_o_Page_143.jp2
d45a7bacb61b0e2a95d10648ced7a1d2
1e994c61e5cdd31b6e5d7c3342660b19a8ec4176
139202 F20110115_AABWRH onbilger_o_Page_162.jp2
3c2a8e6e4ce6416046169a2914252810
92a8a897b84cc69e9b7f757b7980e60ea73893fd
98851 F20110115_AABWQT onbilger_o_Page_144.jp2
4bb60a74b77b373fc446a654acfdce15
ddff5b39cceff87410f49b73f52de37caddacd91
138105 F20110115_AABWRI onbilger_o_Page_163.jp2
566e38838fa34d74f146e7cce3dde6ba
2e2384cd335102db8bbc28ad509269a3cc21491b
1051951 F20110115_AABWQU onbilger_o_Page_147.jp2
800e251741ec4b108b8e954ca7d059d6
07f28992f079eddad714bebf21f1bcff48fb4f34
133765 F20110115_AABWRJ onbilger_o_Page_164.jp2
4544c4f47ac14f805cd69e76eaf56447
6500c418384b3bd488493ed41629ee4399c5bedc
929055 F20110115_AABWQV onbilger_o_Page_149.jp2
768d6705c78d664c055290972856f6c1
015e83b48b64d7d9cce57400221e3403548d066e
136806 F20110115_AABWRK onbilger_o_Page_165.jp2
6dff893620c7ba8d1e0313f0b42744d1
30549f7ac4c35adf2cf36e916e47c4fefbc7dd27
875954 F20110115_AABWQW onbilger_o_Page_150.jp2
37b4de55a6e3b4f455a75c1dfd86aaff
f9e5ac117a067cb8931fb16d97b622e64fee887e
136019 F20110115_AABWRL onbilger_o_Page_166.jp2
ccbc3e6bfed9d3e7b384b9a169508831
e5570fcdc6f38bba6aca0b9c992b8c4e1e9a5c3d
495540 F20110115_AABWQX onbilger_o_Page_151.jp2
01e6fe3e5a9b9cfe800a83684c062893
bf77be54df804557f0791567a5db276c5e229bc1
F20110115_AABWSA onbilger_o_Page_017.tif
985a5916ce34916c22c57c158975071c
4a629ca5dc8a39dd0658482af0a4327f4ecb1280
110716 F20110115_AABWRM onbilger_o_Page_167.jp2
33bbedea0362bc4e9b8afec984fadc57
435b1fe305d6dff474764e1314c17e07cc664311
863905 F20110115_AABWQY onbilger_o_Page_152.jp2
59cd72b20c8793b1070bb7f62d4966ad
562d8e2db5de11053b8a5d5503096bf192284b27
F20110115_AABWSB onbilger_o_Page_018.tif
f79f6a05e0b91d2becd9df703e907e68
ed1b68b7740844a2b20f6544a6ea111498a33aed
45911 F20110115_AABWRN onbilger_o_Page_168.jp2
a356d298ce434d509b75c8130780c251
1fa406d150797fd41e09da841633fe7b08267d0b
110192 F20110115_AABWQZ onbilger_o_Page_153.jp2
32a6f43a65e78247985130963cf16dc9
f16b7c254ce94c219c730c83c2cfec119d00cbe9
F20110115_AABWSC onbilger_o_Page_020.tif
dda1c599e1ec20cac9a29d2e016b896d
0ef5e505a75fa5335afd2638ab2a55b6224b432e
F20110115_AABWRO onbilger_o_Page_001.tif
2712293065131f02997982a129243c16
132736a8d436d0c84687333dd8b827046f78480e
F20110115_AABWSD onbilger_o_Page_021.tif
dd941a4e1b669a46f9fd088ef69e9a65
e390f29b342cf60b9946c10d2411c5c9acef4388
F20110115_AABWRP onbilger_o_Page_002.tif
e8f63936afcb2ba8b8b5c87086654385
82134e4f1a106c56dc8d2882425f651f0d367e7b
F20110115_AABWSE onbilger_o_Page_023.tif
c83b17c5e4f99235e34a42a364ffb815
eccd33f93946d06f1c1c9070941c38bccc76f259
F20110115_AABWRQ onbilger_o_Page_005.tif
639ead027b18fb0ae62bb8fd4e6d3e1a
8a8d0211d72931589021644a205ade54ccb0c78a
F20110115_AABWSF onbilger_o_Page_024.tif
a17553eaf4e535a1d16fc74c9fd09f37
117fb3edcd3e02faac11454d3ba2fee37c1cf777
F20110115_AABWRR onbilger_o_Page_006.tif
1e02b7758eca2377d3eb1445a3d97752
2c24f8e9f28dfc1a028eb64502198baaf957b62c
F20110115_AABWSG onbilger_o_Page_025.tif
6a7a0a9ed08e8952c950922d5b5bf76d
1aef3eb7b103619f8d39f706559f69dd22eebb95
F20110115_AABWRS onbilger_o_Page_007.tif
954283a140c840d7fc7d9895f4ac9209
4dc15f87f3256ff344e7a28eff4434261adf9dfd
F20110115_AABWRT onbilger_o_Page_009.tif
4ffd2a7e085e0390863c4114b646e26e
e800320ddbd98f4eccdedb92c032a5584c3501a9
F20110115_AABWSH onbilger_o_Page_026.tif
c1b79a4cf9842a3f2d96892f09265853
5c9904b625f94a743e1a2e3eb8362d7fff390bd7
F20110115_AABWRU onbilger_o_Page_010.tif
5021f7b6eb8336bd4ae9a6d9d0d4b84a
d26317411e0ce4a9f0750652336a6b77c86125a1
F20110115_AABWSI onbilger_o_Page_027.tif
f8da8c8082b80e1731d154c9e92c8930
69a1450683a849fac4b27a2e9a586697d0b23a6c
F20110115_AABWRV onbilger_o_Page_011.tif
d785df33bcfd3e40019fd225b336e8ca
87e137a5a54b7c2b5f4836db54b563cfdd16e544
F20110115_AABWSJ onbilger_o_Page_030.tif
322f6e0911fd5f9d6c9ca8b6cfcb0be9
cd5835d223413aa1300d8c8b456c4a6a67ab4d56
F20110115_AABWRW onbilger_o_Page_012.tif
8827a1ccf9a1c6e7b6787828c11fac18
594e6887f31d5bd72eeb1f064f10d1eb0ad28b55
F20110115_AABWSK onbilger_o_Page_032.tif
80f57b4e39f0836282b2dce26f211bad
1c95154fb5ee9d34ae9bb0721861e40a6a3a2ac0
F20110115_AABWRX onbilger_o_Page_013.tif
ba05f3c581c9ad65a94209e9bed9cf28
004c342eecf580b454bd6d90e1b8899a6cf46f1c
F20110115_AABWTA onbilger_o_Page_050.tif
f81cff3999ece45e424e3c779551bcb1
dcb892909e6e45c27917d01cf12068de3cba17d1
F20110115_AABWSL onbilger_o_Page_033.tif
9a7b3f94903cfe0b0553350ed24e91a8
79b08fa7d49d9721b1368ca93f96952967ed5170
F20110115_AABWRY onbilger_o_Page_015.tif
dc8e2369476d7845d017c9fecc8da749
ffe943c62078d1a2a361967699f587e8eb803455
F20110115_AABWTB onbilger_o_Page_051.tif
bba5e5499d1fd20b39067e7b8a0f502f
b47fcef589d7c5c244d73ba24b6b30bf2c42b6d2
F20110115_AABWSM onbilger_o_Page_034.tif
ac1fcb33499fd02e694583491017f68a
5a7bc771311319d7a15a30c8b834c21fb4ac5409
F20110115_AABWRZ onbilger_o_Page_016.tif
a1f3eeb7022f6ec0b54275d246af69d5
98b5d16fe5f452a86d587075674a6dde2a4726b8
F20110115_AABWTC onbilger_o_Page_054.tif
d3c1f98435db2404eecfab8e8f303f42
c57fd3b82b05184cfae60df284396f116e57c180
F20110115_AABWSN onbilger_o_Page_036.tif
1112c95c5caa4da45e483081db5f95ff
a0fcde745e3ee4fe3c10ad4cac797a56ae90693f
F20110115_AABWTD onbilger_o_Page_055.tif
2a0ade0b334bd1e7486e17729ef35f11
35e1f3c55ae840b872ce970b79c44cb8277f5ada
F20110115_AABWSO onbilger_o_Page_037.tif
2122f85202e29c57babe69b5427000e9
41fb4f305211c8e6ba7e297e6411d8edd7cc69bd
F20110115_AABWTE onbilger_o_Page_057.tif
6d466550dacd0c9ad2c507a5bddaca6c
85d243ecf3c50434570123b8b15eda51b3ae41dd
F20110115_AABWSP onbilger_o_Page_038.tif
f17981efcbb96df3dec7eacead6f5ebf
f719749cc9d07510ff71e80ae6562d169612e837
F20110115_AABWTF onbilger_o_Page_058.tif
caea4b0dbdb9288f2fc3dbf6d7118b4d
00a941da5243da0b264eee5e1ccc3de2eb9aab12
F20110115_AABWSQ onbilger_o_Page_039.tif
601942174292c473954bfcc7ac3211a6
ff7e783b275396725490430155dfeb5cdcdc54c9
F20110115_AABWTG onbilger_o_Page_059.tif
bb79723c3ab3f41711a2afa522fdec44
17ada3475314fb57064affa35da9ad913361bbb1
F20110115_AABWSR onbilger_o_Page_040.tif
baa53ac00f52d2ae512ac16bcfcb8487
741fa4e9ea500fbe1260d61e2fbeb41940ce2522
F20110115_AABWTH onbilger_o_Page_060.tif
d991f231919f8feb22c906b1e2f842d6
b167bf4c3c4fe2ede57c4034a39e34c369e3c3ec
F20110115_AABWSS onbilger_o_Page_041.tif
1bd795a422e454f10b8e0b29f0ed1f75
c66c40dc5d84ba3dc5cbacd766d65563088ec09f
F20110115_AABWST onbilger_o_Page_042.tif
cd8246ffb862191fea7fdb9926e44fd7
4952b7805f30229b1244ff86c0685547405107fd
F20110115_AABWTI onbilger_o_Page_061.tif
2ffbc4dcdaa2d14da829c4a9c59415cb
016267a753ded4c731560c2e7c41bbb8b27df195
F20110115_AABWSU onbilger_o_Page_043.tif
2c23a42503d52780c27396ddada68d53
ac23bb689802a092d16b27fda7d92c113bce0076
F20110115_AABWTJ onbilger_o_Page_062.tif
c01407fae8e004eea1a858210537736c
9b29013b74874e39eb3f23c24d6914f8605c9f83
F20110115_AABWSV onbilger_o_Page_044.tif
a793e0efd8cbad74076767c8d1cca45d
f73fda4e3e299e1c535fca03156f10af1eb9e221
F20110115_AABWTK onbilger_o_Page_063.tif
2ecd0824361a1a57f9625300b18308a7
1e22776f161b04ba9b1af952ce7157d617b8cab4
F20110115_AABWSW onbilger_o_Page_045.tif
3c8995b6371be1c9737db4178e203f09
e03b65c9a97dffeca2c4c3d7f1123b4c6a89df71
F20110115_AABWUA onbilger_o_Page_084.tif
1c292d22074959545997377d776df52a
f3701778c1af7f5803a25f1b0be0a5f2c523c675
F20110115_AABWTL onbilger_o_Page_065.tif
4f81c302c136f0997486e9e998a16eb9
6b78a844c777475c3fbfbe77e5551193249c299a
F20110115_AABWSX onbilger_o_Page_047.tif
197916c92d32fb63b26492adbb7cadcc
1629dc4fb06ccb19756820b75fe74c5e5ca4e25b
F20110115_AABWUB onbilger_o_Page_085.tif
72dc1b7582d653d3ec449ba8ef5a9e8b
490e44cb72e53af3781eba86863b93b51866525a
F20110115_AABWTM onbilger_o_Page_066.tif
26b6698e89e058a58b55aca01a9cae41
7e3b1cdb39441197f6e3ace85ab35981dcc270c5
F20110115_AABWSY onbilger_o_Page_048.tif
95d2e0db6992cf738ec75b933f3fd76d
433fec2fb0f0e9c0dd113120acdb2eee23689c9f
F20110115_AABWUC onbilger_o_Page_086.tif
aaceaadbb2a0f6f5f64272213b3f37f4
9e95c2f94137ef4fe3ef2136bc79fccaf4344830
F20110115_AABWTN onbilger_o_Page_067.tif
693540deeb68e78d6fd18789dca9075a
c47c0722b114619030c8bd8f4c0272a77935a01c
F20110115_AABWSZ onbilger_o_Page_049.tif
b8f501a856b04ee00b698ddae79e603d
1b6f35144d8badcc7fd08e8dd79d8836a0c57cec
F20110115_AABWUD onbilger_o_Page_088.tif
6aa1362c083fba319bdc942691119dae
7c22a7843383d460ce14dc3ecd1a04df540c2759
F20110115_AABWTO onbilger_o_Page_069.tif
1ba248f3d16d7d47a1dfadffa2e67267
d57a05dfffb106a014d1bb56e04e1983a857df91
F20110115_AABWUE onbilger_o_Page_089.tif
aee8c9f640d1516eabca701389e56d67
f23175201bed52dca0422cb3c405896893c91b40
F20110115_AABWTP onbilger_o_Page_071.tif
9491f64e6e89663647c29dd8ece0f5d4
c5c98f3ce90e9de12c64ae0c4ec2c4e3c5f0ff48
F20110115_AABWUF onbilger_o_Page_090.tif
ed38f5eafdd33c862102fbc77d925771
d800cd3a5bc8da4a0ee5f369b483c7b44191a973
F20110115_AABWTQ onbilger_o_Page_072.tif
b7c568a722d03b72ad23042da2b7f963
1dd71df56317173d01c9899656a7b66c23de08b4
50730 F20110115_AABXAA onbilger_o_Page_132.pro
057551eb9cea94dcb8ea29beb74dba09
58a20fd84d6fc1e1b910878afa9d3c0d838c0255
F20110115_AABWUG onbilger_o_Page_092.tif
3f6881542da6ef6e471c0ba52a72efa4
90604c32ce0090b7a63160df9e7cce39d045426d
F20110115_AABWTR onbilger_o_Page_073.tif
9e9a2349a410386c80b22d310bd0db8f
211180a7bd0066bd2669d64250d753a3bb42ce02
47038 F20110115_AABXAB onbilger_o_Page_133.pro
95634bc9de390d707bc24f0d19097d7d
e67e0a500fc6d67966228661714a799b57c2a380
F20110115_AABWTS onbilger_o_Page_074.tif
14051cd97e8f4335ae7514f941251f66
755e6897ad7324b511e0678a3cb9fa7155d77bb4
F20110115_AABWUH onbilger_o_Page_093.tif
ea3a9c1268e6cd0fb9b68e141201db24
577e1208861f86a7c9719cbc0c4862247d6ec469
44360 F20110115_AABXAC onbilger_o_Page_134.pro
0e1b1a657a62eb05b21708df8edea54f
6b9bf7bc8a32bfd6df41697de4595867c12c36a9
F20110115_AABWTT onbilger_o_Page_075.tif
debfac7e11d6a9d7805b96b403b037e3
abe74d273c8c64327446ab75dbef64a3913e4fed
F20110115_AABWUI onbilger_o_Page_094.tif
9e50245d608245c6cd20c7b9e18c06b6
c3e45f07fa263e5a9d450a04ae6ea63f3c78c28e
43552 F20110115_AABXAD onbilger_o_Page_135.pro
06cf4c1d8b334c5579762c6c4376a579
cfa914e6989125f6e285010f41a6e946b34f953f
F20110115_AABWTU onbilger_o_Page_076.tif
ac2a9032987208c8329855915bb9790d
67a9c52748975871e41ff0b7b6b485587f46746d
47369 F20110115_AABXAE onbilger_o_Page_136.pro
ddebf7092bc0c01f8f601b132c2e67c5
fd103e64e0c7373d42b7e7f5703ba64fbd048adf
F20110115_AABWTV onbilger_o_Page_077.tif
2f8878e73f3c6ae7e64353a0a6423517
045367218ec6631c00ba58885367bfc1ddc7cd2d
F20110115_AABWUJ onbilger_o_Page_095.tif
d9400ee041ebf7f536e701e8c4e85a10
ef3da23904e2549995b842db21c6fcd659c1102b
46394 F20110115_AABXAF onbilger_o_Page_137.pro
8738a283e1967fc4304d8af218369ef0
31424c5fc1a280ac7079005e1f584fd009e93fa5
F20110115_AABWTW onbilger_o_Page_078.tif
d57aa3a98f155d8262195d449974f5f6
1961fbbfcc0601251813afcc1ff69619678d10b0
F20110115_AABWUK onbilger_o_Page_096.tif
81278ef9bbd348377b5282c1070bff32
5f4af8b57169be04ea72d8aa87c899f49854ae0e
52148 F20110115_AABXAG onbilger_o_Page_138.pro
c373622c62be4d4625595acfe773cdad
a7ca65d8ccf9998ed78e40c3098ab8cf59dc05c0
F20110115_AABWTX onbilger_o_Page_079.tif
48c1e18696fc5af2976fa2ca1c30d66c
716d505dc6ce6b6e82acb5db8b9eff7f30d14848
F20110115_AABWVA onbilger_o_Page_126.tif
98e54684a88c21f3c3ea1e10d7ab7e15
559f23e6cc2c2cd77a04063a903f98457e50d61e
F20110115_AABWUL onbilger_o_Page_098.tif
890d671c910043a4eac63f7550a067fa
2aa1a169e6ba1017ee12cfe7eae0de17b5c9fc1a
33827 F20110115_AABXAH onbilger_o_Page_139.pro
cfe9ec39de62aeb207d4e7bb42edea01
cd39af6702b731c18839e6d1f71df1b5e0b00c33
F20110115_AABWTY onbilger_o_Page_080.tif
7e1ed5826152e48613473aed061e0522
acc0dd892b605c567816be222b82ad6eac24602a
F20110115_AABWVB onbilger_o_Page_127.tif
9b1bc34197eca326e312b539c20d590f
ec9a5da495bae063e429be215a69cf1f0bf5fa0b
F20110115_AABWUM onbilger_o_Page_099.tif
3554269487e0d91eb8e53599c8426a5f
01665a76ca4135ac234defb2b8d2e51f5cdbaf33
29396 F20110115_AABXAI onbilger_o_Page_140.pro
92888aa24ebde6ef01ffb4e8f8952655
80f73dc903721ea4c4e8955fa4d89959c638399b
F20110115_AABWTZ onbilger_o_Page_083.tif
868cdf65e98c8f086a75a14a0fe047f1
97417779f6116c557ffc42665b9ce432f47b0200
F20110115_AABWVC onbilger_o_Page_128.tif
fc3d0242e5537c112fe10d993acd723b
69d8245b77dd86f92a6cea58ab9b159a31de239e
F20110115_AABWUN onbilger_o_Page_106.tif
c9f38957ee789b1c795d6c18f379f5a2
58026c6948b205b34b372de045d3902203ac25fc
F20110115_AABXAJ onbilger_o_Page_141.pro
a1272d02d08be178cb46e8924b514000
0b2efe183e9b7cd2e1aa27c9a584296d5efb0988
F20110115_AABWVD onbilger_o_Page_129.tif
acc861900b03b1bf11be23f902e9fa70
c52fa79ddbc99045db0736741163f062066c452f
F20110115_AABWUO onbilger_o_Page_109.tif
c4616f52d7b00e931e766e010601c4d7
b97bbe87b425b10b836eb60d45d8866f48c4785e
21279 F20110115_AABXAK onbilger_o_Page_142.pro
92aa863960640943f1bc650a180c08ac
08c928afe99ca8d524aa602fffe99af4f6ec294c
F20110115_AABWVE onbilger_o_Page_130.tif
16aed0cc48fb5c8de1685649b2989b99
cac6ab9e875bdcf2eb7e43eeb7455ebd435fe476
F20110115_AABWUP onbilger_o_Page_110.tif
7b4de15855d867f5a669c39f060ba771
defda0eb1d4b43a643531d80a498fbdb0f1f0775
46521 F20110115_AABXAL onbilger_o_Page_144.pro
5d48201a7a437b2c3c192bd994dc12fe
dcbf9e8086ca6126b86572564b075cb2b7a0ecdc
F20110115_AABWVF onbilger_o_Page_131.tif
c2b81011f546638d04b99f60785e0f58
bbacd9a61d6f685b660c47e43d56c5fb28efc75b
F20110115_AABWUQ onbilger_o_Page_111.tif
f29205545f33ce364a01aff88536dcdb
fc84c70a271779ac73bc2f409e443f125da822cc
64761 F20110115_AABXBA onbilger_o_Page_162.pro
47fd3a04bc770bb2f1d8d2900f74a908
1a21e89e3c811544125d9d11acff8de5696fd9e1
51043 F20110115_AABXAM onbilger_o_Page_145.pro
eab06f44c7bc650e6928fd6aa41951f0
d6ad02319220b54f608ae846e1126ac1a795f72b
F20110115_AABWVG onbilger_o_Page_134.tif
e5905538e40923a58c653416f678cdf4
526b132b787b12fff979becc6db9b82805c5e803
F20110115_AABWUR onbilger_o_Page_112.tif
9c20fe39d4e37c281a3cc0a54f2006b8
a828401c8bbbab044438697afa93fb5e6bba0f02
61882 F20110115_AABXBB onbilger_o_Page_163.pro
44f1b3399be0c8697fb808462da5956b
6d3939f4ac791a79e16232c2fd24a85c640c01ba
38505 F20110115_AABXAN onbilger_o_Page_146.pro
a45a2546cd73a37ac5d2e957e45f6446
bfffc53ba99e52ca1a0f6830c6205d8b377debc2
F20110115_AABWVH onbilger_o_Page_136.tif
3b0fef2a8a5b1a96fca213bf2ed26c26
cc35f41d1efcbce3a2b69e82699121ee9ff0624a
F20110115_AABWUS onbilger_o_Page_113.tif
59345057ad65f2f0fd8da8e193f38b98
90be597074925441bca80c1867936631616881b0
61949 F20110115_AABXBC onbilger_o_Page_165.pro
5b0877797f6ba80c97e6df22ec3e2c91
b4c29d193d11abad129ced4b476fc33aec540b1f
44776 F20110115_AABXAO onbilger_o_Page_147.pro
4437ba0f8c177d582e197e5813dad606
58e594b06ee50c319f407a41e13fb54e50d6c9eb
F20110115_AABWVI onbilger_o_Page_137.tif
85bc4c794853ea7dc318b2b5b896a87a
13f73bbc37a7509ab73762ba62c53ac300b59267
F20110115_AABWUT onbilger_o_Page_115.tif
6683da1a412b56c28e627a0189c46c19
732fca4931b06ac4f509a5bca592a5db4a309e84
63391 F20110115_AABXBD onbilger_o_Page_166.pro
85eb7f45b04fab01caddb8dfeb1948cd
13c58e740edd38e9f049ad69bfece35cf7da315f
41663 F20110115_AABXAP onbilger_o_Page_148.pro
224cb226a3448b46a17521fa4d295b1c
9ec1c559546488d11fc6029f227507faa2c13a7f
F20110115_AABWVJ onbilger_o_Page_139.tif
c75732cf252abeaddf47005b7559aa66
0daf2073f78d9e414b5c78519dc17009e72bdb00
F20110115_AABWUU onbilger_o_Page_117.tif
d7fa5f27dc6d53723a0b7a5735323ab4
73206e407eef491c0de14d1e31316a3b34f0d1e8
410 F20110115_AABXBE onbilger_o_Page_001.txt
4e0afdcfcac47b2a77ef07b1119f459a
d2808af445fe004da8bff7c101fd671843302e84
40994 F20110115_AABXAQ onbilger_o_Page_149.pro
6ad77948875f42318529211f5607081f
ac4055f2e4e3b25ea30cf159e60cf5aedab15428
F20110115_AABWUV onbilger_o_Page_120.tif
44069dd184ba12bc366413e9da72ad4e
389a31c078acebd9424bb63809b85231ab97fde2
116 F20110115_AABXBF onbilger_o_Page_002.txt
1894c4cd8eedb8058b42a37fea42b4bd
3635e12a8849022e6942d00a6c27a56ffc193fe1
39432 F20110115_AABXAR onbilger_o_Page_150.pro
cfe2007467afb561d8b2d6eb4ffd8dd8
5382d1611c0412b9304788c535cbc71e1f3c870d
F20110115_AABWVK onbilger_o_Page_141.tif
102f1d313823d64035c035f31cba432e
fbe5578fce1500449ab88ee28ee8f07306883b7c
F20110115_AABWUW onbilger_o_Page_121.tif
23077f2a4046a75426a728ec8aeda298
ca5bfd458dca2688a77b5785b8d70b05b383a98a
89 F20110115_AABXBG onbilger_o_Page_003.txt
a0453c7e3090fb562099e349b6837ab5
c4a67cc62f10bbef05514879a275303844d5ff7b
36897 F20110115_AABXAS onbilger_o_Page_152.pro
f8f38533823c02094692afc10c92b889
414be4c793dca156dd9bfbc13cd0bb45f2a09149
F20110115_AABWWA onbilger_o_Page_159.tif
4ab4347840405caffa41a32eccad2193
5cd1335560a54a76798985d0fb080b7123b766ec
F20110115_AABWVL onbilger_o_Page_142.tif
ac14046f9da6605cbdbc49edd6703358
3747fd4f013255f71cc4988103f46e3dc18d0df8
F20110115_AABWUX onbilger_o_Page_122.tif
1ec727fac38a6562cbdaa63e0cf7027c
17d552d45b816c2a5b9a10fa0cfcb92bc13d3f1d
1324 F20110115_AABXBH onbilger_o_Page_004.txt
7b2a4daeb13509f3b97dbc57c5dbe297
3b485534dd466c0d9e1f2b904e775745800e089d
51250 F20110115_AABXAT onbilger_o_Page_153.pro
9e3e95afdd9b46635c205143919bad02
426de10e90f5c0a2c06704ed46599bb690e0c0ce
F20110115_AABWWB onbilger_o_Page_160.tif
fa3dc927a9d92fbafaf4895128759946
85fca9d09ed2384141edf7e511d2085c894d2257
F20110115_AABWVM onbilger_o_Page_143.tif
cc8d8f646583bb615eaa71461ea69795
1b86deb4626842762be0e46f31d6f6e728e84112
F20110115_AABWUY onbilger_o_Page_123.tif
550afe56961d91bc62a42cb62e59894c
2d71be07846e84a4c34e1d93f4f401673e0e1e5b
3147 F20110115_AABXBI onbilger_o_Page_005.txt
6f7fa16ee641ff0d90a152f3171fb507
0b2e3da0ffef465f2231f4e571916513abc6729e
F20110115_AABWWC onbilger_o_Page_161.tif
882591cb536813a94dcf56645d261d1f
3330a9c52c7f14b517cb6b14db73cf142bc72417
F20110115_AABWVN onbilger_o_Page_144.tif
c2fc2cfa94e1379bd3c80a8480fa0a54
8f6cac34376f0580df995a0b5738b5cb94f2c49b
F20110115_AABWUZ onbilger_o_Page_125.tif
7429518974713575522a06a9d9f2f30d
fbc63d047f4feae8806f6be101572070283c72b2
2228 F20110115_AABXBJ onbilger_o_Page_007.txt
174068f9d0488431d2749433e4c87e1d
4d6779672698436a864e4b90abb867392c2b97b5
49923 F20110115_AABXAU onbilger_o_Page_154.pro
97f13b7583c168fd93a30d58e6adbc7f
97ee0646367a7f6b65a3bcb60dbe5f106f219e25
F20110115_AABWWD onbilger_o_Page_162.tif
f0d6369599779b84aa02187c7dc8cf9e
c02cbeec6e2bb3ef9d2cef5a5fb4332e0eb78c4a
F20110115_AABWVO onbilger_o_Page_145.tif
4e568d2daf767243341c5e27551c0d98
d8c25fd6c83fe9e655cf810480b05cf80d8dd605
849 F20110115_AABXBK onbilger_o_Page_010.txt
08e9b20d7f18a06ef4b47764b2ea490c
b55d7475a8cac99fc5d1d78d6fb6368c1e3bb974
57606 F20110115_AABXAV onbilger_o_Page_156.pro
3fa4292a91c6baf511b0f661fd23779b
e8a50b27bb398141cf37c0171496f21f324f5a89
F20110115_AABWWE onbilger_o_Page_163.tif
f2f4438979f26306a9b842f0fd02615b
d49fccca5bf310339746c50a24da9e5e78aafe2e
F20110115_AABWVP onbilger_o_Page_146.tif
7e48c3953c11ce1be556ac93db7b0424
77fc3e714344f21d05562d4268b06f52a69433b3
1555 F20110115_AABXBL onbilger_o_Page_011.txt
39ccdf8a8c7802fb365f3910be10c4ef
51a000c224b4bf16dce9526aaf9d030f98d75961
67558 F20110115_AABXAW onbilger_o_Page_157.pro
115fabf7ded59a8d13f18ffda66cf402
c9e6b89122750d14cbc8c28657a50175ebb82425
7486 F20110115_AABWWF onbilger_o_Page_001.pro
e4a98e9a53764e2ce3552457b1b03e19
5e18bdb4cff5eac005627b1c57b36fed8c563379
F20110115_AABWVQ onbilger_o_Page_148.tif
b3556d3c12f34a9b5ac347c20c98cb6e
2ff91f32356c7721f513016892d20a8788a4cd31
1993 F20110115_AABXCA onbilger_o_Page_031.txt
5d7dfb483b082de6538afb8da0c248ed
e8db4f84af51213b54268e212ff1d5eb831e44ac
2021 F20110115_AABXBM onbilger_o_Page_014.txt
e02232bb93e089370773d577cda9436f
051dcf709be1d592d618c1743facdcf492bbb129
7293 F20110115_AABXAX onbilger_o_Page_158.pro
cddbd6516803cf5e9dde49f43653733d
d13997ecbda1ab298f83adb4c9cd38747fccbfe9
1255 F20110115_AABWWG onbilger_o_Page_002.pro
7a8629959f79e17ba7665a1ff2444dbb
e864ad2f9d0c8642fe973c5cd73c9acea02a0255
F20110115_AABWVR onbilger_o_Page_149.tif
697a58d93e49bcef947a14d5bb87874e
d71946a3242915b807647c4fa5e877089a644500
1834 F20110115_AABXCB onbilger_o_Page_032.txt
80b558817b897f68fd5f8a061e7b4841
39c5df27b04488b4bf3b0ec8e900dc559c6522bf
2010 F20110115_AABXBN onbilger_o_Page_016.txt
b3978fa24b4b5e5f04fa5d9d0b11fce8
96dc05b24ace87a31d97e1c61d725d9d7bd1bc9d
65164 F20110115_AABXAY onbilger_o_Page_160.pro
20bb1c38015a97ca04d0c82104981304
8798caff6b557320aab8f56e07dac14cea114a17
902 F20110115_AABWWH onbilger_o_Page_003.pro
de31ddad64e7fdd8b1b6b53b9a9d81a6
6b0cc5c6da1d31b0dda9c172928f70e6d5378246
F20110115_AABWVS onbilger_o_Page_150.tif
db6406d4aea3c95bc25c2b02b8c67487
fd43ad9b4b8dfa0e8804a8dfa0b1a4c8411fee06
1856 F20110115_AABXCC onbilger_o_Page_033.txt
268a75d7c0dc0f14f3013bcddf916662
4c115aab025fed3e9504b8218112966e34773c7b
1884 F20110115_AABXBO onbilger_o_Page_017.txt
bd8cf1c03160a6a91d68d9e79b909c92
20bc855361666eae3bb82c12d818c19ff8530a8c
62461 F20110115_AABXAZ onbilger_o_Page_161.pro
694ca9691fb971a45a75c738771e05ca
ec693c0cadaaad258f2f7a6e1f70db38162eecaf
31803 F20110115_AABWWI onbilger_o_Page_004.pro
ebf9fa98d1fde2969a5d9141bafe9ba0
fbe3b17688ebf9ea200f4467d5e6863bdddca7d4
F20110115_AABWVT onbilger_o_Page_151.tif
4042463d8b1b1c17307626150b2fc055
ac50329ff527e018cb92aad857710b26a73ca1b1
F20110115_AABXCD onbilger_o_Page_034.txt
3b3760dd976a84b77b05e3f240cb595a
d655520d5fef11f62a9795acf0db3acc2478a2d4
1408 F20110115_AABXBP onbilger_o_Page_018.txt
e11ed27081e459247c3cec54886cbd40
1726c5813d911b6ba340610a15ddf092d696bb39
107944 F20110115_AABWWJ onbilger_o_Page_006.pro
7abcddbbf5e7452f20425fa3543d623a
d39812c6d9f610f02b1851d583c60227e3400b10
F20110115_AABWVU onbilger_o_Page_152.tif
4d62af6897ff0fe25b6a8b02d51ad649
4f72eb3029b70c31c60396c866e7a7ce8b7664f4
2029 F20110115_AABXCE onbilger_o_Page_035.txt
eceaa00425da23265063999cda3cb356
2e89e423ac90478c718cba723a8b3d16805c9ccf
2132 F20110115_AABXBQ onbilger_o_Page_020.txt
0a93ea93fbc0a96baeed7a8bbd56ab8d
50dcd941b2d37b543ae1ad94c5a783d3207c4a34
54089 F20110115_AABWWK onbilger_o_Page_007.pro
5ca6b2eff74a2997b335eca7938a023c
1f1a58a8691f561d05f34f076bb271f8206682c3
F20110115_AABWVV onbilger_o_Page_154.tif
f68b4787a91d311d50de60b9dcae8174
f58cfc594dd9eaef935c6d6630d38608c174b44b
2009 F20110115_AABXCF onbilger_o_Page_036.txt
a779a02c71948085744d5399a2482fcc
37a270f1f843d58c7a0a1beb8e6d32132a321568
1909 F20110115_AABXBR onbilger_o_Page_021.txt
0e3c50b564b755fe1b463fcd09b5ad1f
9250a6a0ebce0c07ab04e9e2b9e35a9bc07975c4
F20110115_AABWVW onbilger_o_Page_155.tif
6190d7a3bcefc75bee350c02acf8b267
923e8ea5161ce6031b472c2b8467a0f59c1c3a3c
2005 F20110115_AABXCG onbilger_o_Page_037.txt
984156cfcdc0f603f69d41608f576a01
25e91ef5ee331b67e665224962a437ab8efaaf60
1951 F20110115_AABXBS onbilger_o_Page_022.txt
5e0d05d76ff6b8b47e8aea788a9256a5
461eb906f5eb4fcd76a7e8e91ab30d65e58d5ca4
16361 F20110115_AABWWL onbilger_o_Page_008.pro
39fbbafce248e0a1301dc8d2bf52c322
17223a7de4383d62b82c0e1a78b735e1ebf3220e
F20110115_AABWVX onbilger_o_Page_156.tif
943a985f2d9246aff1ec698706f706df
e476ab4f8101dc2f82d36e3893963581c3d5c594
49637 F20110115_AABWXA onbilger_o_Page_027.pro
113c9a53f1ad09e9d7e8a7c1fc9d5e1a
9da5a22876c904ddf05b6d01726bd4a2b9cc8c81
1969 F20110115_AABXCH onbilger_o_Page_040.txt
408b5a9aa4f48d3ea16368363c0a0328
1c94879175df790e71970cc0e4b76adfaa9d1f25
1984 F20110115_AABXBT onbilger_o_Page_023.txt
163c6f13835ba67044f7797d97cd29f4
22b954908479b54a445c3f7fc2d3ddd00c532958
61016 F20110115_AABWWM onbilger_o_Page_009.pro
449c873e8f34934875172a30949b336c
0053cce0c134b05b7228d6d30b89fe3be7e061c1
F20110115_AABWVY onbilger_o_Page_157.tif
8b7c7b6bd83426a870345935c6aa490f
d197921322dfbfc0b2f2f99799e9a6393a942d43
29659 F20110115_AABWXB onbilger_o_Page_028.pro
6b08c3062dbcdd39bd62bf9238c7f23f
6cd757db62d4fb7438f6d70f86ff908ad49fb27c
1743 F20110115_AABXCI onbilger_o_Page_041.txt
4c0e60735bb190ddfaa1ade6db36d563
e038dcc5099ef400a8a676523e3669111dbd220e
1886 F20110115_AABXBU onbilger_o_Page_025.txt
e1a8dc194d6599d0bb99f8c9cc627142
a38fca38350943e91bb792c456daddd0d3e94f9a
33546 F20110115_AABWWN onbilger_o_Page_012.pro
1be84112d4cc18bdd308befd7801167c
b0694442debea94296d13aae19a72f7e7ebe0921
F20110115_AABWVZ onbilger_o_Page_158.tif
f0993c87b6dadc7799c258eb9a9a3958
902190c2275eb45396283a1e1ad59eaf6b935b69
47614 F20110115_AABWXC onbilger_o_Page_029.pro
15a592d1a9da581b589e85cf94b98608
ca0173c4302e8bc9ee8f6c893b2a17b07ad39f69
2003 F20110115_AABXCJ onbilger_o_Page_042.txt
2dedbad5a3e3730c2eed379d4209a16e
9b405779aa63ec7d0dbc1945ffcd2bc036120deb
44887 F20110115_AABWWO onbilger_o_Page_013.pro
43e55d5c481f0af87db404612dd2e9de
6eefd41ec0cf0bca1e6d719782c3e0f6779ba849
48659 F20110115_AABWXD onbilger_o_Page_030.pro
ddd146bc0ab1d6338ce1a23206039b9d
2edcfb2ab0cb5ac1316ca94fcd3cccffdf69d3cc
1896 F20110115_AABXCK onbilger_o_Page_044.txt
279e21ab7eee79079b80e3cb80d8b638
3066bc460d1b335d225fed6fbe0ae8bb753d0f4e
1865 F20110115_AABXBV onbilger_o_Page_026.txt
51875a11d01b42159156b2dcc25e9c54
83cdc1b7a1fdac641564f14f6e4cbaa2eb93291e
51228 F20110115_AABWWP onbilger_o_Page_014.pro
e21ef0fff0232fd2e3109803d640107a
77d75d196b464ac07be591fa9e98e547f27ce091
50725 F20110115_AABWXE onbilger_o_Page_031.pro
1996d87c39a6d5861fff24d4cb6b12cd
afcc20089a8446c77b7eef3f3917dc8afd13db1e
1980 F20110115_AABXCL onbilger_o_Page_045.txt
f778590498a98f9aecc085dff79c85f3
3d205810bd68ccd76ef083c39bacbda955a3949a
1955 F20110115_AABXBW onbilger_o_Page_027.txt
fc47e5485ecc73ac5c63e4075b42fbf2
e92464fd71609b8abd7634b98fcf68d07107ddae
48848 F20110115_AABWWQ onbilger_o_Page_015.pro
a4bfa32e1f136d59fe67b1a05286e11a
a2f8f1713bdea7e83efc30fddd569c8dd927fc97
50872 F20110115_AABWXF onbilger_o_Page_037.pro
b207c212c3fb44e48a4ce6861a75479d
467c47280b246fb6aedc5c957b1ae38819b1b045
1988 F20110115_AABXDA onbilger_o_Page_068.txt
553520e61e5664d6ec5bac77b2b66f50
94b2bc189ee9298437a6fa2d079b401354ff00ec
F20110115_AABXCM onbilger_o_Page_047.txt
9e54a39c6c23f5dbb7589b7bcd8939da
b447da9f88b46fab2e3c698bb1a11e3dabd5cabe
1465 F20110115_AABXBX onbilger_o_Page_028.txt
f158e77bb4b023b515fe0acd1f6e97eb
31286b15b2fde4b9d99172a29c16175fd979e678
50261 F20110115_AABWWR onbilger_o_Page_016.pro
3a461a549e24c83818baf2cee67276a2
0b2bdbeaacb3069fcb52509743a9c2f096de73bf
54931 F20110115_AABWXG onbilger_o_Page_039.pro
57cbd8280eb96caf1e263d76addbd009
354b356d7bea5bf402e7e34c553bdfd772198494
2104 F20110115_AABXDB onbilger_o_Page_069.txt
5d97a00190ef651665d3dc7ded5bc147
766c16c745df1b6335ac7187478256027eadaa06
2035 F20110115_AABXCN onbilger_o_Page_048.txt
ae1e3eb79abfd93541ee376ce0bc6f90
e18ee0ada09778093b1634d846f6493315508fa0
1882 F20110115_AABXBY onbilger_o_Page_029.txt
8cfd130b709b98633940b10c490f3e44
e72795bfbd6d6bd6427f9a69b67bccbb5b210e54
47276 F20110115_AABWWS onbilger_o_Page_017.pro
6579506532cc8aff0e6a9fa147a2109e
d6a875994f098082b52440c6459f0234fb2814a9
50078 F20110115_AABWXH onbilger_o_Page_040.pro
dc3f31f69be89e412e7276926df7bfe9
2bc01e86d1a3f7437df0ef4772278da135e707de
2079 F20110115_AABXDC onbilger_o_Page_071.txt
b77a6eeaeb4672eca96aa91d01149c21
44a87413ef38330028f97f7ca7dca2737ec7a162
2100 F20110115_AABXCO onbilger_o_Page_049.txt
bd612658a0f8ec9b7a5027a6bf1a5490
05df34d72abb5a8ac01e11a9b7ca8bbe214c08bf
1922 F20110115_AABXBZ onbilger_o_Page_030.txt
8cfb39e01eca24172b5191d38ba8eade
fb7a8d6438081606e363ea9faf8110c55493a4e0
34980 F20110115_AABWWT onbilger_o_Page_018.pro
e2bfbefefa28eb35993ddee7deedb211
f2e13a19c2aa1559bc911cf5d17f3c9cdc48b5e3
198494 F20110115_AABWAA onbilger_o_Page_145.jpg
9eedbc78e0d8801c13783d4b3d98221d
e6f57c3d91079ba9bc792323241655ecb35a6f8d
43415 F20110115_AABWXI onbilger_o_Page_041.pro
80d425d675dcaf25543f5be4ce8f0c19
83cb9e22c0ac3bd2e08ee4b83b9f30d59ac9b73a
1895 F20110115_AABXDD onbilger_o_Page_072.txt
b5b99dccd41d02a7f2648d7ecff1a305
cf3b750320d1120e27d0eb16e801b647a6752cec
F20110115_AABXCP onbilger_o_Page_050.txt
e8932b0dbcea837475bea88bea7cd11c
4cca18caf53650addd74b7d88b2e8f86920ff795
42015 F20110115_AABWWU onbilger_o_Page_019.pro
e681c4f1a5fbc9fc97e6adeb024cb6e8
ef8bac8e154153e4b7b0f4350dfe5689cbc569fb
980322 F20110115_AABWAB onbilger_o_Page_148.jp2
fadbfe3eb676f01279c3b92c43962cf1
a7cb83c7ba0dd468299cc360e73d42d14490fdd4
49577 F20110115_AABWXJ onbilger_o_Page_043.pro
dd3f7d7a8c6e0902dd22a5f228c299c1
bd5d7936adfdfbe49a4d671016f3b6f7bc7a2bfb
1945 F20110115_AABXDE onbilger_o_Page_074.txt
68844e60aa1bf6a55152a993ea784529
534253d351e049cd30b7e43799c5676307c901e7
1947 F20110115_AABXCQ onbilger_o_Page_052.txt
f7c49bcdebd99d19a5ec502a6853ffe2
aae36ac68eec3833ce0cb001adde6e04b95e6344
52458 F20110115_AABWWV onbilger_o_Page_020.pro
72b9cfc04786ed8ff7cab008ad4f4b78
5d5e546e0ab3e9a268649ba3b88171d1a4747443
75270 F20110115_AABWAC onbilger_o_Page_101.QC.jpg
e1264a42293bb999a5ff68365075c580
72c161f0613edaf22bcebde1ae18e4b3fc18b5fc
47857 F20110115_AABWXK onbilger_o_Page_044.pro
33b39804966434570286fa33a2715e6b
5a11bbb843c44faadecef9e6ea4d863e861bd877
1995 F20110115_AABXDF onbilger_o_Page_075.txt
ef0b086e621b087306722b93195b0eb3
44653ea670e00a23d7f6b12468ad0d863159df1d
1870 F20110115_AABXCR onbilger_o_Page_053.txt
9af5dffa8eb2511ff6b2bf499f7d44d8
565b33b5e3498f906ad2dd2b1c8675e13280324c
49372 F20110115_AABWWW onbilger_o_Page_022.pro
5bfef86bc6b29d7ac1ea3cc06aee2a75
47e40ff7bb1927a8105c4f5653284da9d0b44cb0
98621 F20110115_AABWAD onbilger_o_Page_106.jp2
6703dba48e5ba19a43fdfa44c9f78d7c
ff0ef496497e9497ecba9e9c4a1cb85b7b880711
43339 F20110115_AABWXL onbilger_o_Page_046.pro
4dffacc5fbb34ed52ef67202e132988d
213a02528eed14701802c6b405e73e45a33f04db
1723 F20110115_AABXDG onbilger_o_Page_076.txt
6910eb13a76cc378278a54e3344194f9
968014960d9c62fbaeb8daf84ab53955dab988f6
1565 F20110115_AABXCS onbilger_o_Page_054.txt
52865de2aeedc6493d67f476422f9481
759d94498604135e349902bfd8de961d9b0a21f9
35994 F20110115_AABWWX onbilger_o_Page_024.pro
7e3eef8c6447b1f8e472873b0fbfeda7
d60b7c01bb783456ddcc2d3334f535ee03430667
1051976 F20110115_AABWAE onbilger_o_Page_071.jp2
d9f1422c8458736eeb1a5dbc7179e333
2a19f36b04120082752fffe53b466062bc8f61e8
10055 F20110115_AABWYA onbilger_o_Page_065.pro
a33d764747344047038c6d8301758ce2
c8a4fefe1b02f8e9fdb8bf8614d771efbb9668ef
1489 F20110115_AABXDH onbilger_o_Page_077.txt
b21d00c97b9127c526772ced31b00562
497ebbdd6ab319f64eea22394cabb4acb229e1a3
1470 F20110115_AABXCT onbilger_o_Page_055.txt
885f592c7295d53305945d0e541c859d
76795563842e096ede5a8fbb5f6569075eded68b
47698 F20110115_AABWWY onbilger_o_Page_025.pro
5e6ef0d7e574238bbb0649a6fb55c03c
4d0d67f2bbb72f2f380da80b74ab272b8b769ac1
76807 F20110115_AABWAF onbilger_o_Page_015.QC.jpg
59f33bfa0bc1c088ff2cf1ad55675b14
5524ece516278b5afdc0ae52d7b37a95abb9737b
43066 F20110115_AABWYB onbilger_o_Page_066.pro
787fee61141839aec6e3f2308b617417
30953c2d36e6bee7301179a48d66ec112e526e25
51749 F20110115_AABWXM onbilger_o_Page_048.pro
838b4e13f23e8bab791565fe46d2d304
ee309ccc725ee278046528399d00b9c80dbc761c
1612 F20110115_AABXDI onbilger_o_Page_078.txt
27f1b746ee613b8d7581b9231684f2bf
4f0256963a23218d5014803c11e9080e17bac406
1314 F20110115_AABXCU onbilger_o_Page_058.txt
c99d70ee6ca7e89deaf79efa2566782a
ba5398aa04e6f5e7e2fe8fd2b889bb5f5a791cdc
47168 F20110115_AABWWZ onbilger_o_Page_026.pro
52ef124f5120cdaf6597246afbaabe0d
8047163b7557a727fe59c36f65d1e41b86c55d40
72302 F20110115_AABWAG onbilger_o_Page_133.QC.jpg
7eb319ec45bb6e54e748f2aa402bc9cc
bf456e80ab1ea631732f949841775a7cf14fe905
49308 F20110115_AABWYC onbilger_o_Page_067.pro
d5fe445a8f4fdb4a2d0f745a330d5974
85fc6f9fe8565fe810b7a6bc07a0b041e2aae90e
47328 F20110115_AABWXN onbilger_o_Page_050.pro
9e3d93f25b56553430eaf9d37fd50b17
3781e9627bbc7111f726d1c7683b36f6d0599747
1400 F20110115_AABXDJ onbilger_o_Page_079.txt
bf461dec86e1f508fd88444163a4879f
9c99ea838ff4c06a50c47559208e7a6fac8aed08
1937 F20110115_AABXCV onbilger_o_Page_060.txt
c7bf6914f5c0d110e80045dcc3714184
63d1f12c7ed447ad572eaa43276814e9cf0e3303
95495 F20110115_AABWAH onbilger_o_Page_135.jp2
5ac668b37527b5b5d2761823a4bfba7b
3898c88f0cf836d5f551116863da2d37f21683c9
50503 F20110115_AABWYD onbilger_o_Page_068.pro
563172fdcf1d04e39d14986a134015f5
e97d3bb546f7a561b0e0c28b201704e8a815d990
49565 F20110115_AABWXO onbilger_o_Page_051.pro
a8b2ef537188d6d08cbd8b52fb0bc58f
340cf4a547c17339c2e37df40770561ef77dbabf
1663 F20110115_AABXDK onbilger_o_Page_080.txt
5c33d87ef401475c5a7a0e35e02958e3
fdab5ba4ef0d976960d292379f4a3efadb2bac68
1934 F20110115_AABWAI onbilger_o_Page_015.txt
90a5869a48466fc65333fd4693d24923
1c625e02362d51e2d14765e91edda2a8cbaa2db5
52728 F20110115_AABWYE onbilger_o_Page_069.pro
b1c952caa72a5370ca7d6495c5d0a798
3dc9276079524f7ef12041cd0c1680484ab1adbb
48514 F20110115_AABWXP onbilger_o_Page_052.pro
4f5c485cf46dc9d2092247ee11b08449
7f398c632aaab8109901efa17aad49f11c666af6
1729 F20110115_AABXDL onbilger_o_Page_081.txt
f5f8eee5668d30d33fb46708f440eb4c
2318291b7b233042d097c3c5485626c38deddd7b
2008 F20110115_AABXCW onbilger_o_Page_064.txt
e8e05ffe8be1f05b17cfb09cbe6eb831
1c2364aeae34e30ecfc0c5c1125fade1b5acdca0
23501 F20110115_AABWAJ onbilger_o_Page_026thm.jpg
20143d5fd6d40d6317c793ca7ff25e0f
daa7c22abbf97f0f66075c4ef2ee52c784943f85
50713 F20110115_AABWYF onbilger_o_Page_070.pro
86be2c1eef56b77641fc5662a367f279
fd4d4713c4e75bb1a905f55ea7077fd869ee904e
45974 F20110115_AABWXQ onbilger_o_Page_053.pro
f4985e10f6b46ab62fb27c3956795619
3e59584d433477498a24f2b7941d69d97c066e04
1935 F20110115_AABXEA onbilger_o_Page_101.txt
bcfbdcdd939bbf4e3073fd586de83c07
1562962c96629380614af1b7cb003916d1c71dfb
1617 F20110115_AABXDM onbilger_o_Page_082.txt
1cc678e274f840d9a629fc9b8f4da12e
70f8f0df693546d4792c20ed6186a305a6aef64d
448 F20110115_AABXCX onbilger_o_Page_065.txt
19a98767caaf099c7f12020bcf93a970
55756d37ec1abefecf16fa79a49f252ca33d58b4
F20110115_AABWAK onbilger_o_Page_107.tif
43ca19ea1ff5af420512cb6dbf6e0b68
bcae72ffa11d7985c9cc069cf70ee4372ae454d1
53039 F20110115_AABWYG onbilger_o_Page_071.pro
f6f74d46c76ef8c2e9b218712bd255ee
d25f8939e24f9fa7555c3eae76b3cc8b88a75cfc
33216 F20110115_AABWXR onbilger_o_Page_054.pro
cfffd3b15f5bf66644a16df3e4b8d4ad
fc3647b9d48dd3c6caf15d95761eaa3c9d31bc48
F20110115_AABXEB onbilger_o_Page_102.txt
fdb7dcdc941a5ceb8f74b11b36976341
7496598f265433c2d5f53048c8ebd5a98e439a67
2289 F20110115_AABXDN onbilger_o_Page_084.txt
9c8a0c0f0828eeeb1a2d8408d899ff0b
79d9394cf61198a079783aa5cf363bcce56a7c55
1806 F20110115_AABXCY onbilger_o_Page_066.txt
87dcbfe0e0979b9263fbda12bf414164
7220e97725043a6b9b0349acff027d27598cb2d2
99046 F20110115_AABWAL onbilger_o_Page_013.jp2
ee17335bade75d1bbcc11ee635da53c0
d083ac320d4acfe2c61fbb2c34403c02dfa8e78d
49457 F20110115_AABWYH onbilger_o_Page_074.pro
edd48b505b800becf5133eb85de74655
07f43a0b30de483e375b1355eba1b42b7b51a3ab
29272 F20110115_AABWXS onbilger_o_Page_055.pro
285475f870cc823b4e91409abd5b4ca1
0238091a503d8837214a4589eb7d4de38b37ba0f
1885 F20110115_AABXEC onbilger_o_Page_106.txt
397235e6b7d2ffddcca744e05d16bc71
ce852bd32061b233d739694bb479a53d58947904
2215 F20110115_AABXDO onbilger_o_Page_085.txt
b893c80e882c7b8ecf802788dbe262f2
ec46080076cc5730ab56fae6b36e07767abf9a68
F20110115_AABXCZ onbilger_o_Page_067.txt
a7fa3746c769b19f82dde526d72b3d29
fd508540fe7ce41cebe18fa403c5d905060e018b
52581 F20110115_AABWAM onbilger_o_Page_077.QC.jpg
06e399c392e546ea18dbd012fb4a44d5
2ece36b499e95b2f26c36eb0ffc4afd3efdd5692
50200 F20110115_AABWYI onbilger_o_Page_075.pro
0bf8c19d60f06ba0e306179b698c9efd
9525546f985e557fd1fe05c42c64bd6b4e1d65d7
39378 F20110115_AABWXT onbilger_o_Page_056.pro
deee682f8888492bed5f332d1dd72798
0cce4457190c87edde84a449038f4c216ea37c3f
102602 F20110115_AABWBA onbilger_o_Page_033.jp2
01ceef7c8e9427067c09e854704c8b4a
6a97135c2e65f7d3698f96f9be735534dbaa7923
1876 F20110115_AABXED onbilger_o_Page_107.txt
8ff3ff91b619c4cf54d8242e5e66ab1c
b544caf3cec6b3d7bc218a302f25a37a6b110486
1968 F20110115_AABXDP onbilger_o_Page_086.txt
e640dd7f5e46c1e2d959c0c7721fddcd
a6ff3296e4fc67cd987e3bbd57f17123b652afd3
203449 F20110115_AABWAN onbilger_o_Page_121.jpg
06461e560bb23a700dbe156cbc511c57
c7a4e4782b5dc4d7c36cec14a50b89d54210f463
42743 F20110115_AABWYJ onbilger_o_Page_076.pro
71e0dc639c2c1bf4c88e5bef1f5f5057
64e6168662ad0c2ca1e651e2a9aeeed740069f7b
37818 F20110115_AABWXU onbilger_o_Page_057.pro
e55c452c58e201d56d16b51d9e61789d
2b7f2429790ac222fdb0a1df2aa3a49814daac3a
22996 F20110115_AABWBB onbilger_o_Page_089thm.jpg
30b9b70d5ed1b30c8656a0f59ad78e5b
80382aaf7a587bb360246713485726e7c649f0b5
1892 F20110115_AABXEE onbilger_o_Page_110.txt
146e86cb7aa89e9a4016ad4d8907ce41
6954a2167b7a3ac63851c6a2d9b0d4c4c96bc1d8
2025 F20110115_AABXDQ onbilger_o_Page_087.txt
9fc2027a56c1a7cf570d5a137fed2a54
6f8ee396147299558d8ce6d0cf304445a94d019c
2084 F20110115_AABWAO onbilger_o_Page_061.txt
c31eb4d6db0036fb75b5bc6ffbe7a462
deef6502a87cf610371867269bc2d5db197e4369
32419 F20110115_AABWYK onbilger_o_Page_077.pro
dbb326c2982b02551a50264ab687a993
dea01928280424bd3c4bb97dd1fcf2e1580ba43d
45475 F20110115_AABWXV onbilger_o_Page_059.pro
0cfaca80dec0105ea278ba006a1af960
11816bcec0c65ba386511e6b903bb7a01bd27999
2040 F20110115_AABWBC onbilger_o_Page_108.txt
685390da6826bbce269e70c97b2fb0a8
de1f0f48b1a1bc4d131671fac4434aa880f2f864
1898 F20110115_AABXEF onbilger_o_Page_111.txt
ab0c51675cfc5d3a10764bd9ca8386c5
0007ecb4d605dcfdf5b1793793fcc81af3d5c921
1953 F20110115_AABXDR onbilger_o_Page_088.txt
2a690bd7ff5dd4f427cd4cb624824d4b
5c7df988df7e572b670e14c19586262376f0fe6d
1799 F20110115_AABWAP onbilger_o_Page_134.txt
c40980934d28104af35107a445555515
5c47773055b576a3a0c00813f7875e439336acd4
38920 F20110115_AABWYL onbilger_o_Page_078.pro
74a1c325b22fdc81ca7dee65babbfaf5
145d922891ffde0eaa9036fbb45aff4c97bbb905
48246 F20110115_AABWXW onbilger_o_Page_060.pro
611b7266620638b6c8dcdaaa2fab704b
9a56fa1640da82d0e88909314181d56932a3a474
110151 F20110115_AABWBD onbilger_o_Page_124.jp2
b463d3e3865c4e9f5110edca67da43f7
00b26c1620de0bcc759dc71b3bb76fed238fa10b
1188 F20110115_AABXEG onbilger_o_Page_113.txt
585f23b57652dd89a014ae26fb08d25f
d15aec3edff2ae7d7f76ab41730d3af0f6cbaf23
2116 F20110115_AABXDS onbilger_o_Page_090.txt
b9059992338fed180346bd3cb70d4b6a
d38c9b408f399f664325055a06f30db2150dd807
4395 F20110115_AABWAQ onbilger_o_Page_006.txt
17c9ef77e65e805c0e017a806ccdfae4
7910706ea720e2fa36b1048e4ea86aef021fae32
46406 F20110115_AABWZA onbilger_o_Page_097.pro
1ece5d93c252d9d77361dd7ec8e1957e
bf23c24dd822b9fadeef03b6ae0e9c7a288feb4c
27677 F20110115_AABWYM onbilger_o_Page_079.pro
da290ce760790d97e8c62c6a57c29b98
699c1cdbc52d6383a4d8c4803493b9a485e9be73
53017 F20110115_AABWXX onbilger_o_Page_061.pro
ed902cf188bfd5261a85da1da1f8e85a
69fe3478e89547cf569ae43d140da728582437cd
50815 F20110115_AABWBE onbilger_o_Page_042.pro
4d46f281bd91a9d268a9aa14749789ca
4d0354cf9ede4b5dc0c05aeead72ff4cb2923864
1409 F20110115_AABXEH onbilger_o_Page_114.txt
208dc737eeb93043e88acc4eaf36e436
fe419420e6e25626a09e2057ee10e2b2ac2e4e37
2142 F20110115_AABXDT onbilger_o_Page_091.txt
32feac3477a414606fe43051b01087cb
7f59d8426af445b2d166458b1d895269484c5f39
1972 F20110115_AABWAR onbilger_o_Page_167.txt
b9e4b163c869af712f09246ea458fd32
a7ae80fb3720d8b26f113cf44734f2f3ac059676
34868 F20110115_AABWZB onbilger_o_Page_098.pro
a835437be04f8581049ba0c3b9569bfa
271fce816595758d3d56a826ae245b711e1e2d87
45876 F20110115_AABWXY onbilger_o_Page_062.pro
e442ee02946be14cc690f65db5733764
4662b72270f43d9ca01ebeaeec471647088d8bc2
F20110115_AABWBF onbilger_o_Page_118.tif
5fec8cf105d2a92e0cf98e42b00e147d
9a126483f1edd8ecbf39bdf04ec5b76334a5264e
1899 F20110115_AABXEI onbilger_o_Page_116.txt
a9d25ef28f1dadd90cff005498b1f6b9
693aa50abcaffe9dc25b11a1736152dfc69a9d47
1770 F20110115_AABXDU onbilger_o_Page_093.txt
2099c58a9acf140b33a58223af5ebb23
6ddc67f53475964e53349d2039d789fb9ff7965c
50826 F20110115_AABWZC onbilger_o_Page_099.pro
844fee8dbb7fd47f63b8d6ca70cff2a2
f0694a09024709aa87ec2d5ad8bd13eb8e7086dc
37546 F20110115_AABWYN onbilger_o_Page_080.pro
9cf4e38540312c2d2d576c05249b0ba2
462234ef66f609e4a7e401cf4f95146eda533be7
44364 F20110115_AABWXZ onbilger_o_Page_063.pro
cde09de32da148853c887174b04916a5
01c4fdf5ae41c3ccd6b618880e871453e9e076d0
140203 F20110115_AABWBG onbilger_o_Page_004.jpg
c9422c00152266700c11a760bd830757
92d6c0df9ad88d42910f5e477f8d911a88fd918f
2554 F20110115_AABVWA onbilger_o_Page_166.txt
3f251f3c6f316846b52e391fa74ddfd2
3f322f1fe4de68aed1267023621515be43f04d2d
2159 F20110115_AABWAS onbilger_o_Page_039.txt
c89bb0baf686b84bdd1348eb18168953
36c3760fc7167abed85b211b0284179c507a7a6b
202 F20110115_AABXEJ onbilger_o_Page_117.txt
b24442730acfff52daad891a9de84ec7
63fd9aef8da980cfd3261669b5e56588d9cda7f9
2044 F20110115_AABXDV onbilger_o_Page_094.txt
926c73fe9eaf08f8ff0ee430a16c6e21
513be269bc0f94af47c9713c1b89c73414c1205a
40307 F20110115_AABWZD onbilger_o_Page_103.pro
4f339a16868dc6716c5c07c0e922b639
e3738fb7dd08fba5b6bde8ebae90742973151d7b
35248 F20110115_AABWYO onbilger_o_Page_081.pro
c17526cc921bef269ef18cd27d80dce6
04169647426e88af0fff4f49d95a8938565d6014
86052 F20110115_AABWBH onbilger_o_Page_091.QC.jpg
1d431b1061a2cf841d98a69091a02649
a14abf29eb401320b680970ae786dee4c4aa215f
771 F20110115_AABVWB onbilger_o_Page_095.txt
9a7562b04657cf0f4ebeeece9d0fb654
83330bf78eaddfc93299a7f31f458a12cff11ba4
31389 F20110115_AABWAT onbilger_o_Page_100.pro
b24178e62910499bbeb09b6522cad573
9eefe0d347a8b7169887be2fef7bf004499b0d95
1656 F20110115_AABXEK onbilger_o_Page_118.txt
c39d198bf13bcbd87152cf7f94525d5f
8bf3fe5df3c19e0505c31839e0a6122722dba37b
1878 F20110115_AABXDW onbilger_o_Page_097.txt
933fd5737eaeae8b4b1c747d2fa91368
ed7555e248b7b82c49037772b221335727e4dab0
2027 F20110115_AABVVN onbilger_o_Page_070.txt
ede8accd807f382621b586f91dac0456
c160f74c8f40456f87efbba73f4cb81cd1005e9d
33867 F20110115_AABWYP onbilger_o_Page_083.pro
ed746ab256f9de7e395bee880d56fd4f
f7a752aff909aaeac72986b5da26d8f0b0f6a8b7
200381 F20110115_AABWBI onbilger_o_Page_109.jpg
f998d712598e3e06ea029a19d0cc8742
50fbb5821137e4b23fa73d272220b0fab2237af6
54624 F20110115_AABVWC onbilger_o_Page_091.pro
5e791bc57a67f1dcd4e9b4195d0d21c3
f711f9ae97fba20e4e12192b7f996287d2f42f19
890748 F20110115_AABWAU onbilger_o_Page_128.jp2
9307081148285a66781767612b40ed1f
5f3a97eda650c0c6cd633a32ec21939207bb7529
45801 F20110115_AABWZE onbilger_o_Page_106.pro
357538d7cfb14f83099947b2b2edc121
a52207b93c869a97f948e57d7363f37841c4f388
1981 F20110115_AABXEL onbilger_o_Page_122.txt
bc57078e864bfdaa10103b4238cf44d1
e4c0dd15e4112e5468782212620afd9ff6c49a9d
21128 F20110115_AABVVO onbilger_o_Page_125thm.jpg
a28d17ecfb561617ea9fd0aaf33aaf34
f1bdcbdbc9db8641f2f2621290c5dfbf36591334
51593 F20110115_AABWYQ onbilger_o_Page_084.pro
e4d706293120c035a1848c538befd6d1
c316a9efacd0704ec163bc4688aa6f132102c9ba
911 F20110115_AABWBJ onbilger_o_Page_115.txt
353a36328c814f96e9fd134295d82bc3
86891e97fc68c6a42575eba5451605d5a886bf66
183045 F20110115_AABVWD onbilger_o_Page_066.jpg
4c334182012a291c2ac28d2ccea2d0c8
8ecc0276ab754dc45b7c5cee7c0148d7f39cc399
47398 F20110115_AABWZF onbilger_o_Page_107.pro
ec80af64017f0a6e3befe7f5e83e7105
c7a61ecddb73a0ff20754c019825a913831af038
988 F20110115_AABXFA onbilger_o_Page_142.txt
7ca473a68785a3ef9eb9fad9dfeadf8e
7ec46717b2451967da6ffcea9d454995651a5286
F20110115_AABXEM onbilger_o_Page_123.txt
847a98a635ddef343bf58320658b7619
67c008e1a81892458dfbc6b82b15ba782c15d652
1586 F20110115_AABXDX onbilger_o_Page_098.txt
0d9b62682f4cdb16a90c544a7ab52efb
f70ad9655e57a36cfe274212ac30437117467cdf
1960 F20110115_AABVVP onbilger_o_Page_051.txt
64d95d5eaac8e2ad05dcfec40933d0ea
61538b13731f6ddd2bb87135f117216b1e0c69d0
47607 F20110115_AABWYR onbilger_o_Page_085.pro
bb6dbc583764b11dd1f2aeb4ca8b45d1
ba6734c3521758eeb6a9a0a4de5c91565f2be28a
49781 F20110115_AABWBK onbilger_o_Page_023.pro
26f9ccfabb95c3efc3678c5a4084f703
45e217baf4bc4b737462b77a865b806eee28a4a9
46491 F20110115_AABVWE onbilger_o_Page_033.pro
1055275a1ed2a91e64ad0d563ef49177
a1db4b18d1f7f64867d78b3797f2c64f9b7974c8
78648 F20110115_AABWAV onbilger_o_Page_082.jp2
b766bccb792f71f6ebfb44f8ce33c22c
fbd60a596251ef38fe9e1a94271e8dc62f756a42
48723 F20110115_AABWZG onbilger_o_Page_109.pro
be6d59d339ee956c8114312ce641437a
6f5a5c1d70d8ec7d61ec135d20a61ca27bf8a940
F20110115_AABXFB onbilger_o_Page_144.txt
b22d7088b6ce878ab9ec678a868df60f
b64373e9669e99abc20623b73b5a87ca8bcf0fb3
2058 F20110115_AABXEN onbilger_o_Page_124.txt
89e265afd1ddcd8d72734c06da599fe8
b577fe559568a43b2429ae7a87f62e472d012e79
2000 F20110115_AABXDY onbilger_o_Page_099.txt
51d5e8f80418ae5d22f42f045891aa54
58da6559bfe731a8235f87b53218069bee4a0b64
103984 F20110115_AABVVQ onbilger_o_Page_110.jp2
f6015d0034a4f3a517577908fcd8ca77
a8f8d301658811105e7f9b38eb20fe3cb1b90ead
49547 F20110115_AABWYS onbilger_o_Page_086.pro
638de2d1cc74367a054e34d93ce8b625
850aaadae78a9141da19260e75f57d1f64233dbb
F20110115_AABWBL onbilger_o_Page_168.tif
95753a8e762e58a5ea23139533f83592
4a08e771a7c44b2beaed4316acae440c3553197b
F20110115_AABVWF onbilger_o_Page_019.tif
b527fb97fcb420361d7448002ab5c607
ac7754bababef8c7f0eb08bb366f95edb70b0760
F20110115_AABWAW onbilger_o_Page_082.tif
2587fc2f5780317540cbe2ec0c29c150
9bc6fb6535459f19633db7a310e33efc5e24b8c7
44813 F20110115_AABWZH onbilger_o_Page_111.pro
b185904a0318c0892104b4586975de78
32750c9d12ad80c74dca7c68ab29465a2bb4ceed
2227 F20110115_AABXFC onbilger_o_Page_145.txt
6d5af2101597acddf221cfd6c84595f0
8e74cd3e44a08e4f7f8855dca343b49d39406179
1690 F20110115_AABXEO onbilger_o_Page_125.txt
7790fb5454ebfa46cf1cf28577009f0f
6dc324b083c83f148f4668491c411f0ddb9beb38
1577 F20110115_AABXDZ onbilger_o_Page_100.txt
5bb6224b8ded0a1aed605019753e2b32
cabb10d6109f735cbfca7f5f1dafb1423b637cb2
207587 F20110115_AABVVR onbilger_o_Page_104.jpg
8e5339d9323e4d9f48854e7c0c4c0370
99d1f708cb498c972570ad3fed5ec0eec5cf981b
51496 F20110115_AABWYT onbilger_o_Page_087.pro
a866ae25635d7dd4159a4df33b1ba0ff
841790897247063921d3b69f8a12d02501986daa
90217 F20110115_AABWCA onbilger_o_Page_125.jp2
1625c2fb6d5e081d2b1f8eb9854bee80
c1404d57e649563e9816f2ccfa7c885127207e59
F20110115_AABWBM onbilger_o_Page_035.tif
04dbf611fd6e480b384719d82bc8c8f9
4f48b2c8d5968aff0677ec1de4557ebb910d63ca
209704 F20110115_AABVWG onbilger_o_Page_040.jpg
e6e27e411c5ba6fc1d5893306f2ad4eb
9352803444b1964950546eeaaae44a7effa01a87
188317 F20110115_AABWAX onbilger_o_Page_013.jpg
1f4b0c09c3548d498927c487b4d02af9
7968f1781b98435f0b6efe1479c69bc801b1f266
24422 F20110115_AABWZI onbilger_o_Page_113.pro
cd480ead635664c3887bc7bd0e04c040
827620f46edb6c812bd55870d27a0887f45156da
1534 F20110115_AABXFD onbilger_o_Page_146.txt
2978d19b19b1a59960115cc222625406
c5af6e08eab27c979e5f9022235c44f30fb7754c
1842 F20110115_AABXEP onbilger_o_Page_126.txt
a41f531bfdb306b466b8ed1ef225952d
429717bfb7478ba63dc1ab302fb9d4407a02230e
206843 F20110115_AABVVS onbilger_o_Page_022.jpg
4b684eec091d48d3928e6330a417bc9e
10d6ce791da38539cac33d5b1c3f950d15a5b14c
49521 F20110115_AABWYU onbilger_o_Page_088.pro
5ac01f9034a967578558362721bf8836
1cca21515e45bf1652450c0e48f8045386a0bc24
1552 F20110115_AABWCB onbilger_o_Page_127.txt
5277c6d1d9b9b380b1bff6e40b2eb620
e6d2192f8dacf66cb70bf8a3fa5cb4533cef77fc
225152 F20110115_AABWBN onbilger_o_Page_073.jpg
959fca7c02256614061d5b8893172d1d
1922e3f920060fb4fd3e14f20cf3f8affe8d3b32
5974 F20110115_AABVWH onbilger_o_Page_002.QC.jpg
b4fedf881348f783fb2f6bfdca57c789
126d724db1e5da9a6c62390d6ef657286b0b9ef1
25663 F20110115_AABWAY onbilger_o_Page_036thm.jpg
b0fe2021387c95bf822accb8490f6920
00a8d10f6a10025d4ee482390b8a92e1787fbadc
24352 F20110115_AABWZJ onbilger_o_Page_114.pro
6c23eb5b7953c33ad3350998a8b140da
43ac949e93cf5396afb417a8153512f6c66e2407
2143 F20110115_AABXFE onbilger_o_Page_147.txt
c36d0530090c9de61c5a022f3633507d
4a125da437254d03d70bf4f346cc1ac84e956faa
1713 F20110115_AABXEQ onbilger_o_Page_128.txt
90c00605e9d86c1416f375cdfa4d4ddc
25c87a3b262d00cdd95f7f3d6dec031495141af6
24629 F20110115_AABVVT onbilger_o_Page_105thm.jpg
c58976456734c8f7eace61a12f94f4f4
760ca8c530c6e4d36d5504601914aeb8bdcb40a8
53386 F20110115_AABWYV onbilger_o_Page_090.pro
2b060aefc870643233819da46c4b0edf
d50fc9e541ae52a926c33e3e1c451f7b803ea5c7
274255 F20110115_AABWCC onbilger_o_Page_166.jpg
547edafe5d2e224fb06b0b2c567d2bd4
ce6b07b07f1889a2fc82dfc2f1e6b0cd01433c6f
105501 F20110115_AABWBO onbilger_o_Page_101.jp2
74eec2003c4d9362765d7f5125cdd51d
866bd9d995b7f1e83df25067ddae4b588291d208
53918 F20110115_AABVWI onbilger_o_Page_073.pro
d74204cfa44bc21758d519ea4e9e1dc6
b1c0c35b9dac609d359f5a7d1bdc18c0c5911cc9
75199 F20110115_AABWAZ onbilger_o_Page_120.QC.jpg
d3aace4c63b109502259d5ac599ea9a7
86d7fd24d2a40d38eb254fe758cdd5207a81b99f
17204 F20110115_AABWZK onbilger_o_Page_115.pro
5b82aa360014af981859a89be2f90b80
d334ad800a393ef3d78961d789cc9f283be49379
F20110115_AABXFF onbilger_o_Page_148.txt
2faeacdb7a5426102ad6712b1282b76e
85a6c3393a9ea54c22d57133640621ac50a11eef
F20110115_AABXER onbilger_o_Page_129.txt
4d2737fb6032a19d5cb45bae502a0e49
4783e8954ae58cc62ea65eab57dbd6b169fd4e80
F20110115_AABVVU onbilger_o_Page_165.tif
c88ec64ab9ffd4d1e322e095e4861610
452c0b17aaf9ffe8110bbeafe27a27e9219fb6e9
53852 F20110115_AABWYW onbilger_o_Page_092.pro
0ac7e4180309c4e3de0e5c470f2ba2b6
2721de5ef06805edc65ebc01e48d4bcb3e768064
24832 F20110115_AABWCD onbilger_o_Page_138thm.jpg
8485cf29b7ecdab36a90548570bf3300
79f8339304c322655559e248e818ec0865c1a4b7
111694 F20110115_AABWBP onbilger_o_Page_020.jp2
2c1a0d25a01b235eaf7b0a7ac6674bf2
029cf1c7dea1c88e0540f77628b19f0b920f338e
F20110115_AABVWJ onbilger_o_Page_164.tif
870d57628c4ec30c1a96ed7f03fdbb32
8a6a4d39874eda7a71368ef92581ad5d679a147c
4028 F20110115_AABWZL onbilger_o_Page_117.pro
5bbc8e776a3c7898198772a1fbdd44ab
46c817541a239d2cca41363d36d4fe1188c582c4
1858 F20110115_AABXFG onbilger_o_Page_149.txt
f327d33bff11fb0508fa411d3ae21457
c282c30ca0bf6a424c244691b5be9fc798d8bd6c
2770 F20110115_AABXES onbilger_o_Page_130.txt
83631845a2aeaaea4cf94adf1cfc7e03
77beea988ab75371aa3d9e71db8f1e66a87fc8e4
189334 F20110115_AABVVV onbilger_o_Page_150.jpg
09ba4a5e499d2720285eac86d275b3ce
0248c493e7635ad481e71beaec0a2666c5d51494
44675 F20110115_AABWYX onbilger_o_Page_093.pro
580ba3646aeccd4ab1241de4ba429ecf
fd27f6c54f8af1fc8cb4fe6677ee6f245cd8cce4
50467 F20110115_AABWCE onbilger_o_Page_161thm.jpg
43597bf3e447ec13816b8c27635ffc3e
aad7aae7ed453af47e8addccf9b637585036b575
F20110115_AABWBQ onbilger_o_Page_119.tif
2b63eb42fb12782d659faf95dcc6ebc9
cf11aa950390fa95d5c132c6d6cc2e32d7628a9f
204131 F20110115_AABVWK onbilger_o_Page_015.jpg
835b9da03ae24a15ec056738e6a8645c
327835949ca8a986fb8006edbc9efcd9b3bbd1ad
39597 F20110115_AABWZM onbilger_o_Page_118.pro
78c74797f2b15bef5b057e39cbebc32f
40ba4a3e026eeff68f7a930e622b9ccf2cbb33c7
1029 F20110115_AABXFH onbilger_o_Page_151.txt
b69b6ab5274e425928a92737f32d0f9e
1e5756d6aa8f7f54e43d0afb0ae708152f576f34
F20110115_AABXET onbilger_o_Page_131.txt
a534f9933b74888b929024deb960c381
f5a026375bf6d937473bb905f63b7be6ebf6d843
50050 F20110115_AABVVW onbilger_o_Page_045.pro
87bf35c2bdf72ae971e1279ab93322d8
46ce4c9970e2153751ef5d3bbb02f49bbca264eb
19233 F20110115_AABWYY onbilger_o_Page_095.pro
6cce709167163d1cd4b38e953ba66d6f
42f4db81e950cd1af1863ae78e8a39bf0cf1f83d
2177 F20110115_AABWCF onbilger_o_Page_089.txt
8911f493bdc35960085af0efefb1fd5e
f77cb073d3e663a90afd4aa152995935966d114e
F20110115_AABWBR onbilger_o_Page_100.tif
09ebef6e824712f156aa173dc79f09c2
3ad10c392aa7a8bb841cfae354a8ae8ac1f7a47e
86470 F20110115_AABVWL onbilger_o_Page_127.QC.jpg
0c65801b5bf2779398885f61360a5233
5e74da731ad471ddff265b7fab760e4841f979c8
53297 F20110115_AABWZN onbilger_o_Page_119.pro
2843d28ad26b424fb58373ca89c85808
6d7f5755dc409cd042e8989ef8bed4ba5b28cfa3
1681 F20110115_AABXFI onbilger_o_Page_152.txt
3525ce95c3ade85f3bfa6295f9a0298c
63aa1f0ee4821775cbef229b5f52c29f4f90f2a4
1881 F20110115_AABXEU onbilger_o_Page_133.txt
25c3bc228852c962f0a0ced843e4f09d
7c9d34f4bfacabc690b34994c4209e8edd2d84c7
79924 F20110115_AABVVX onbilger_o_Page_153.QC.jpg
8d767e756ccc54c58a612f37eb166df7
731b2a1fa1b9717ace9d35b56c6381ab0f965776
37817 F20110115_AABWYZ onbilger_o_Page_096.pro
193d6f55058283c6abf40b6ca9d80ab1
b7a4825e8932debb8e8849a96d8d1cc39f8f60bc
19786 F20110115_AABWCG onbilger_o_Page_141thm.jpg
d6540a0d4c8bb396e3c0c01b34ce4971
f933d77db78b0fb0f0960376754d732a0d3ad732
386402 F20110115_AABVXA onbilger_o_Page_006.jpg
30816e7b97799486c7062b0de3902ffd
8bfc3991f6d8909358e3e36cdf21ab8e77c93d70
1764 F20110115_AABWBS onbilger_o_Page_150.txt
adc5a39dc64ce34c640427db18912e81
8e0e9f9602af875294f1ff12d287b97a9e388182
2018 F20110115_AABXFJ onbilger_o_Page_153.txt
7882b3941acd45cc748e262f4c96b276
9a996647db5f3a1c04a12d0db4a9928bdcfacb62
1890 F20110115_AABXEV onbilger_o_Page_136.txt
3daf50965e7f9979b4ade3ada31fb630
115313b3819643418d4789c8663f2e706455fd1c
1820 F20110115_AABVVY onbilger_o_Page_062.txt
b632cfaa284f15c9419838345acb9967
221bd372ba5af58c4984514068184426ae8ae49f
76109 F20110115_AABWCH onbilger_o_Page_021.QC.jpg
d04eaf5ce677f0fec045cf53e3cf7f89
4e0fbb05f239fc7aca675d95e4877a76ff239f44
57787 F20110115_AABVXB onbilger_o_Page_105.pro
2b819350f0daeaa9a85417f01913a97a
37b10d8826d1e96d1b8ed82c737fee2557287ba0
44166 F20110115_AABWBT onbilger_o_Page_047.pro
bb2bcba66ac20217aa7bf618b1e619bd
1774f67db91d36b847b02ca170d5e315e7304c51
77158 F20110115_AABVWM onbilger_o_Page_104.QC.jpg
eaed2e39a5fe2ec2ebece12da0c3ea6f
648db12ee8ebb0f2c67ce4213165e2e9c9bb56d5
49504 F20110115_AABWZO onbilger_o_Page_120.pro
91e76e25d99cbb34d751a488073a5c22
d47c105da6f264c4e61f82ca661a09a0d0cf8463
1992 F20110115_AABXFK onbilger_o_Page_154.txt
40bf3d4819760ddfeabad273469aed91
a5e263539f641524d29a59f57d9a90b4a95e5127
1846 F20110115_AABXEW onbilger_o_Page_137.txt
97f6aecd698832392a95d0f61d86db76
5781318cde65455eea5e59e467a5871574c3c944
263086 F20110115_AABVVZ onbilger_o_Page_165.jpg
cf8b17737247645de05c6979a5327edc
7403c46eee9ce085cb8501e49802ecd2fca9cbac
46611 F20110115_AABWCI onbilger_o_Page_139thm.jpg
be6d9527d8f503e02f57c79a3624085c
a84d5206a783e8b4297f9d077910b7f51c228f47
51837 F20110115_AABVXC onbilger_o_Page_094.pro
43ccbd8c7aea1f02cb19379761a1d9f5
c89c819fdf5990c9772f32084bc2daf5cdea3260
60337 F20110115_AABWBU onbilger_o_Page_164.pro
97570412a9bdf35127f68a639d5f88b2
18d6146a434e11730d7db3aa75444ec00c023474
47503 F20110115_AABVWN onbilger_o_Page_110.pro
bc5d870ae15665a732d51b8a667bd4bd
60fe136d24c91c6232b0e083fc036c83ca778bc4
48831 F20110115_AABWZP onbilger_o_Page_121.pro
9ce028c70e4e7343619847f76d214ddb
4293633f2af6582b50c588e56a86c8cd0eff64a7
2778 F20110115_AABXFL onbilger_o_Page_157.txt
23fbcef94891d15c04cfd87a13bd4259
2ffb394195dfa4c5412bd06e43d0a65c06718e5c
2080 F20110115_AABXEX onbilger_o_Page_138.txt
d98e7df807e7b7bbf1c799529b991adc
0e42af23a4e382f0ed0843ccf56ec84aa3ba50cb
F20110115_AABWCJ onbilger_o_Page_046.tif
b90977b5f4ac50b55dc5759e50d08a53
2c11c31775437abcd3c0d56e8aa68b7edc9328ee
24896 F20110115_AABVXD onbilger_o_Page_143thm.jpg
0b23f86ccb071f44e33405c82b475554
ed7e23fc3455f5daf27fd275e25c540ce9d21c25
81927 F20110115_AABWBV onbilger_o_Page_164.QC.jpg
b4684224a1da94070fbe2ec61195b064
79b453e325cdc5ffbc9892a12c8eda54ad71e80e
90540 F20110115_AABVWO onbilger_o_Page_058.QC.jpg
2e2165b6bc1080348c4daafbcfefc89a
c2109704693b602825ad267c691f6da0f9ab6cd1
50322 F20110115_AABWZQ onbilger_o_Page_122.pro
33794c59d59ba79301a0a6d0f7633540
5a1fec8299b31c3716a5e49f3402d04a21505326
77184 F20110115_AABXGA onbilger_o_Page_031.QC.jpg
de27b7e21b57f8fffd49b45f52796209
7ef59c9663e4c24d6d45e380fd1ff668b545ae31
332 F20110115_AABXFM onbilger_o_Page_158.txt
0761655e45d45ffe98452a03b6ccfd1d
334a936196effd84470cdf12e2cea251a4cf43c6
719 F20110115_AABWCK onbilger_o_Page_008.txt
f9c23f572c8fba87bc7ff0a57ad516e6
a99adb2bd889ed4d59e4cdac6aed36d39da272e8
75054 F20110115_AABVXE onbilger_o_Page_005.pro
4a73b7d43fa47679eb909ebbc858adf8
32e2a02ea34158810d7228aabceb3f42ea8b7291
50224 F20110115_AABVWP onbilger_o_Page_090thm.jpg
574c9ea387025aea61c48bfe25e6d169
bc38255502735a3789017785158ec63f455709fd
46721 F20110115_AABWZR onbilger_o_Page_123.pro
0a69743e9c330840daa09d5b1782920a
c4ef0950cccadb2d8c894f0a468187b81c1102ce
25981 F20110115_AABXGB onbilger_o_Page_091thm.jpg
b6e6172147c97697640bd9f40ca5ddc0
21c1daf59f8ff6615fac77264b5b31adf3bae0ec
2175 F20110115_AABXFN onbilger_o_Page_159.txt
beed5d4affd5142311aa3c47d711fad3
670a6ef9dcc1443581306088fc649766e6fa0a8a
F20110115_AABXEY onbilger_o_Page_139.txt
885594a3f177fea95fd5704a569dc584
de59ed7ba22422fcd8a96bba066d1411c8bea5cd
F20110115_AABWCL onbilger_o_Page_056.txt
5a057f8c0b726438110835f6ada8ee77
ff43fbcc2679bacb5d3407c3235473ad18a16eb5
F20110115_AABVXF onbilger_o_Page_108.tif
0fc28c0043c8e9387e92d838be36edb5
0c308049240f9c2c6b30b483c929671d9f10eb01
19504 F20110115_AABWBW onbilger_o_Page_096thm.jpg
11c33b545339198e5337f29b525d89ad
55b89fbc99488e7abc09242cdb1e460fedfe88b4
658229 F20110115_AABVWQ onbilger_o_Page_114.jp2
7890f18254b87da69f0b5186c16eb847
149b6107668566b1f9a47a7fbb5de424b19bb131
52271 F20110115_AABWZS onbilger_o_Page_124.pro
56072edbd92810fc6817a3f64e86c545
990238edfb90858187ca0ddc2f0937405342a83d
23491 F20110115_AABXGC onbilger_o_Page_029thm.jpg
5f59770d72828d24e0327e9535c4bd59
83b372e8054da7971400c6db3a178b4da3ebe5af
2520 F20110115_AABXFO onbilger_o_Page_161.txt
366aa415220e9cc005ff0f11fa54459e
fe1c6788d6f9c44b2078d233f8b8a41519b6f9a6
1202 F20110115_AABXEZ onbilger_o_Page_140.txt
99afac95e37df8a05cd281ab713e1966
a4e0cc0be919996c6f0f56a604c705968747189c
41251 F20110115_AABWZT onbilger_o_Page_125.pro
22d77ab8b88626a4a19cbd3a3492b237
cd744025d3d4bad30a3d4fe7cb8fce081043a838
23738 F20110115_AABWCM onbilger_o_Page_062thm.jpg
5288363f2fbdd9c985c775dde0153cd9
a278812f043a693968430011259878f78627dc3b
1592 F20110115_AABVXG onbilger_o_Page_096.txt
164bf7949ed2a512046da7e205a4b31b
20d3723a9f819a28b9e884968e6f6805334ce595
46746 F20110115_AABWBX onbilger_o_Page_142.jp2
07e08696e52b96910205c453f4a6a37e
a0cef77dfdf1d5a5d82386ab166c9d7578d7c50a
105062 F20110115_AABVWR onbilger_o_Page_109.jp2
59f3758203a8aef76b2d9076b271e696
9d0efa112b2ac43611480b5840433f94e8df09d0
61682 F20110115_AABWDA onbilger_o_Page_057.QC.jpg
4bbf45a57e0f7ffc739ca2eabf14b8d2
733117a66629d3f5ad00743f4e3eb9e6c0c5d577
5926 F20110115_AABXGD onbilger_o_Page_158thm.jpg
428cb56489959050bd0f3c3e8ba4800a
555ebe6b2452a31692b4efddd98750792c86d1f0
2630 F20110115_AABXFP onbilger_o_Page_162.txt
5da9fca273be9181866947ac41fe247c
0c8c75f16a9298c0eec2294bba22d8e99d58f809
46189 F20110115_AABWZU onbilger_o_Page_126.pro
5109bf760ddbaed4b99226c49d9e6c4b
3af215af764f162719f8e5d76af09a625c7105d9
21316 F20110115_AABWCN onbilger_o_Page_010.pro
ac795deb48c6beab2594b9c49663de64
1b753952098a06d3e0dc0158891a2bf3e85c2d54
25315 F20110115_AABVXH onbilger_o_Page_155.pro
4f112d51c3cc884f8b1d0ee437a9f1e1
b695ea2a263bd13943f5d206ed30b3c204592d2c
101062 F20110115_AABWBY onbilger_o_Page_145.jp2
e77af4b428fc13c7d6db15aa179d7819
3dc0eed8c54e35290fc08d1e1b1ed7e8bc16ea2a
77162 F20110115_AABVWS onbilger_o_Page_016.QC.jpg
18a405639531f06dac30bba6c8eba8e9
1c4e3f6547cf408b6d84d568a621ac145ff7a92d
68571 F20110115_AABWDB onbilger_o_Page_134.QC.jpg
b417ebe8086d63ad9b077f96349ec60d
e212e8f0c0333819647d6bd3457c9238e0c6d286
72008 F20110115_AABXGE onbilger_o_Page_093.QC.jpg
47facbb83ea7b45e2cfa7631459b50a5
f501dbed5a28c7b027c350cc9f3944b8d6e39dec
2509 F20110115_AABXFQ onbilger_o_Page_163.txt
9b1ace5d7789ecd583a7f33b5839b10c
e9ec94faf2dedeabc4c9abcab71bbf0c11b5ebca
34951 F20110115_AABWZV onbilger_o_Page_127.pro
4aa281d69a091b7a709ffb595ea571e6
b4fb8afc4c665e725b7f64e2d00af8bc7a530fe0
1545 F20110115_AABWCO onbilger_o_Page_057.txt
222edad7fcbb643c855fbe3c7ce2771f
a8c3ecf2ab8af990735431255a6f1e79fdab11e8
25597 F20110115_AABVXI onbilger_o_Page_049thm.jpg
5e601150f562f4be203a6df4914ba390
f612663a51de5a493e59d9dfecf06a47fb45f51c
1929 F20110115_AABWBZ onbilger_o_Page_121.txt
cacc7cca3506963c30e239236490055f
366cc2454fdd51084bf40cca1ee44017299f4337
20651 F20110115_AABVWT onbilger_o_Page_056thm.jpg
25b65d045fc03593a4567efd0e988cc9
de7bfafe82221173113ac90d1530aa2c93c47973
23720 F20110115_AABWDC onbilger_o_Page_050thm.jpg
e54156668ce23e4d1e3ab6a9b4595926
cb13359533c618f31eace39f7f75b76168f17c9d
21660 F20110115_AABXGF onbilger_o_Page_046thm.jpg
04fadcc43b2fcebb259dcafd38dbbd56
cbcad02756e292908fb7575b9ce9e37a86b2b9cb
2441 F20110115_AABXFR onbilger_o_Page_164.txt
1c202218b9eb170e451c51d5c5785182
f755c4f16397dee8595dc580eab28a395ed9a937
38813 F20110115_AABWZW onbilger_o_Page_128.pro
a01b49abf73ebd683242c3ecd7f4dd75
74ab9d03f05dfe9b72968ea2d7a67811718e6a3b
F20110115_AABWCP onbilger_o_Page_014.tif
302ca77c44baa23811edc8d17b1d2e93
fabc1751146fce47488e1500f3e3e8ea006659d6
149559 F20110115_AABVXJ onbilger_o_Page_055.jpg
d5de7a84c7d0807d4db6a80c140ceb4e
a44c75d48cd5a111f4b43fb8b580431449ce9e31
1664 F20110115_AABVWU onbilger_o_Page_141.txt
ed79458746c4375bfce9fd613b311ece
bfb3bafecc58fe72e3e43c62c9f3007e8aae4a6d
71952 F20110115_AABWDD onbilger_o_Page_026.QC.jpg
d944a5a42599a89d528c6958e0028b42
07a0dbbb9a787d5fe09d6d5a6fef764bd7a5c2f0
82309 F20110115_AABXGG onbilger_o_Page_073.QC.jpg
910f8e68dd34a6df1025f3562894e154
f583120f06850ca0aeb27f1b25047b009db34381
2514 F20110115_AABXFS onbilger_o_Page_165.txt
b13c3d3882d3af5ba1db088fb90e1676
8760b5673d8fda1ca2b1dcab4ff0e3680d0a013a
39207 F20110115_AABWZX onbilger_o_Page_129.pro
91362f966da90d34ed554e0b18cc10d4
04365281fbd5c323db3ee133926710f5da0581c2
50890 F20110115_AABWCQ onbilger_o_Page_035.pro
fedbb20e2451edf142688fce90f7f353
efeb757771f458295e59f1086a4d8c6950da0754
F20110115_AABVXK onbilger_o_Page_133.tif
8474b6ec7006dac4c2d3f525fe8ddd8b
98331b37cad6af7d176812079a3d8375071715d6
F20110115_AABVWV onbilger_o_Page_056.tif
49411a06759d150a996951ff255b50b1
32b073889c97884986af533ffefeea1a42e15025
2106 F20110115_AABWDE onbilger_o_Page_119.txt
67e7e541a139d94e8310f60c54cd60d2
801881d3500894d00bb455ef1eb9456d0ef34249
24137 F20110115_AABXGH onbilger_o_Page_137thm.jpg
01341d74e174ae0ad42fd2519a3bb262
b19a063ea1d9d58a6eab97386c4c8f8f45c7c610
803 F20110115_AABXFT onbilger_o_Page_168.txt
dffb3e9ab1a5bc95f7b481b89de67ab5
ff84a36cf4c5325334957ddc9016b4457d88e9c8
60177 F20110115_AABWZY onbilger_o_Page_130.pro
c38b318d6d8b13e44aade7785950bc23
6b8dd94ffcd2d57035c5933e6722e1f3f810f3d7
24134 F20110115_AABWCR onbilger_o_Page_064thm.jpg
b8026cff7d187273d04e2d6dca94ca21
86c7540dfbc57e06e40d9cdda6cab64ca11a777b
35300 F20110115_AABVXL onbilger_o_Page_082.pro
26da086715def75593b85170a553c904
752f29e2cd5378a5a6357104752dc4166d781952
45717 F20110115_AABVWW onbilger_o_Page_152thm.jpg
0ef924b1ccc3a2a869b8db8fc312bc19
37ce7a84445e4290dcd692f85d3bba1235089c6e
103681 F20110115_AABWDF onbilger_o_Page_085.jp2
2f2b67c0de2722f4072652c2acaf5b7f
10c1fb655803e13b3e05970aba518a472b770c57
57724 F20110115_AABXGI onbilger_o_Page_082.QC.jpg
b6c7e01437482846a7a166ba31668544
e475d98ffbef4686744b7fa4f93f2f41065d6841
741000 F20110115_AABXFU onbilger_o.pdf
efccc9260351c8ed67aa1d0d75fb3204
2e2608c372df248da638aeca67f67ba5549914a7
49388 F20110115_AABWZZ onbilger_o_Page_131.pro
6d4cb66b8907a8b3761a170d824cce8d
3d083036139c1f807dcb987b210fc4bde0f24cd6
F20110115_AABVYA onbilger_o_Page_008.tif
47d6f911db257a3bcdc060805b32315f
28f927011ccfc0d1acc1bbec8bc1a9943ba7edd4
199551 F20110115_AABWCS onbilger_o_Page_017.jpg
093e8c18c620c59d70af2da17620b4af
9121ab5223d0527f1826837bf229f141188b0239
213536 F20110115_AABVXM onbilger_o_Page_124.jpg
0067a622ce4df90ceac89e8cb038501d
4c8c4cbf76420d9de33979f79fc1bdac62262197
110746 F20110115_AABVWX onbilger_o_Page_108.jp2
ad973189b01bb296d2ac8243bf135d6c
908d0fa797d5a94064fba9b291401931c43bd1ff
1931 F20110115_AABWDG onbilger_o_Page_112.txt
4f1df511374a66a9141ad088a2f42176
df898a2a60a7138a688734602ea6942d0ba83872
65656 F20110115_AABXGJ onbilger_o_Page_041.QC.jpg
b62307ad7a55e150a65170f2d5f3f1ec
2cb3a39ec25f7b3f6a06c4d2c500756686c9da95
77680 F20110115_AABXFV onbilger_o_Page_064.QC.jpg
db020db20cf627cb8bf3678916487c32
e42222b81e313e35101a56c80b7e5c3ceb2051b5
24696 F20110115_AABVYB onbilger_o_Page_027thm.jpg
7ebf1b6f59fb967328053310364ef6e6
849f351e34657f70944b74624873da3afd6871c2
75263 F20110115_AABWCT onbilger_o_Page_110.QC.jpg
08c6991a205955699bb987ef180a8b99
f1fef18caed26090fc00ac81385bcbbb8e79de75
F20110115_AABVWY onbilger_o_Page_064.tif
66565cbea9e0df70741c51e828e138dd
c853eff5818ab7c208d6aceb52767efa501ccc69
109039 F20110115_AABWDH onbilger_o_Page_042.jp2
00761fe5505623ff5cb22797758907db
b346f416bd696d574e4b7665e0c8c9a310536fcb
10307 F20110115_AABXGK onbilger_o_Page_117.QC.jpg
102fdf09d5e8a551fbae85484a2dfc71
2b8cc2126cee7a65c1f40109e21941941f184d68
24773 F20110115_AABXFW onbilger_o_Page_121thm.jpg
e40fc18f2c166e0cc6332f4a8fe47a2f
16bea40bc0be07caa7057cd171221657a2313f0b
F20110115_AABVYC onbilger_o_Page_116.tif
bee781d352416e3cf2403071deb4e97a
17a0bfb97e1535ef97f4365388b5d8235dc4e491
F20110115_AABWCU onbilger_o_Page_031.tif
e8f0e470ceed603cdbf638578f284cda
5916d7a55cc0706147513ec73b406a632abdabaa
197086 F20110115_AABVXN onbilger_o_Page_033.jpg
c6f20f29812d480946bc06525b5a7bc4
3cbb7f955460c127be69736a3e1ced984f4740c0
24062 F20110115_AABVWZ onbilger_o_Page_067thm.jpg
11cbd342826a21a790e8c8d9336da1de
ffbc51144d79f2f5a409e7420d4322a4cf6bc39b
88812 F20110115_AABWDI onbilger_o_Page_118.jp2
b69692a69c20d47b460e6e24825c8e88
377c8301bbb1c45ed29194ec2dd4b7d6e1aefff1
21809 F20110115_AABXGL onbilger_o_Page_084thm.jpg
cf7bc2cdca300a29cc9ea33949e87ce5
315a395513affd9b31c2674f40ba7a9914eb8c69
20581 F20110115_AABXFX onbilger_o_Page_118thm.jpg
d0ae7c476ca2d4a7b85b507ad0c0c0b5
a5e6f1842f0262cd6a4fce99b24883f007552906
24457 F20110115_AABVYD onbilger_o_Page_122thm.jpg
5c68bda77065b7c2358c4c38a536d392
10a397d82463a4655856527492507e7b44759060
24615 F20110115_AABWCV onbilger_o_Page_163thm.jpg
70d3dda0acb95fe390907d95a72391b9
935578cde75e3100125c0cdbbedb172cc5c1ed5e
25145 F20110115_AABVXO onbilger_o_Page_074thm.jpg
95d51be46ca14341daf42fc2901d81c7
025dd59d9e7590d4fe5df21aad601e91bf700a28
F20110115_AABWDJ onbilger_o_Page_102.tif
94344b94749e71a8004a86d09b76d6ef
60e2a1246962d2d46c8420430ffcbd55cdee57f0
44284 F20110115_AABXHA onbilger_o_Page_028thm.jpg
b7c2103f618f0a7e3f4ac20b6990f645
a7eb0f1f1d499a7b3b8662612ac2519527a30ba1
67811 F20110115_AABXGM onbilger_o_Page_047.QC.jpg
30e040b9a14a6499f02e033b1da84662
6e1e5113f1116d7aad0a1c425f07c8dace9eea46
25311 F20110115_AABXFY onbilger_o_Page_094thm.jpg
f7e1fab9b385d79dbd419affddee99a8
44e73450bf1db4d99995c75f958a631291b6df44
21829 F20110115_AABVYE onbilger_o_Page_066thm.jpg
0b8cfb48a689f532bca85474d509cd03
f886e5caa995e80bb92c6f84150ce225bfa7df6c
52965 F20110115_AABWCW onbilger_o_Page_006thm.jpg
e6d579e84977695f45f151308bb6dacc
fd8b67e8b62aeb0c577928c2f76a5c4c4dfb1058
F20110115_AABVXP onbilger_o_Page_052.tif
7f223b441208ecbc4f12f24cc83214f9
953329bc54f01dfdfce419dffc8f5d0a74a1f091
35038 F20110115_AABWDK onbilger_o_Page_011.pro
9a92eacc213533e1cb5043afb92d27cf
0ecaff6e01a5e3bea59c36cd9c79feff53b6d121
79750 F20110115_AABXHB onbilger_o_Page_156.QC.jpg
ddd3bb9d4a3245ff6132f39a98548584
a642141b1f3efe9f2662130ea5f076c86b6d8a32
40408 F20110115_AABXGN onbilger_o_Page_115thm.jpg
583baa0bf752b416bef9e694d3291281
39b1ccb5ce540d237e77842e2ee6976e59037f04
1031 F20110115_AABVYF onbilger_o_Page_155.txt
ac9d488fd6d4be9d6ce69303136d7243
17a944a7617a5ac524d1b73b77f5b3b528649c5a
F20110115_AABVXQ onbilger_o_Page_087.tif
9df17b575edfcd2175845e4607fe052d
4c57e3800180f60da32d64a7f0052ba462d4041b
94846 F20110115_AABWDL onbilger_o_Page_041.jp2
336c80270dcdf08854007bdcc62543a8
d889fe4dbe2b7b8507e6306b0c5b247b63e9827d
18188 F20110115_AABXHC onbilger_o_Page_054thm.jpg
667d27c5b3ebd378283ee796f2a0bff9
8e7df813b11dedb6bcf5349f69af51ffc57a39c8
88577 F20110115_AABXGO onbilger_o_Page_128.QC.jpg
3530da498b3b784d08c8d297bc8c4982
7cc83dce340066eb0217ab116f447bf13248466b
24433 F20110115_AABXFZ onbilger_o_Page_045thm.jpg
68e92b58135fb2290c9574e76fa620c2
9f57846a0cf3f77ced3a645b99b01c5d0599d60e
154412 F20110115_AABVYG onbilger_o_Page_082.jpg
32cf7f31d3c0934d87e8a7697aa1e374
5807c407a406b4c03df8bfd31b3dbdc8c4cb0b52
111401 F20110115_AABWCX onbilger_o_Page_138.jp2
755f68df8cfa074e7f16b03a52e69088
82a804ebbb5162793f46162ca642ada12f2f6313
F20110115_AABVXR onbilger_o_Page_140.tif
edeb6efca69906df8563390f3182b883
54de4bf202eac9216c9d126527a0e6658f327f45
76108 F20110115_AABWEA onbilger_o_Page_088.QC.jpg
d79d0f7724c4d06c5430445de65d5efc
3e35d99e04c3459c6593355a08b5086aaa975046
F20110115_AABWDM onbilger_o_Page_106thm.jpg
9d3bb6395a2a7db182174a686a1322e4
80e43a32af2b9bc81569c8d72501c7e14530cc2c
24345 F20110115_AABXHD onbilger_o_Page_031thm.jpg
453ea3baaf3c43b81d9ba791cf494444
5dc8e3b55cc5a66865f9533c302ed3f5f71fa29a
80064 F20110115_AABXGP onbilger_o_Page_143.QC.jpg
ca0d3dfa36653be6bc6a1a5b6ed91689
f8a6dbfa49a362817adef0719431ee7f3b36455b
63448 F20110115_AABVYH onbilger_o_Page_118.QC.jpg
ea6d7720b37c519ab41aba08789a3c3c
7582628c483245d2c3b54485e0efe4b0723b9a57
44916 F20110115_AABWCY onbilger_o_Page_100thm.jpg
2d04caff961c2168ce3f693cc2f7cb67
6b0b175ff280c20b49a370081e818fe0bc8f9d5d
18391 F20110115_AABVXS onbilger_o_Page_079thm.jpg
b3097934f8e6c4e4efb17d529a77bc67
f5462a2998c3a6a08325d192470758ce6b83a0ac
46054 F20110115_AABWEB onbilger_o_Page_058thm.jpg
3bf8eedcf62d0087a3ff74c20fc6245f
52453f30df86e5c5ed146ed07cca7f19c021b4d6
1747 F20110115_AABWDN onbilger_o_Page_135.txt
45afafa8bae879d553a76c0e4975dc71
124a506e4b2871e5344a19045a48af02c5a30fd6
81830 F20110115_AABXHE onbilger_o_Page_061.QC.jpg
ae7241ccf8903e3df8bd3090fdeb8692
2b6f9e8a533847288cea89cfbb4fb8957ac1b31b
23916 F20110115_AABXGQ onbilger_o_Page_162thm.jpg
cce6ac1c41c2a690dbf75eed46d1193e
3c5468294f97cf806ad7ab003ba6fcdc9feecd28
11489 F20110115_AABVYI onbilger_o_Page_168thm.jpg
8c904a8265c7723bc8f900444c806709
0755c8a1eab3e14be4f550ab3369c62917423cfb
151596 F20110115_AABWCZ onbilger_o_Page_114.jpg
59f93445df1fd8f32f8bd0f3ad15d90b
8b1352bc85d8a9cc135c22d040269f807a9dae2a
255235 F20110115_AABVXT onbilger_o_Page_164.jpg
e6f5b2fe023bd3fb65fd4b6653863fbb
374eba1b2dc3fd26a434709f2b8c41f64ba5a035
110681 F20110115_AABWEC onbilger_o_Page_035.jp2
5fa406127951ddd6dff1cf1f2cd77ce5
9c878b3c7b1f17d443f3c0df114edc949730192c
191215 F20110115_AABWDO onbilger_o_Page_058.jpg
d243b042b1149b6d3be7de879d847b38
75a6647c766447c00eb9744b3712152833cfc237
18480 F20110115_AABXHF onbilger_o_Page_083thm.jpg
b4b5399bfb2286f12ba9b136d1a9c7e6
5de83dc7750e14998db6b0205ed286ac136842ec
18699 F20110115_AABXGR onbilger_o_Page_018thm.jpg
a468d3c88101d19d234fccca715c9b45
09d6d177aa323dae54af6a88343d91358698da40
52501 F20110115_AABVYJ onbilger_o_Page_104.pro
e4942e107b449f3c006c3f090130914f
44bcefd971dd2ad04ed3b9c8e0c82610eb629305
196621 F20110115_AABVXU onbilger_o_Page_116.jpg
317fba4d2f5646f5616c9a0e910e08f3
adf6e151405a75e9f1455f2c19a160e0b7a8a35a
106412 F20110115_AABWED onbilger_o_Page_064.jp2
41938a3bf64c991c1d422b40a1365952
a670aa680a8218cf9967ee16cd9f81a280c3d6f8
F20110115_AABWDP onbilger_o_Page_081.tif
5fd31a246da553c22e9e572a64946664
d056c93dc57d2010bf64d8ec64e01525be36bc27
73824 F20110115_AABXHG onbilger_o_Page_033.QC.jpg
b2ee6e2e7be661473335914946b5fcef
e74d11441500d275e7b8ebfb15ddcc15f7f66c1a
24716 F20110115_AABXGS onbilger_o_Page_154thm.jpg
811c63f624aef7b72214daaa45b7b299
f402a5680f2ebea83539d1e634ba1132d10d9f59
F20110115_AABVYK onbilger_o_Page_167.tif
7c90feb59c6bf8d318a0310be7063fb0
e80585126ac20bd2d277969f21e6f2eba38bf7fb
59732 F20110115_AABVXV onbilger_o_Page_146.QC.jpg
ac1ccc3aa0d447211dac4ae7d137735b
1a581dad689e8664be3537535b5fe7d3400fdda7
F20110115_AABWEE onbilger_o_Page_004.tif
f6ca86d9e451f7a85a29ad910bf3e7e4
b3bda99566d1fd577be9ec924c473a06889cd57c
83795 F20110115_AABWDQ onbilger_o_Page_146.jp2
b81d97935d0ed0ad18bbb03dee60dfe2
d2218fe9d72859a14bae7890a87423a46f80bd0a
75462 F20110115_AABXHH onbilger_o_Page_121.QC.jpg
eef092fc0d69f9348a79c8d4f6c3ae41
967873feae34302e6a4c61e5ba27ef685f0dd631
15137 F20110115_AABXGT onbilger_o_Page_158.QC.jpg
151e15d2b8a7807c40c6d6714f54ce11
a569dd5171733af26f4152bbe6fb4b4bcc9ceda3
108488 F20110115_AABVYL onbilger_o_Page_075.jp2
42fe46cc5cb417518c04a6fdc2a06115
6dcddbb1728d61101d83c35d27b80be0d0fabb40
1342 F20110115_AABVXW onbilger_o_Page_012.txt
3802ecec63482bf1379ed60ee5187d14
2f9490c1c16c97b18f5196ca841db4dbf3c16b2a
47963 F20110115_AABWEF onbilger_o_Page_072.pro
8a35c486adce76a1cc50ff3602a9415c
8c46f847ac87b781c99bb80a41a8526cb9391c0a
53047 F20110115_AABWDR onbilger_o_Page_049.pro
ec1e20acd45a1c445045dbbd72e1da5d
5ae81349352d302419437382258e2adcd8acc3ea
23061 F20110115_AABXHI onbilger_o_Page_116thm.jpg
72f0ccf1f0f2b4484f913759810cd590
54e25ee3d04903ad3eef1e6bdf1fd5a719f91f9b
25279 F20110115_AABXGU onbilger_o_Page_124thm.jpg
817b1ec762de3647e6a9b7ffbaf96aea
c94366f4da1792f452e46da1463a89cd875c2d88
86712 F20110115_AABVYM onbilger_o_Page_102.jp2
478cadac90326035801801bea7f27385
b89e6e95dacdeb10d627d12540428f1b9203ff20
2082 F20110115_AABVXX onbilger_o_Page_104.txt
c0ab81f103eee4494b27b91e961538eb
78115d0a9c08aa86bab287f80ac10082c0e17f2e
25561 F20110115_AABWEG onbilger_o_Page_022thm.jpg
f1e72373080a61fdbe8e3026cc2d33ea
cdde0d8e61c39cd7cdf28603dfd1c589124b5f11
106659 F20110115_AABVZA onbilger_o_Page_131.jp2
761361fd1c0b00c3f11be3a4144f44eb
941438e3c88c16e4798171e485fc436ee1112c92
F20110115_AABWDS onbilger_o_Page_068.tif
d0a5059e6b32d27095546664678658a1
6b4067a3418766bd23b37eabe3cac6024b38eb5a
11220 F20110115_AABXHJ onbilger_o_Page_095thm.jpg
8742cc9601c9cad5e96f39630302cb6a
1fa9faeb939b29e49caa691817355bbdd7828e74
22375 F20110115_AABXGV onbilger_o_Page_085thm.jpg
c8ed6d979d52502947f2e2fbc15d2212
e15d3c8e50b8687541b648fe3b481ca188a5b2a3
52443 F20110115_AABVYN onbilger_o_Page_089.pro
35f0bd7df21ad49ec67ffe693bf0fef6
6459aac42a48f202a8b8ee6f2221f37d15da2747
1978 F20110115_AABVXY onbilger_o_Page_120.txt
a2bca6bd83283183381ba6bf14f378ea
5db5f56a84aebd34deb2091c3f15dd62cab6246a
272926 F20110115_AABWEH onbilger_o_Page_162.jpg
205e9d654478193c80ac037a4a4ff0af
9bc56a0a9b5bdd6e62372668bd8e4317a3427bed
65205 F20110115_AABVZB onbilger_o_Page_019.QC.jpg
051b73d19b9cc4942cab7fc62081786c
6d00eaa60f4b31bebe85f5d04b0149192fa4dc84
73039 F20110115_AABWDT onbilger_o_Page_029.QC.jpg
a6e8d0253467a6114900c6a8900238ac
dfd3045f59b1788257dedac967bc71e4bcbda880
54301 F20110115_AABXHK onbilger_o_Page_011.QC.jpg
58546c7befd66115c14b1f5143e57eb6
7738e74e175f43262c96ba75669b3c94102e19b5
55615 F20110115_AABXGW onbilger_o_Page_083.QC.jpg
c7ed0d83e6e0a4ef3e8919142aca5697
e2c72360feb3ef052bb167592d1d30fda4600e98
105329 F20110115_AABVXZ onbilger_o_Page_088.jp2
5ae770ad345d360b190658327d85c98e
b87f66b01cb0fe94852a1ae2fef661e2d5d0ee95
80561 F20110115_AABWEI onbilger_o_Page_069.QC.jpg
3c039bf58ef163a44467f659ea5cbce9
454f28cd2b0cd01a8ac3b82b3409175e56b03a06
111386 F20110115_AABVZC onbilger_o_Page_034.jp2
e1b82020eb666508c9bbdb4992948f3e
709aecb3b09d4dc8bc556356839410b62d577086
82872 F20110115_AABWDU onbilger_o_Page_165.QC.jpg
9c722695cbd9864a4a1f0f912bd3b6c6
422efb011112d151a6cbe9e2db92c517e234d58e
13361 F20110115_AABXHL onbilger_o_Page_103thm.jpg
f8eac406409007906a8826a731624449
dfe3033cd2c0626f95e8c598a6f1b635b88963dd
22713 F20110115_AABXGX onbilger_o_Page_136thm.jpg
1e47820c4c28c4b5fe412b2ecbadf7c2
48c415f56f7621f781a5a716adfb5ebb5d167cdf
47208 F20110115_AABVYO onbilger_o_Page_021.pro
9c51983f4691ebf1186b989b824092b8
54bef947b7cf8167c3c048f1e96ab00d78b70c5a
1566 F20110115_AABWEJ onbilger_o_Page_024.txt
bf75df6d36719c3eb66e283163f0be97
10ab98f552314cd60552d691b23f3342652a9b08
49196 F20110115_AABVZD onbilger_o_Page_101.pro
0a69857007c115ee97e307cfc937aa45
eb3b6a730cf49313d01b8b4c8e9b3baaf09cc38b
23412 F20110115_AABWDV onbilger_o_Page_044thm.jpg
0a528e5366ce9ce49e643346ec778a36
62b2b761feb9d9389ae24e74e8c22f9fccf8506f
24214 F20110115_AABXIA onbilger_o_Page_025thm.jpg
5da793f31aac8876ad6db591a66e98e7
a102ae929813a5f7f6c625090f9829795cf0ee8e
17574 F20110115_AABXHM onbilger_o_Page_012thm.jpg
6eb492a760c075c6211e674557c2b0be
f8525426673c70f7102f000e830517be607f8de6
25337 F20110115_AABXGY onbilger_o_Page_153thm.jpg
402ba4c394a014c15681baf8f08ee314
26c95991b898626d2911a32a61aff464027919e5
52951 F20110115_AABVYP onbilger_o_Page_143.pro
f6f1766eabf23c9e1ce983fce45a55f1
1fa6c8d9d9eb473e86a0e2facb2cb38039b050a7
1784 F20110115_AABWEK onbilger_o_Page_103.txt
33124fa4026ed83ea1eb425a63dd7cc6
c9f3151eabe44ed19a44de219ab566bb5f46bf0e
38568 F20110115_AABVZE onbilger_o_Page_151thm.jpg
7b7d52cd666906bf574fe0fa7250dd1b
b92f6139b7d9c5fe6d9f5b886b20473c7c4230d8
165695 F20110115_AABWDW onbilger_o_Page_056.jpg
ec5e16d18173ff5dd16eea6d7b844c36
98f5de9fa4a837bf34956b950229cc8a7f5761c7
24063 F20110115_AABXIB onbilger_o_Page_038thm.jpg
8aeb3869bcdcab1778319327207af5f3
5bd2bcdde804574c03955d5815140cc71e08127c
25105 F20110115_AABXHN onbilger_o_Page_014thm.jpg
2f2858c794d832179f0198b90a146881
e51fc3aa8e1c94959aae725937e6225c1b7ca39a
2867 F20110115_AABXGZ onbilger_o_Page_003thm.jpg
73ef1b33586813b4a34331fecc1350fe
52a5b5f42e5b57784f9309b242d617f2d1dc7fe9
210313 F20110115_AABVYQ onbilger_o_Page_122.jpg
b0451f0b13fac17b39f21450a5233155
ed491944b95db460148bc783184968e9c3394a0c
47010 F20110115_AABWEL onbilger_o_Page_116.pro
241b42ca9a53c72791b5db488d26663e
fc0cb67666278a5c2f468e7a10dd99295bdff17c
190147 F20110115_AABVZF onbilger_o_Page_144.jpg
993b9c93512cb2db335170b068309ce2
89b0d194f2018ed304fb241dd64243ef3b18d4cf
143052 F20110115_AABWDX onbilger_o_Page_054.jpg
8c93536aa699a79919c2a934b77609a7
5ffa52f2cede73235148cec78aa387775e551c57
78241 F20110115_AABXIC onbilger_o_Page_027.QC.jpg
651c9010a2c7548dd43fd114ee21ee93
cd58f0874cc012d7f9375c2d812deb5179654d74
24164 F20110115_AABXHO onbilger_o_Page_126thm.jpg
6d696d72d462ae78c6ca898b12f5729e
d8da908d312e23c51e1a6efaeb9ef950e1e5a940
76091 F20110115_AABWFA onbilger_o_Page_114.QC.jpg
f1f8796b25aa5f6375019f1421ca366e
6236dcc1b58f20034539e8213a1ca15ddc245892
219512 F20110115_AABWEM onbilger_o_Page_147.jpg
a991204998f2cdec64ee78140f65e525
1c6094b17b1b3bb454fc82331a3ac0b251b98a85
64695 F20110115_AABVZG onbilger_o_Page_125.QC.jpg
d35b79aef96828f3786666e7c3df18cc
7a5bd931241f2e6a81f06b242187445a79bb38d3
139054 F20110115_AABVYR onbilger_o_Page_157.jp2
d6ca7c14b7637ceb60044ea3fcbf7268
2820d60f8815f1e1b37ac73684e1bb9910445e20
98160 F20110115_AABXID onbilger_o_Page_009.QC.jpg
df88a84f094e59e45b6e7756e6aeed0a
a04162da36633d9d24bd8028bad2911d8e2038da
21468 F20110115_AABXHP onbilger_o_Page_080thm.jpg
0619b2e49b3f6cc0667a2d8fc49d90ce
544349b1aa3a79417c9f8ac2091f606acd8a588b
48078 F20110115_AABWFB onbilger_o_Page_167.pro
de13abcc5cc2004b99bd65e5e06ccd48
c05d15e5a12e649568b4c1b03c02e0ded71bc7e4
19136 F20110115_AABWEN onbilger_o_Page_082thm.jpg
3626838dbf0d4b9ebea3ddd5963cfddb
3e9b2e397407a1102d6aef91e4b07b0ec9e809be
F20110115_AABVZH onbilger_o_Page_046.txt
da1a4cff4b78527adbd867327c989ff2
e31f3d243271bc6f968d4686cb099e0199e2fbbf
99994 F20110115_AABWDY onbilger_o_Page_133.jp2
4865b3e8d0bde0dd5bd69ecbe799b316
672b91969b02fcf8749a308d58438a832d40f741
103606 F20110115_AABVYS onbilger_o_Page_026.jp2
21eeb34ee96c5e461d9b21b205fd9d45
323e7389ac482e49f1986dc25804e3ad1d9a1ce1
23265 F20110115_AABXIE onbilger_o_Page_145thm.jpg
0490888e7982e8c8bbbb43a33cc5c58d
9c52f55ab66051113104816822491eaf9c26f8f4
23903 F20110115_AABXHQ onbilger_o_Page_015thm.jpg
36cab05495498d26864af4d057e80d12
1f9d8f4752489590d0933521fe41526629794a1f
20903 F20110115_AABWFC onbilger_o_Page_151.pro
c70eaa73fb63892f08b865430a6f3ad5
346fb5ea8db1141bdd37de8960653c8105b192cd
72871 F20110115_AABWEO onbilger_o_Page_059.QC.jpg
dc7cc904058e48b78f4f2d72c85044a7
414f391ed829335bdf65fcfa3ac9c8b7fe7bd80e
F20110115_AABVZI onbilger_o_Page_105.tif
3145ee1e8667f36b2e495fdad37f6052
a248d2d96cfd8e4d5466f76ef25f28604c18bab5
F20110115_AABWDZ onbilger_o_Page_097.tif
9d9ed7ed077df665a315fc376bc442d2
a585a216e445148add6d3c8c35c32cfa7a600ec9
194266 F20110115_AABVYT onbilger_o_Page_097.jpg
1bea14c1cbb3c8a80dd718359917a0a8
0568f3d17b6e908ab38d5279ae06ebd9d3797a64



PAGE 1

A COMPUTATION PARADIGM FOR MULTIPLE MOBILE AGENT SYSTEMS By OGUZ KAAN ONBILGER A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2004

PAGE 2

Copyright 2004 by Oguz Kaan Onbilger

PAGE 3

To my unborn son Alpkan

PAGE 4

ACKNOWLEDGMENTS I would like to express my gratitude to my advisor, Dr. Randy Chow, for his guidance and support, which made this study possible and for sharing his wisdom with me. I also would like to thank my co-advisor, Dr. Richard Newman, for fruitful suggestions, and sharing his intelligence and experience. I thank both of my advisors for patiently listening to my presentations during the weekly group meetings and providing their guidance. I also would like to thank my committee members, Dr. Jih-Kwon Peir, Dr. Abdelsalam Helal and Dr. Suleyman Tufekci, for their efforts and brainstorming to make it clear what I was trying to do and their helpful comments and suggestions. Special thanks go to Dr. Shigang Chen for providing the network simulation software he developed and his collaboration and discussions. Thanks go again to Dr. Randy Chow for encouraging this collaboration. Very special thanks go to my parents for their continual emotional support from thousands of miles away. Finally, I express my gratitude to my beloved wife, Derya, for her constant love, encouragement, patience, and support through difficult times. Without her, this study would never have been completed. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS .................................................................................................iv LIST OF TABLES ...........................................................................................................viii LIST OF FIGURES ...........................................................................................................ix ABSTRACT .......................................................................................................................xi CHAPTER 1 INTRODUCTION........................................................................................................1 2 BACKGROUND..........................................................................................................7 2.1 Software Agents and Multi-Agent Systems...........................................................7 2.2 The Mobile Code Concept......................................................................................9 2.3 The Mobile Agent Paradigm................................................................................11 2.3.1 Applications of Mobile Agents..................................................................13 2.3.2 Mobile Agent Systems...............................................................................15 2.3.3 What Mobile Agents Offer.........................................................................19 2.3.4 Drawbacks of the Mobile Agent Paradigm................................................22 2.4 Security Problem of Mobile Agents.....................................................................23 2.4.1 Malicious Agents Problem.........................................................................25 2.4.1.1 General protection mechanisms against possibly malicious mobile code.........................................................................................................25 2.4.1.2 Specific protection mechanisms against possibly malicious agents27 2.4.2 Malicious Hosts Problem...........................................................................29 3 MULTIPLE COOPERATING MOBILE AGENTS..................................................35 3.1 Introduction...........................................................................................................35 3.2 Requirements and Objectives...............................................................................37 3.3 Definitions............................................................................................................40 3.4 Mission Models....................................................................................................41 3.5 Multi-agent Systems (MAS) vs. Multiple Mobile Agent Systems (MMAS).......44 3.6 Proposed Architecture for MMASs......................................................................45 3.7 Example Missions.................................................................................................48 3.8 Related Work........................................................................................................52 v

PAGE 6

4 REMOTE DIGITAL SIGNING WITH MOBILE AGENTS.....................................54 4.1 Introduction...........................................................................................................54 4.2 Electronic Commerce and Mobile Agents............................................................54 4.3 Mobile Commerce and Mobile Agents.................................................................55 4.4 Mobile Agent Security in Mobile Commerce......................................................55 4.5 Objectives.............................................................................................................57 4.6 Background...........................................................................................................58 4.7 Multiple Cryptography.........................................................................................61 4.8 Key Splitting and Signature Generation...............................................................63 4.8.1 Using the Multiplicative Property of RSA.................................................64 4.8.2 Using the Additive Property of RSA..........................................................65 4.8.3 Using El Gamal Public Key Cryptosystem................................................66 4.8.3.1 Signing in sequence with El Gamal signature scheme.....................67 4.8.3.2 Signing in parallel with El Gamal signature scheme.......................69 4.8.3.3 Transition from El Gamal cryptosystem to digital signature algorithm.................................................................................................70 4.9 The Overall System for Remote Digital Signing..................................................71 4.10 Using Limited-liability Keys and Public Key Certificates.................................74 4.11 Practical Issues of Remote Digital Signing........................................................78 4.11.1 Probabilistic Signature Scheme and its Impact on Practice.....................79 4.11.2 Performance Considerations and the Big Picture.....................................80 5 A NETWORK POSITIONING ARCHITECTURE FOR MOBILE AGENTS.........84 5.1 Introduction...........................................................................................................84 5.2 Related Work........................................................................................................85 5.3 TPNP Approach....................................................................................................88 5.3.1 The Algorithm............................................................................................90 5.3.2 Starting the System.....................................................................................95 5.3.3 Scalability Issues........................................................................................96 5.3.4 Security Considerations..............................................................................97 5.4 Experimental Evaluation......................................................................................97 5.4.1 Simulation Environment.............................................................................98 5.4.2 Simulation Parameters................................................................................99 5.4.3 Simulation Strategy....................................................................................99 5.4.4 Simulation Results and Analysis..............................................................100 5.5 Conclusion..........................................................................................................104 6 QUANTITATIVE ANALYSIS OF MULTIPLE MOBILE AGENT SYSTEMS...106 6.1 Introduction.........................................................................................................106 6.2 Network-awareness in Mobile Agent Computing..............................................107 6.3 The Traveling Salesperson Problem...................................................................108 6.4 Application of TPNP and TSP to Classical MA Model.....................................111 6.4.1 The Data Structure....................................................................................111 6.4.2 The Heuristics...........................................................................................112 vi

PAGE 7

6.5 Experimental Evaluation....................................................................................113 6.5.1 Simulation Environment and Parameters.................................................113 6.5.2 Simulation Strategy..................................................................................114 6.5.3 Results and Analysis.................................................................................114 6.6 Context-awareness in MA Computing...............................................................120 6.7 Multiple Cooperating Mobile Agents Model.....................................................122 6.7.1 Trust Model..............................................................................................122 6.7.2 Performance Model..................................................................................124 6.8 Application of TPNP to Multiple Cooperating MAs..........................................126 6.8.1 Problem Formalization.............................................................................128 6.8.2 Heuristics for MATAP.............................................................................131 6.8.3 Experimental Evaluation..........................................................................132 6.8.3.1 Simulation parameters....................................................................132 6.8.3.2 Simulation strategy.........................................................................133 6.8.3.3 Results and analysis.......................................................................133 6.9 Related Work......................................................................................................140 6.10 Conclusion and Future Work............................................................................142 7 SUMMARY AND FUTURE DIRECTIONS...........................................................144 REFERENCES................................................................................................................147 BIOGRAPHICAL SKETCH...........................................................................................156 vii

PAGE 8

LIST OF TABLES Table page 3-1. Comparison of MAS and MMAS...............................................................................44 6-1. Application of NN heuristic with TPNP...................................................................118 6-2. Application of RA heuristic with TPNP...................................................................118 6-3. Application of FRP heuristic with TPNP.................................................................118 6-4. Simulation parameters..............................................................................................133 viii

PAGE 9

LIST OF FIGURES Figure page 2-1. Mobile agent execution model...................................................................................12 2-2. Mobile agent execution platform................................................................................16 3-1. Mobile client/server model.........................................................................................42 3-2. Multiple mobile agents model with two mobile agents..............................................43 3-3. Multiple mobile agent system architecture.................................................................46 4-1. A snapshot of a mission using multiple mobile agents..............................................67 4-2. Protocol for sequential signing with multi-agent model............................................72 4-3. Protocol for parallel signing with multi-agent model.................................................73 4-4. Limited-liability key protocol.....................................................................................77 5-1. Global network positioning model (GNP)..................................................................86 5-2. Local network positioning model (TPNP)..................................................................88 5-3. Discovery algorithm...................................................................................................91 5-4. Selection algorithm.....................................................................................................92 5-5. Distance measurement protocol..................................................................................93 5-6. Average relative error...............................................................................................101 5-7. Average local relative error......................................................................................102 5-8. Average outliers relative error..................................................................................102 5-9. Distribution of average relative error to path latencies............................................103 6-1. Performance of 2-Opted TSP heuristics across the problem size.............................115 6-2. Performance of 2-Opted TSP heuristics across the number of TPNP dimensions...116 ix

PAGE 10

6-3. Illustration of MATAP.............................................................................................127 6-4. Mission communication time across problem size...................................................135 6-5. Mission communication time across security level category...................................136 6-6. Mission communication time across random selection distribution over security levels.......................................................................................................................137 6-7. Effect of transmission rates on mission communication time..................................138 6-8. Heuristic performance with the available SA hosts in the network.........................139 6-9. Heuristic performance with the number of clusters..................................................140 x

PAGE 11

Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy A COMPUTATION PARADIGM FOR MULTIPLE MOBILE AGENT SYSTEMS By Oguz Kaan Onbilger December 2004 Chair: Randy Chow Cochair: Richard Newman Major Department: Computer and Information Science and Engineering Mobile agent (MA) systems have been proposed as a potentially useful computing paradigm for distributed applications. An MA is an autonomous computing entity, which migrates from one host to another carrying its code/data/state information, to accomplish a task on behalf of its owner. The concept is attractive since mobility of the agent brings execution closer to the remote resources resulting in a great reduction of communication overhead, and the autonomy property of the agent relieves the attention of the initiating owner, rendering more concurrency for the applications. The primary hindrance that prevents MA systems from wider acceptance is the concern of MA security. Protection of agents from malicious hosts is considered a difficult problem. Our goals are to prove that sufficient degree of agent security can be achieved to make MA systems a reality, and to propose prototype architecture for secure multiple MA systems. xi

PAGE 12

Our approach relies on the assumption that security can be enhanced through the use of multiple collaborating MAs. We conjecture that security can be strengthened through protection as a whole meaning that attacks to some of the agents cannot corrupt the entire group of agents performing collaboratively on a common task. One of the problems tackled in this research is the requirement of the ability to compute with secrets in a public domain. Our research focuses on a special case of this problem, i.e., remote digital signing with multiple agents. Multiple collaborating MAs are a natural extension (with mobility) of the research on multi-agent systems in artificial intelligence. Central to the design of mobile systems is the ability to track the locations of migrating agents. In our proposed multiple MA system, agents need contextual information based on location to optimize their traveling itineraries. We propose a general coordinate-based peer-to-peer network-positioning scheme for the system. The design of such a location service opens up many new and interesting variations of the classical traveling salesperson problem. The location service is used in a simulation tool for analyzing the performance and communication overhead of the MA-based network. xii

PAGE 13

CHAPTER 1 INTRODUCTION The concept of software agents is a natural extension of the notion of processes in traditional operating systems. In the context of distributed systems, software agents are autonomous processes deployed at various sites to perform some specific functions or tasks. When collaborations among these agents are needed, they form a Multiple Agent System (MAS) to achieve a common goal. The design issues on MASs generally fall into two complementary research areas, distributed systems and artificial intelligence. The distributed systems research community is concerned with the system supports for the agent technologies such as synchronization and communication of interacting agents, while in the AI community, the focus is more on the intelligence and decision support of the cooperating agents. This research adds another dimension, mobility, to the multiple agent systems we term, Multiple Mobile Agent Systems (MMAS). In such a MMAS, mobile agents exhibit strong mobility in that they need and are allowed to dynamically migrate from host to host carrying with them their code/data/state information to accomplish their missions. The concept of code migration or mobile code is not new. Most Internet users have experienced its impacts in both positive and negative ways. On the positive side, we have enjoyed downloaded programs such as Java applets in web browsers for all kinds of operations ranging from banking transactions to animating cartoon characters. This aspect of mobile code technology helps to realize the important goals of transparency and efficiency in distributed systems. On the negative side, we have seen numerous malicious 1

PAGE 14

2 uses of the technology in the forms of viruses and worms that disrupt our daily computer operations. Similarly, Java servlets, which are the server counterpart of applets, have become commonplace for many Internet applications. Like applets, their code migration is static, meaning that codes are uploaded to servers, run there and cease their existence. The emerging mobile agent technology takes the applet and servlet concepts one step further to allow dynamic and continuous migration of the agent processes autonomously. Mobile agents have been proposed and used in some limited application domains such as e-commerce, information retrieval, network management, software distribution, distance education, and even as a security mechanism for intrusion detection. It has been argued that using mobile agents as a programming paradigm is a perfect fit for distributed systems since the autonomous characteristics and mobility of agents facilitate naturally the implementation of asynchronous and dynamic interaction of concurrent execution in distributed applications. More precisely, the mobility of agents brings execution closer to the remote resources resulting in great reduction of communication overhead, and the autonomy property of agents relieves the attention of the initiating agent owners rendering more concurrency for the applications. However, the concept has received much skepticism until the current millennium, out of concern that interoperability and security might not be justified if agents are to roam freely in an open and large-scale network. This research addresses the security issue of mobile agents. In particular, it claims that utilizing multiple collaborating mobile agents can actually enhance the security of the applications. There are two separate categories of threats in mobile agent security, malicious agents and malicious hosts. Protection of hosts against malicious agents is well

PAGE 15

3 understood and has been implemented at least in some degree in most systems. Common solution approaches to the problem are host hardening and agent containment such as the built-in security mechanisms for byte-code execution in Java language and virtual machine. The protection of mobile agents against malicious hosts, however, is less intuitive. First, the assumption that a user would send its agent processes to untrustworthy hosts is less conventional. Second, the secrecy and integrity of the agents and the need to execute the code in public might conflict with each other at times. Total agent protection is considered unsolvable without special hardware by some researchers. The main difficulty comes not only from agent mobility but also autonomy. Especially, their ability to migrate from one host to another poses vulnerabilities, which could easily be exploited by the very host platforms they execute on. This dissertation focuses on the problem of protecting mobile agents against malicious hosts. There are threats to mobile agents which lead to very simple attacks that could be devised: denial-of-service and replay attacks. A host platform which receives an agent may simply not execute the agent at its own discretion, which leads to denial of service. Similarly, a host platform can reuse the agent by using the credentials delegated to it by its owner (i.e., user) to masquerade the original host and user, which leads to replay attacks. These two types of attacks are not properly addressed by the known or proposed mechanisms. A complete description of attacks possible against mobile agents and a background information about proposed solutions and their classification are given in Chapter 2. We have identified several requirements for a solution for the malicious hosts problem. These are summarized as follows:

PAGE 16

4 1. A solution proposed to protect hosts from possibly malicious hosts should not jeopardize the protection of hosts from agents, 2. The second important requirement is that solutions should not limit the potential benefits of mobile agents, 3. It is vital to address easier attacks against mobile agents, which are denial-of-service and replay, 4. The concept of the network trusted computing base needs to be extended to be applications and case specific. Details of these requirements are provided in Chapter 3. The theme of this dissertation is to address the protection of mobile agents from possibly malicious behavior of host platforms by keeping in mind the requirements pointed out above. The proposed technique is based on an autonomous group of multiple agents designed to accomplish a single well-defined task, which in turn relies on the concept of information dispersal for security. Information dispersal is not a new concept. Both cryptographic and non-cryptographic means of protection via the technique have been proposed and implemented. Cryptographic mechanisms are mostly related with key sharing and threshold cryptography. Non-cryptographic means are directly applied on data to be protected. For example, sensitive information is split up and distributed to several hosts connected with a computer network. Penetration to one or some of the hosts would not reveal the information, and intrusion to several hosts is considered more difficult than intrusion into a single host. Similarly, sensitive information carried by mobile agents (this may also include the code) can be split up and given to multiple agents. Therefore a successful attack against the group of agents is more difficult than attacking a single agent. Agents in the group should be located on different hosts, and furthermore on different administrative domains. Agents in the group should

PAGE 17

5 communicate and cooperate to accomplish the task given. Therefore, tampering with one of the agents could be detected by the others in the group. The feasibility of the described approach however does not only depend on information dispersal. To apply the concept into dynamic mobile agents, we first need to figure out how to position multiple mobile agents, specifically how to find the hosts to locate the agents in a feasible manner. This opens up very interesting research issues including making mobile agent systems aware of the underlying network topology. While we are focusing on one specific application of information dispersal in Chapter 3, our focus in Chapter 4 is on the network positioning models to be able to apply information dispersal into multiple mobile agents in an open internetwork environment. This dissertation is organized as follows. In Chapter 2, we provide a brief description about software agents and multi-agent systems, mobile code concept and its applications, mobile agents, their benefits and drawbacks. Then we provide background information about mobile agent security from both perspectives described above and proposed solutions and their categories in more detail. In Chapter 3, we explain the concept of group of multiple cooperating agents for security. We provide models applicable to this concept and our proposed model. We define the mission concept and model and distinguish this concept from the multi-agent systems. The proposed multiple mobile agent system architecture is also introduced. Chapter 3 is the foundation for the rest of this dissertation. In Chapter 4, we address the remote digital signing problem of mobile agents. For the mobile agent paradigm to be widely accepted and used, one must demonstrate that

PAGE 18

6 mobile agents are capable of performing computations that are possible with the client/server model. Digitally signing a contract is one such computation in e-commerce applications that needs to be performed by mobile agents. We demonstrate that it is feasible to perform this computation with multiple cooperating agents using the information dispersal for security concept, as presented in Chapter 3. In Chapter 5, we examine the network distance measurement approaches and propose a general, highly scalable coordinate-based peer-to-peer network-positioning scheme, one that fits better to the requirements of the mobile agent systems. By using a simulation tool, we analyze and demonstrate the achieved accuracy of the approach. In Chapter 6, we apply the network positioning system proposed in Chapter 5 together with traveling salesperson problem heuristics to traditional mobile agent computing and multiple mobile agent systems. We are looking for the answers to the questions about whether we can alleviate the performance problem of multiple mobile agent systems and if we can do it efficiently without canceling out the performance benefit achieved. This chapter also deals with networkand context-awareness in mobile agent systems. Finally, Chapter 7 summarizes our work and provides future research directions.

PAGE 19

CHAPTER 2 BACKGROUND Mobile agent paradigm has two descendants: software agents and mobile code. Mobile agents are software agents with the added feature of mobility. On the other hand what makes them mobile is the general concept of mobile code. So, mobile agents combine these two unrelated concepts, and become a unique technology in distributed systems. In this chapter we provide a brief outline of software agents in general and then have a look at the mobile code concept and its applications. The rest of the chapter is dedicated to mobile agents, their applications, systems, standards, pros and cons. A detailed survey of the security problem of this technology and the proposed solutions ends the chapter. 2.1 Software Agents and Multi-Agent Systems Software agents are an active research area in Artificial Intelligence (AI) and distributed computing systems. In this section we use the term software agent to refer to software entities that are subject to research in these two fields, in general. So, autonomous agents, intelligent agents, interface agents, virtual agents, information agents, and mobile agents are all software agents. The difficulty with the definition of an agent in the AI community is to distinguish a software agent from a software program (Franklin & Gaesser, 1997). Bradshaw (1997, pp. 7) cites the definition given by Shoham (1997), with the hope that it might be acceptable to most researchers: A software entity which functions continuously and autonomously in a particular environment, often inhabited by other agents and 7

PAGE 20

8 processes. Murch and Johnson (1998, pp. 16) provide a survey of definitions and as a result they conclude that agents are, by consensus, autonomous, goal seeking, persistent, reasoning, productive, and communicative. So, it seems like characterization of agents makes more sense than giving an exact definition. Bradshaw (1997, pp. 8) shares the same point and as the result of his own survey concludes that consistent with the requirements of a particular problem, each agent might possess to a greater or lesser degree attributes like the ones: reactivity, autonomy, collaborative behavior, communication ability, inferential capability, temporal continuity, personality, adaptivity, and mobility. From the distributed computing systems perspective, however, our focus is on mobile agents, which is a specialization of generic software agents with the added ability of mobility. The details on mobile agents are given in Section 2.3. A precise description of multi-agent systems is given by dInverno and Luck (2001, pp. 6): Multi-agent systems are typically distributed systems in which several distinct components, each of which is an independent problem-solving agent come together to form some coherent whole. There is generally no pre-established architecture or configuration incorporating the agents, and the interactions between them are not pre-defined, as is usually the case with traditional processes in concurrent programs. More importantly, there is no global system goal, the agents being heterogeneous with their own goals and capabilities. In consequence, agents in a multi-agent system need to coordinate their activities and cooperate with each other, in order to avoid duplication of effort, to avoid unwittingly hindering other agents in achieving goals, and to exploit other agents capabilities. What is not clearly specified in the above description is that owner or users of the agents participating in a multi-agent system may be different parties.

PAGE 21

9 It is necessary to distinguish the multi-agent systems and the multiple-agent model we use in our research for better understanding. This distinction is made clear in Chapter 3 where we define multiple cooperating agents concept. 2.2 The Mobile Code Concept The mobile code concept may be best understood by examining the applications. In the following we provide brief descriptions of mobile code applications. In traditional distributed computing systems, applications are built on the client/server paradigm. Usually, the client process sends a request to the server process over the network. The server processes the request and returns the result to the client. The communication between the clients and servers are handled through message passing or Remote Procedure Calls (RPC). This is a synchronous process in the sense that clients usually block after sending the request until the reply arrives or a certain timeout is observed. Although asynchronous RPC changes the classical synchronous communication nature of the client/server model, the request/reply scheme remains the same. The mobile code concept however makes a paradigm shift in distributed computing. In contrast to the request/reply scheme, in mobile code systems, not only the data but also the code to be executed is exchanged between the applications. Remote evaluation has been first proposed by Stamos and Gifford (1990). In this scheme, code to be executed is sent to the remote machine. The result of execution is sent back as data only. As is true for other resources, processor cycles can also be shared in distributed systems. The mechanism necessary for sharing such a static component requires code migration in the form of processes, which is known as process migration. The first

PAGE 22

10 objective of process migration in distributed systems is to redistribute load and improving performance by migrating processes from node to node. The secondary objective is to achieve location and performance transparencies by distributed process scheduling (Chow & Johnson, 1997). Perhaps the most well-known mobile code mechanism that is widely used today is Java applets. An applet is a Java object that is associated with a web page. When the page is requested by a client browser, applet is downloaded into the client machine along with the web page and executed in the Java Virtual Machine installed on the same machine. Applets are static in the sense that they cannot move anywhere other than the client machine, Moreover, their communication to the outside world is restricted to the originating server machine due to security concerns. The server counterpart of applets is an object known as a servlet in Java. So, servlets are uploaded from the client to the server to make the server functionality customized according to the specific requirements of the client. Code migration, therefore, follows the opposite path of an applet. Servlets are widely used today by the web servers, which are implemented in Java. However, servlets in use today are created and used by the server host, mostly due to the security concerns. Therefore, the capability of code migration, which was explained above, is not used. Java applets and servlets are said to be examples of code-on-demand paradigm (Lange & Oshima, 1998). Active networks are an active research area employing the mobile code concept (Hartman et al., 1996; Tennenhouse et al., 1997; Tennenhouse & Wetherall, 1996). The area has its roots in the SOFTNET project, which is a multihop packet radio network developed in the 1980s (Zander & Forchheimer, 1988). In active networks, specialized

PAGE 23

11 packets, which are called capsules (Tennenhouse & Wetherall, 1996), carry not only data but also code. The code is injected into the nodes along the route of the capsule. Subsequent packets which are related to the original capsule trigger the execution of the code previously stored in the nodes. The result is that the routers of the network and therefore the network itself are programmed by its users. Immediate advantages of the described scheme are that customized computation for individual applications can be carried out inside the network and new network protocols can be installed on the routers easily, on-the-fly. 2.3 The Mobile Agent Paradigm Mobile agents (MAs) are an approach to distributed computing employing the mobile code concept. MAs are autonomous entities, which are composed of code, data and state information. They visit hosts (e.g., servers) possibly using an itinerary, perform some execution on those hosts using their codes and migrate with their state information from host to host. As in the case with stationary agents, they act on behalf of their owners (e.g., senders). They are autonomous in the sense that they have all the knowledge needed to perform the assigned task on behalf of their owners. The traditional mobile agent execution model is illustrated in Figure 2-1. The mobile agent is launched from the originating platform by the owner. It visits the hosts to accomplish its task and return to the owner. The most important difference between the MA paradigm and the other mobile code systems is the strong mobility of MAs. None of the mobile code systems and mechanisms except the process migration mentioned in the previous section has the strong mobility feature. This means that the execution state of the transmitted mobile code is not carried. Therefore, the code (e.g., program, procedure or method) starts

PAGE 24

12 execution from the beginning and terminates at a certain point. In the case of mobile agents, execution stops but not terminates and resumes at the next platform, where the mobile agent migrates. HostHostHostHostAgent Owners Host Agent Agent Agent Agent Agent Agent Agent Agent Agent Agent Figure 2-1. Mobile agent execution model Migrating processes are not allowed to choose where and when to migrate in contrast to mobile agents. While processes are migrated to balance the load transparently, mobile agents autonomously migrate to hosts where the information or services are of interest. Another difference between the two is that processes in general can migrate among homogeneous environments whereas mobile agents are designed to run on the middleware, which makes them platform (machine and operating system) independent. Active network architecture is mainly proposed for network level tasks, although application level customization is also possible. Mobile agents, in contrast, are mostly to be used at the application level. While the target hosts are the network routers in the former, target of mobile agents can be any host. One last distinguishing feature is that mobile agents have execution state, whereas an active capsule has no such state. However, active networks and mobile agent systems are not mutually exclusive. Active

PAGE 25

13 network architectures and models, which employ mobile agents, have been proposed (Breugst & Magedanz, 1998; Busse et al., 1999). 2.3.1 Applications of Mobile Agents Mobile agents have been proposed to be useful in a wide range of applications. We classify these applications in the following and give a brief insight about the application areas. E-commerce, m-commerce. Among many application areas of MAs, e-commerce draws the most attention from both academic and industrial researchers (Busch et al., 1998; Marques et al., 1999; Klusch, 1999; Roth, 2000; Sandholm, 2000). This is mostly due to the fact that, MAs and in general agent systems have the capability of representing users (i.e., customers) in the electronic marketplaces. Agents can effectively profile user preferences, act on behalf their owners, participate in e-auctions, watch stock prices, search for commodities and find the best offer from competing vendors, purchase goods by paying and committing to transactions, communicate and cooperate with other agents of relevant goals. Network management. Code mobility in the form of mobile agents has been proposed by many researchers as a promising technology in network management. Some examples are Baldi, & Picco, 1998, Papavassiliou et al. 2002, and Meer et al., 2000. Baldi and Picco (1998) model network management activities using client/server model, remote evaluation and mobile agents and summarize advantages of using mobile code in network applications as semantic compression of information, a higher abstraction level to the network manager and autonomy of management agents. Information retrieval. The information retrieval problem is getting more difficult everyday on the Internet due to the amount of information available to the users. Mobile

PAGE 26

14 agents can search, filter and retrieve vast amount of information locally. Therefore information retrieval has become one of the most important and popular application areas of the mobile agent paradigm. Brewington et al. (1999) provides a qualitative and quantitative analysis of the use of mobile agents in information retrieval applications. Johansen (1998) discusses pros and cons of mobile agents in different application areas and provides quantitative analysis of real applications. One of these applications is StormCast where several servers receive weather data from meteorological censors. Users in turn, by sending their mobile agents can learn about the weather conditions in their area, and even set alarm conditions which are watched by their agents. Agents react by notifying the their users when the condition is occurred. Software distribution. Mobile agents are capable of customizing server side functionality by moving the client specific code to the server and this capability is one of most important benefits of the mobile agent paradigm. This concept therefore can even be used to deliver software for permanent use of server and client computers. Using this push model, subscribed code consumers may enjoy immediate software installation and updates. In fact, active networks are a good example of using mobile code in the form of specialized packets to install new protocols to the network routers, on-the-fly. An example of software update application using mobile agents is given by Bettini et al. (2002). Other application areas. Other example specific application areas are distant/remote education (Jamwal & Iyer, 2003), and vehicular traffic management (Schill et al., 1998). Mobile agents have also been proposed as alternatives to provide

PAGE 27

15 security in distributed systems. An example is intrusion detection systems, which utilize mobile agents (Jansen et al., 2000). 2.3.2 Mobile Agent Systems Informally a mobile agent system is a middleware where mobile agents live. This middleware typically sits on top of a runtime environment. The runtime environment is responsible for running the mobile agents and in some cases also for the execution of the mobile agent system itself as in the case of Java systems. The instances of these middleware systems, which run on hosts are known as places (Lange & Oshima, 1998) or platforms. We prefer the term platform. So, the mobile agents are created, executed and terminated in these platforms. When we say that mobile agents migrate between hosts, what we actually mean is that they migrate between the platforms, running on different hosts connected through a network. The mobile agent systems are responsible for all the operations of mobile agents. Creation, migration, communication with other systems and agents, cloning, security and termination are all handled by the underlying platform. Figure 2-2 illustrates the mobile agent system concept and relationships with the other components of a host, which employs a mobile agent platform. The runtime environment is typically a high-level language interpreter or Java virtual machine, since vast majority of mobile agent systems today are built using the Java programming language. Java has been the common ground for mobile agent systems, mostly due its standard, object-orientedness, support of mechanisms such as serialization and reflection, support of distributed objects as in RMI, and inherent security features. However, because different mobile agent systems themselves and mobile agents are implemented in the same programming language and executed by the same standard Java virtual machine

PAGE 28

16 does not mean that these systems would be interoperable. More details on interoperability problem are given in Section 2.3.4. OS JVM Mobile Agent Platform HOST ..... Agents migrationcommunication Figure 2-2. Mobile agent execution platform Today, there are more than fifty mobile agent systems. It is difficult to keep track of all the mobile agent systems exist today around the world. Some of the earlier ones ceased to exist as they become unsuccessful in the market or some of them have been experimental research systems. However, many new projects have been started to develop new systems which usually to overcome the deficiencies of the existing or previous systems. Kiniry and Zimmerman (1997) provide a survey of both commercial and research based Java mobile agent systems. Brewington et al. (1999) classify the systems as multiple language, Java based or others which are written mostly in script languages, and compare the systems. Lange and Oshima (1998) give a brief description of popular mobile agent systems. Karnik (1998) classify mobile agent system according to several

PAGE 29

17 criteria including the security features provided by these systems. We classify the mobile agent systems as in the following. Programming language used. Most of the latest mobile agent systems are developed in Java. Hence, mobile agents themselves are implemented in the same language. Earliest systems however have been written in scripting languages or interpreted bytecodes in other high level languages. Migration state carried by the agents. There are two different approaches for mobile agent migration. Within the first one control state of the mobile agent is captured and send to the target machine. The execution resumes in the target where it left off in the source machine. Within the second approach, the execution state of the mobile agent is not sent to the target machine. The programmer is responsible for the agent state and the execution state resume in the target host by referring to an entry point. The second approach makes it simpler to develop the underlying system but it may be a burden to the application programmer to capture the current state of the agents. But this is not really a problem because migration decision is made solely by the mobile agent itself by executing an instruction such as go. Since, migration is not forced by the underlying system, entry points can be easily specified using the data portion of the agent rather than the control state which includes the execution stack. This approach is taken by many of the Java based systems for interoperability since Java does not support inspection of the execution state of the objects due to security concerns. The former approach requires modifications to the JVM to capture the state and hence mobile agent systems and mobile agents developed using these systems can not run on standard JVMs.

PAGE 30

18 Multi-threading of mobile agent systems and mobile agents. Many Java mobile agent systems run the agents as a separate thread of the main process of the mobile agent platform. Others run agents in isolated processes and some of the systems use a combination of the two approaches. Ara is an example of the former approach whereas DAgents is for the latter. Communication primitives. Different mobile agent systems use different communication primitives among mobile agents. Some uses message passing, or RMI. Some systems require the agents to be present at the same platform, some other provide remote communications between sites. As examples, Aglets support sending and receiving messages in the form of objects, Ajanta supports RMI using proxies and DAgents use message passing. Security provided. This is perhaps the most important classification from our point of view. Unfortunately, vast majority of the mobile agent system have been developed without any security consideration at all. This is perhaps due to the fact that these systems are not intended for large scale, open systems or networks such as the Internet. In a company network or intranet, security may not be that important for mobile agent systems. Karnik (1998) makes the distinction among mobile agent systems in three categories: secure communication, server resource protection and agent protection. Secure communication is about whether the agent migration is protected using encryption and authentication. Server resource protection is usually associated with authorization of agents and access control mechanisms such as ACLs. Agent protection is related with the malicious hosts problem. Agents must be protected against any possible hostile behavior of hosts where they are executed. This is an open research area, which is the subject of

PAGE 31

19 this dissertation and only a limited number of agent systems support mechanisms within limited contexts. 2.3.3 What Mobile Agents Offer Lange and Oshima (1998) point out that mobile agents: 1. reduce the network load, 2. overcome network latency, 3. encapsulate protocols, 4. execute asynchronously and autonomously, 5. adapt dynamically, 6. are naturally heterogeneous, and 7. are robust and fault-tolerant. Gray et al. (1996) examines the benefits of mobile agents from the mobile computing perspective. They point out the capability of mobile agents which provides a powerful alternative for partially connected computing through mobile computers (i.e., laptops, personal digital assistants, etc.) and home computers, which have intermittent connections to the fixed networks. They also highlight how mobile agents simplifies the development, testing and deployment of distributed applications, and how it is possible to employ a scalable, peer-to-peer architecture for distributed applications instead of the rigid client/server model. Chess et al. (1995b) in their classical paper in the area collect fourteen claims, which have been given as the advantages of mobile agents over existing client/server paradigm (i.e., message passing, RPC, etc.) and they examine each claim in detail. They conclude that none of the claimed application areas could be uniquely addressed by the mobile agent paradigm (one exception might be the real-time applications which could be impaired with the network latencies between hosts that run client and server components of such a distributed application, especially in wide-area networks). For every application area, they could find an alternative that may well be addresses by the existing technologies. However, as the final conclusion they point out that mobile agent technology is unique in the sense that there is no alternative technology that could

PAGE 32

20 address all of the application areas and benefits together that can be offered easily by the mobile agents. Johansen (1998) shares their experiences of implementing and using mobile agents in real world applications using the Tacoma mobile agent system and also provides quantitative analysis of the performance aspects of mobile agents. He concludes that 1. agents are a convenient way to install client software at remote hosts, 2. their most successful application would be to build extensible servers, 3. the asynchronous nature of agents is important, 4. agents are shown to be a very convenient structuring technique for the distributed applications. We briefly summarize the benefits, which are offered by the mobile agent paradigm as follows. Mobile computing point of view. Mobile devices have limited battery life, and their intermittent connection to the wireline networks have low bandwidth, and high latency. Mobile agents overcome all these problems. They can be launched from mobile devices in a brief connection to the fixed network. Returning results to the users requires only another brief connection. During the computation the device can be disconnected from the network, and can even be turned off. Networking point of view. Mobile agents are capable of searching, analyzing and filtering huge amounts of information available on the servers across the Internet. As a result they can only return the most relevant information to their interested users. This saves network bandwidth when compared to the existing client/server model of computing where all the analysis and filtering are performed in the client side which requires transferring all irrelevant information along with the most relevant parts.

PAGE 33

21 Service point of view. Services offered by servers can be customized according to the user requirements, on-the-fly. Servers can offer basic primitives to use their services. Using these simple primitives, mobile agents can be programmed to reach the services and information offered by the servers in a customized way. The alternative used today is to provide service packages, which are offered to clients. Offering a new service requires a long implementation and deployment process. Therefore, users have to choose from these offered service packages. Mobile agents make the deployment process immediate. Application development point of view. Even it is not a real problem theoretically, client/server based application development poses the problem of a design issue of at which component the client or server, the services should be implemented. Mobile agents overcome this problem easily. Client side functionally can easily be moved to the server. Mobile agents, in general, simplifies the implementation, testing and deployment of distributed applications (Brewington et al., 1999; Johansen, 1998). Interestingly enough, they can even be used to develop and deploy prototype distributed applications (Chess et al., 1995a). Application user point of view. Not only mobile agents, but in general software agents have the capability of representing their users and user preferences, which is an important benefit especially in electronic commerce and mobile commerce applications. Distributed system point of view. Most distributed applications fit naturally to the mobile agent model (Brewington et al., 1999), mostly because of the mobility of the agents. This is the aggregate advantage and hence becomes the unique property of mobile agents.

PAGE 34

22 As a conclusion we believe that mobile agents possess an enormous potential in building feature distributed systems, once their drawbacks are addressed convincingly, as explained in the following sections. 2.3.4 Drawbacks of the Mobile Agent Paradigm Two major open problems, which prevent mobile agent paradigm from being a widespread, actively used technology today, are security and interoperability. The security problem of mobile agents is addressed in the next section. Here, we provide brief information about the interoperability problem. As mentioned in Section 2.3.2 mobile agents require their own mobile agent platforms to be executed. For example, an Aglet cannot be executed in an Ajanta platform even though these two mobile agent platforms and agents themselves were implemented in Java and all they need is a standard Java virtual machine. Interoperability has several aspects such as capability of communication between the different systems via message passing or RPC, capability of running mobile agents from different systems, or communication between agents from different systems. Recently, Brazier et al. (2002) proposed generative migration of mobile agents among heterogeneous platforms. This approach is based on agent factories and blueprints of agents. Blueprints, which could be describe with a high-level specification language, describe the agent functionality. Agents state is described by a language such as XML. Agents blueprints along with their state are migrated between host platforms where agent factories exist. The job of the agent factory is to transform the blueprint and the state into an executable form using libraries designed for this purpose and for the target environment, which exists on the same host. Although the approach seems to be promising, it raises several questions. First one is the security issue. While it is already

PAGE 35

23 difficult to protect agents from malicious hosts, this approach makes it worse. For example, the approach renders the agent protection schemes completely useless which are based on obfuscation methods. The other concern is performance overhead introduced with the approach to transform agents back and forth. Another approach is to let agents migrate only between their own platforms. If and when they need information available on some host, which does not employ the same platform that the agent needs, the agent migrates to the nearest host to the target one, with a platform needed for the agent. Then, assuming standard client/server interfaces are employed between the hosts, agent becomes a client and communicate with the target host using a request/reply scheme. This scenario is equivalent to the one with a target host, which does not support any mobile agent platform as in (Theilmann & Rothermel, 2000). The major problem with this approach is related with performance, which is to find the nearest available hosts to the target host. This issue is a subject of this dissertation. Moreover, making mobile agents dependant on the client/server model limits their capability to customize server functionality. 2.4 Security Problem of Mobile Agents In contrast to many other technologies in distributed systems, mobile agent technology will not be accepted and widely deployed before the security problem is solved. Other technologies have been widely deployed before their security requirements have been understood and mechanisms have been implemented and used. There are two types of security threats introduced by mobile code systems. One comes from potential malicious agents and the other from malicious hosts. The malicious agents problem is rather old and many protection mechanisms have already been proposed and implemented because of the fact that some kind of protection mechanisms

PAGE 36

24 are common in mobile agent systems and other mobile code systems. On the other hand, the malicious hosts problem is more difficult and considered unsolvable without dedicated hardware. The problem is relatively new since the computation in the form of mobile agents has never been defined to take place in a remote environment that could possibly be malicious. We are concerned with the latter problem in this dissertation: protecting the MAs from malicious hosts. Chess (1998) identifies the assumptions made on the security of computing systems in four categories: identity assumption, origin of programs, origin of attacks, immobility of programs. These assumptions state that programs and their users can be easily identified; programs are obtained from easily identifiable and trusted sources. Significant security threats come from attackers running programs with a clear intent in a restricted environment. Programs rarely cross administrative boundaries and only in controlled ways, programs run entirely on one machine on a specific operating system and operating system is responsible for the security. Unfortunately, these assumptions do not hold for mobile agents and in general, mobile code systems. Therefore new security mechanisms are necessary especially in the mobile agents case. The protection of hosts from potential malicious agents and the protection of agents against potentially malicious hosts are not mutually exclusive. There are two reasons for this. First one is that, in general, solutions proposed for the former problem implies also the protection of hosts. This is due to the fact that, a successful attack against a mobile agent in a given platform may threaten the subsequent platforms, which the MA visits. For example a brainwashed shopping agent may request for hundred airline tickets instead of the correct value of two. Similarly, an agent responsible for software updates

PAGE 37

25 may introduce Trojan horses to the subsequent hosts it visits, if a former platform could fabricate this code inside the software patches carried by the agent. The second reason is that some protection mechanisms, namely obfuscation techniques may render host security useless, since the intent of the agent might not be easily checked or verified by the platforms, which are to execute the agents. 2.4.1 Malicious Agents Problem Hosts, which are to accept and execute MAs must be protected against possibly malicious MAs. A malicious agent may access sensitive information on the host, which is not authorized to do. Moreover, MAs may alter, fabricate or delete data or files, and may inject malicious behavior in the form of Trojan horses. We have a brief look at mechanisms to protect hosts from two perspectives. The first one is the general mechanisms, which apply to almost all mobile code systems hence to MAs. The second category is specific to MA security, which necessary due to strong mobility and multiple execution platforms that a given MA may need to migrate and run. 2.4.1.1 General protection mechanisms against possibly malicious mobile code Sandboxes and playgrounds. Sandbox is a restricted execution environment where all the foreign code (i.e., downloaded from another machine) is to be executed. In Java, the Java Virtual Machine executes foreign code in a sandbox, which is complemented by a security manager, which checks the instructions of the code to verify if they adheres to the security policies (Oaks, 1999). For example, foreign code has restricted access to the file system, main memory and other assets of the computer system. Moreover, in the case of Java applets for example, their communication to the outside world is also restricted to the host from where they are downloaded. Since the code inside the sandbox needs to be interpreted in order to be checked, code

PAGE 38

26 interpretation is regarded as a part of the sandbox (Tanenbaum & Van Steen, 2002). However, in general, there exist code interpreter systems that do not employ the sandbox concept. Therefore, we consider this mechanism as a separate one in the following. Malkhi and Reiter (2000) extended the sandbox mechanism into playgrounds. Basically, the functionality is the same, however, playgrounds are to be placed in physically isolated machines. Foreign code is downloaded and executed only in these machines. The local programs can access the migrated code and data through traditional mechanisms. However, foreign code cannot access to the other computers and local assets in them. Interpreting code. Code interpretation is an important concept in mobile code systems for interoperability of heterogeneous systems. The code, which is not compiled directly into the machine instructions but instead compiled into some intermediate code (i.e., bytecodes in Java) can be run by standard middleware systems on top of the underlying specific operating systems. The best known example is the standard Java Virtual Machine, which can run almost on any operating system exist today. A nice side effect of code interpretation is the ability to easily check the code before execution during runtime. Therefore, each instruction can be inspected to figure out whether there is any access violation or any behavior, which does not conform to the security policies defined. Code signing. It is important in mobile code systems to authenticate the source of the code, which is migrated or downloaded. Digital signatures (through public key cryptography) can effectively be used for this purpose. The code is signed by the manufacturer (i.e., programmer) and/or the owner (i.e., user of a MA) by using their

PAGE 39

27 private keys. The receiver uses the corresponding public key to authenticate the source of the code. If the source is considered to be trusted then the foreign code can be assumed safe and executed. Even in theory this works well, in practice it is difficult to assess the trustedness of the source and the level of trust that could be associated with the source. 2.4.1.2 Specific protection mechanisms against possibly malicious agents Here, we provide an overview of the mechanisms proposed for the host protection against malicious agents. These mechanisms, mostly try to circumvent the issues arise from the nature of strong mobility of MAs which is a direct result and necessity of visiting multiple host platforms to accomplish a task. Path histories. The idea of path histories (Chess et al., 1995a; Ordille, 1996) is to record and carry authentication information of previously visited hosts, with an MA. Each host platform digitally signs and inserts its own identity and the next platform to the history using digital signatures. Meanwhile, every host, which receives an agent checks the validity of the signatures and decides by looking at the previous hosts, whether it would be safe to accept and execute the MA. If, for example, any of the identities of the previous hosts is considered to be untrusted, the MA is discarded. The drawback of the approach is that the payload of the MA increases at the every platform visited, and it is required to check the whole path of digital signatures carried by the agent. State appraisal. The state appraisal mechanism is to detect, to a certain extent, whether the current state of a MA, when arrived to a new site, is not harmfully altered. The agent code producer and the user of the agent provide appraisal functions for the state of the agent. This function is carried by the agent along with its code and state. When an agent arrives a new host, it must decide what specific privileges it will need at the host. The state appraisal function is used to compute a set of privileges to request as a

PAGE 40

28 function of the current agent state. In turn, the authorization mechanism employed by the agent platform determines which privileges requested by the agent it is willing to grant and whether the agent is in a safe state (e.g., no harmful modifications have been made) (Farmer et al., 1996). The authors indicate however that, it may not always be possible to detect a deceptive state from a correct one. Proof carrying code. This is a technique, which is used by the hosts to verify that foreign code provided by an untrusted party adheres to a predefined set of rules, which is known as safety policy. This policy is formed by the hosts to guarantee that the downloaded or migrated foreign code, if complies with the policy, will be safe to execute. Two components are used with the technique: a formal proof and a proof validator. The code producer creates a formal safety proof, which expresses the fact that the code will behave according to the safety policy. The code consumer host uses the proof validator, to check whether the proof is valid and therefore the code is safe to execute (Lee & Necula, 1997). The authors indicate that there are four necessary components for the technique: 1. a formal specification language used to express the safety policy, 2. a formal semantics of the language used by the untrusted code, 3. a language used to express the proofs, and 4. an algorithm to validate the proofs. Although the approach is theoretically sound, there might be practical difficulties in implementing and using the approach including a standard formalism for establishing the safety policy, automated assistance for generation of proofs, and techniques to limit the potentially large size of proofs (Jansen, 2001). In addition, the technique is tied to the hardware and operating environment, which is in conflict with the interoperability requirements of MA systems.

PAGE 41

29 2.4.2 Malicious Hosts Problem As we have pointed out above, protecting mobile agents from possibly malicious hosts in open environments is one of the most difficult security problems in distributed systems. This problem has even considered unsolvable without dedicated hardware. The obvious reason for this is that an agent in under complete control of the host it is to run on. Hohl (1998a) identified the specific threats to mobile agents: Spying out and/or manipulating code, Spying out and/or manipulating data, Spying out and/or manipulating control flow, Incorrect execution of code, Masquerading as a host, Denial of execution, Spying out and manipulation of interaction with other agents, Returning wrong results to system calls issued by an agent. Hohl (1998b) also provided a set of requirements for an attack model against mobile agents. He uses the Random Access Stored Program (RASP) machines to show that the components of the execution process of an agent program can be accessed by an attack program and this program can be executed by another machine (in the abstract sense) to control the execution of the agent program. There are several approaches proposed in the literature. Different classifications of these approaches can be given. For example, some approaches are aimed only to detect certain attacks whereas others try to prevent them. While some of the approaches are more general, majority of the proposed solutions target specific threats. Although we do not give a precise taxonomy, a classification and a brief description of the proposed solutions are presented below.

PAGE 42

30 Organizational or social trust. Most of the MA systems ignore security by the assumption of organizational or social trust. For example, an individual user may have trust to a reputable well-known company. Therefore he/she may not expect any hostile behavior from the company that operates the MA system, against his/her agent. But this cannot be applied to a virtually unknown company, and such an e-commerce MA system may not be fair to businesses that have not yet established a public trust. On the other hand, social trust does not apply to a business-to-business e-commerce system based on MAs. For example two competing companies could not assume the same trust to one another as in the individual user case, even if these were reputable companies. This potential aspect of lack of trust could severely limit the use of MAs in an open e-commerce environment. However, we believe that together with other technical security mechanisms, this aspect will be helpful in providing better security for MAs. Solutions based on obfuscation. Blackbox security is an obfuscation scheme, which does not rely on cryptography. It defines the problem as to make an agents code and data be messed up so that cannot be read or modified at any time (Hohl, 1998a). Because there is no known solution to the problem, the at any time requirement is relaxed to for some known time interval. The idea is to scramble code and data of an agent so that they do not reveal the function of the code. The interesting aspect of this proposal is that it does not rely on cryptography. There are some issues to be solved by the approach such as necessity of synchronized clocks to be able to realize time limitation. Code obfuscation is a well-known method and there are many examples especially for Java. However, there are also tools to defeat known obfuscation methods and this is an arms race as indicated in (Dyer, 1997).

PAGE 43

31 Another approach for mobile agent protection relies on cipherprogram concept (Sander & Tschudin, 1998). It is claimed that mobile agents do not have to rely on cleartext data, program or messages. This, in turn, relies on computing with encrypted functions and computing with encrypted data. Encrypted functions work as follows. Suppose Alice has an algorithm to compute a function f on data item x. Bob has the computation power and would like to compute f for Alice. However Alice does not want Bob to know anything about f. If f can be encrypted in a way that another function E(f) can be computed by a program namely P(E(f)), then Alice sends this program to Bob, after execution Bob sends the result back to Alice. Alice, in turn decrypt the result to obtain f(x). Although it is not claimed to be a general solution to agent protection and the computation is limited to certain functions (e.g., polynomials), this approach is a good example for a software-based solution based on cryptography. However, recently Barak et al. (2001) have shown that this approach is not likely to succeed. Tracing data state and execution. Partial Result Authentication Code (PRAC) has been proposed by Yee (1999). The goal is the technique is to ensure forward integrity using cryptographic checksums formed using symmetric cryptography similar to Message Authentication Codes (MAC). Forward integrity means that results of the previously visited hosts should not be able to be forged by a malicious host subsequently visited. The technique requires maintaining or generating keys for every host visited, with the assumption that the hosts will destroy the keys after the computation is complete. This raises concerns especially if the agent needs to revisits a previous host. PRACs are aimed to provide integrity rather than confidentiality. Karjoth et al. (1998) improved the

PAGE 44

32 technique using digital signatures to create a chain of results obtained from the hosts visited. Young and Yung (1997) proposed the sliding encryption technique to deal with the small size data usually obtained from hosts by mobile agents when compared to the size of the encryption keys and resulting ciphertext. The technique is to ensure confidentiality with public key cryptography accumulating the encrypted data in each platform visited. Another approach is called cryptographic traces (Vigna, 1998), which aims at detecting any kind of tampering with a mobile agent. It relies on code execution verification using traces based on cryptography. This technique requires each host visited by a mobile agent to create a trace of the execution of agent. This trace is both maintained in the host and forwarded to the other hosts subsequently visited by the agent. The major concern is the size of the trace, which needs to be carried with the agents. This is another unauthorized modification detection technique. Hardware-based solutions. Hardware support is recognized as the only tractable solution since no single software solution proposed so far addresses every possible attack. One example is the Tamper-proof Environment (Wilhelm et al., 1998), which is a regular computer with some specialized OS, manufactured only by authorized well-known parties. Sites that offer services to mobile agents purchase these computers and advertise this. In turn agents execute only in these isolated places by interacting with the hosts on those sites by well-defined secure interfaces. However it might still possible to devise some attacks and the solution does not seem feasible because of its special requirements. A similar approach has also been taken by Yee using secure coprocessors (Yee, 1999).

PAGE 45

33 Environmental key generation. Environmental Key Generation approach (Riordan & Schneier, 1998) relies on some interesting observation that agents can find some keys whose protection is crucial only after they are on the host on which they will execute. A key can be sent to an environment such as a news list or a mailbox. The idea is to not carry the keys but to know how to find them. After agents find their keys in this manner they can do their jobs with some protection. An interesting example is given as a search agent that needs to search remote databases without revealing what it looks for. The solution is nothing more than using a cryptographic hash function that is applied to the items in the database and checking the results against the already hashed value carried with the agent. Because it is still vulnerable to denial-of-service attacks by changing the value carried by agent this approach should be used together with some other solution to prevent the kind of attacks mentioned. Multiple (cooperating) agents. The idea of using more than a single agent for fault-tolerance and security has also been studied by some authors. However this approach has not been attracted deserved attention. Since the theme of this dissertation is in this category, we provide related previous work in Chapter 3 in more detail. Other approaches. Another approach protects the computation of agents by relying on trusted third parties (Corradi et al., 1999): some sites that offer a trusted environment for mobile agents to perform secure operations. Agents need to visit such a site after computing in some untrusted host. Another example (Marques et al., 1999) assumes a neutral trusted host for e-commerce applications. But it is not clear in these proposals, why and how untrusted hosts guarantee to send the agents to so-called trusted servers to compute with secrets.

PAGE 46

34 Meadows (1997) proposed the detecting objects idea, which is originally proposed for database integrity against unauthorized modification. In this scheme, some dummy objects are inserted into the mobile agents. For example, a shopping agent can be provided by some dummy offers as if they were coming from legitimate merchants. By carefully selecting these objects, the owner platform can check the agent whether these dummy objects have been tampered with. If there is no modification to these dummy objects, then with some degree of confidence it can be said that there have been no modifications to the other parts of the agents. However, this scheme is highly application specific. We extended the idea to detection objects and code (Onbilger et al., 2001). In this scheme, some dummy code fragments can be inserted into the agent code together with dummy objects. Depending on the degree of protection desired, dense of injection can vary for different applications. Since, it is intractable to distinguish dummy code fragments from the original ones, execution results of the dummy code can be checked against previously recorded results and it can be detected whether the code is executed correctly. By combining the technique with multiple cooperating agents, detection can be made immediate, without requiring the agent to return to the originating platform. General discussion and survey papers for mobile agent security are given by Tschudin (1999), Jansen (2001), Claessens et al. (2003), and Oppliger (1999). Some flaws in the security protocols, which have been proposed before and summarized above are identified by Roth (2001).

PAGE 47

CHAPTER 3 MULTIPLE COOPERATING MOBILE AGENTS 3.1 Introduction Information Dispersal is a technique used for faultand intrusion-tolerance of information. The study in this area consists of three phases. In the first phase, Shamir (1979) showed how to construct a robust key management scheme for cryptographic systems. In this scheme, a secret S is divided into n pieces in such a way that S can easily be constructed from any of the k pieces, but the knowledge of k-1 or fewer pieces reveals no information about the secret S. This is called a (k, n) threshold scheme. The remarkable aspect of the scheme is that k-1 pieces give no information about S, so it is applicable to relatively small data such as secrets. However, this scheme is not space efficient, consequently it is not suitable for large data such as a file. Rabin (1989) showed how to disperse a file into pieces and to use a subset of pieces to reconstruct the file later, in a space efficient manner. In this scheme, a file F of length L is divided into k pieces each of length L/m. The file can be reconstructed from any m pieces. The sum of the lengths of pieces is L(k/m). Because k/m can be chosen to be close to 1, the scheme is space efficient. The second phase includes the techniques of Fragmented Data Processing (FDP) (Fray & Fabre, 1991) and Fragmentation-Redundancy-Scattering (FRS) (Fabre et al., 1994). The common goal in this phase, in addition to the concept of information dispersal for security in the first phase, is the processing of sensitive information. FDP is designed to employ parallel processing techniques to process fragmented and scattered pieces of 35

PAGE 48

36 data. Sensitive information (both code and data) is fragmented into pieces in the trusted part of a distributed system and the pieces are located on hosts in the untrusted part of the system. The code fragments are constructed using a pre-processor and compiler so that when collaboratively applied by the hosts on the corresponding pieces, the result becomes exactly the same with the result of the original code applied to the original data. Similarly, the goal of the FRS is to employ several hosts to provide fault-tolerance of the systems and intrusion-tolerance against deliberate faults. The fragmentation process may consist of several iterations. At each iteration, application objects, which consist of both code and data are decomposed into more elementary objects if there is still identifiable confidential information exists. Redundancy is achieved by either applying techniques such as checkpointing and synchronization or relying on detection mechanisms and voting protocols implemented over underlying multicast communication system. Scattering phase consists of assigning the fragmented and redundant elementary objects to the hosts in the system. The goal is to assign the elementary objects in such a way that the objects that are assigned to the same host would not reveal any confidential information. We consider our work as part of the third phase in this field. There are however important differences between the third phase and the former ones. FRS and FDP utilize a distributed static infrastructure to provide tolerance. In our case the target environment is already distributed and extremely dynamic. The assumption with those techniques that there are fixed available hosts in a close environment does not hold for the MA problem. FRS merely relies on a spatial technique (replication) but we need to consider both spatial and temporal solutions for efficiency. Also, in addition to Shamir and Rabins work we

PAGE 49

37 also need mechanisms not only to distribute the secrets but also to be able to compute with them again in a distributed fashion. These differences inevitably add new challenges to the known problems and solutions. 3.2 Requirements and Objectives There are mainly four requirements to meet in providing security to mobile agents as mentioned in Chapter 1. The first one is that a solution proposed to protect hosts from possibly malicious hosts should not jeopardize the protection of hosts from agents. Some proposed solutions such as obfuscation mechanisms might not be feasible since they may cause hosts to be vulnerable to attacks by hostile mobile agents. The second important requirement is that solutions should not limit the potential benefits of mobile agents, which are otherwise observed and enjoyed. While security is an important requirement for the mobile agent technology to be accepted and widely used, it should not sacrifice the benefits we gain from using them. One such property that is usually ignored by the proposed solutions is the autonomy of mobile agents. Since it is one of the distinguished features of them, sacrificing autonomy would severely limit the their applicability to the wide range of possible applications. For example, an MA may be required to communicate with its owners host to perform some security sensitive operations. This violates the autonomy property of the agents, which constitute the basis of disconnected operation, which is a highly desirable mode of functioning in m-commerce. Another example is to allow mobile agents to execute only on trusted hosts and then limit the use of mobile agents into the client/server model to access the untrusted hosts. While this model provides security it sacrifice the benefit of customizing the computations on servers, which is another important feature of mobile agents. The third one is related to one of the fundamental principles of security: when there are easier ways of defeating a

PAGE 50

38 system, an attacker would not try to penetrate to the system through well-protected components. So, it is vital to address easier attacks against mobile agents, which are denial-of-service and replay. The last requirement is extending the network trusted computing base concept. This concept has been proposed as a solution without giving clues about how they could be realized. Simply assigning some dedicated hosts for this purpose does not seem practical. At least, these hosts could be single points of failure and targets of attacks. Moreover, locations of these hosts should also be considered. Under the requirements given above, the goal is to make individual MAs meaningless when they are treated as a single entity as much as possible since there is a trade-off between openness and security. This makes them resistant against malicious behavior of the hosts where they execute. A given task is split up into two or more MAs. These MAs are located in different hosts and migrate when necessary. They exchange information and partial results of execution at certain synchronization points. So, the approach presented here is based on information (data and code) dispersal supported by known cryptographic techniques. In a mobile agent system there are three general security objectives: 1. Data confidentiality, 2. Correct code execution and data integrity, 3. Code confidentiality. Data confidentiality is the easiest-to-achieve goal in our approach especially if the data needs to be kept confidential from certain hosts that possibly could gain advantage from knowing it. It is possible to place sensitive information (i.e., credit card) in an agent encrypted with a nonce and place the nonce in a cooperating agent. Other more complex means are also possible.

PAGE 51

39 Data integrity can be achieved through the idea of detection objects, which has been proposed by Meadows (1997) to detect possible modifications to MA data. Correct code execution along with data integrity can be provided by extending the detection objects idea and introducing detection code. Predetermined but random code fragments are injected into the original code of the agent (possibly by also introducing dummy data). These code fragments can be produced by a tool and the modified program can be guaranteed to give the exact same result as the original when executed. At certain synchronization points, agents exchange the results of the modified program together with the results of the original program. Since the dummy code results have to be fixed, another agent can easily check them against the precalculated values. Together with realizing time limitations and dense injection (i.e., one line of dummy code for every original line) it can be guaranteed that the original code was executed correctly. Although a human can detect which portions of code are dummy by analyzing the code, it is an undecidable problem for machines especially if data flow analysis is prevented by mixing the data flow from the original code to the dummy code (e.g., y=y*x; z=y; z=z/x; y=z; y and z are dummy, x is not). Since the concern here is instant correct execution of code and time for that execution can be limited to a few seconds, an analysis by an human is prohibited. The approach presented is equivalent to randomized state information that could be maintained and exchanged among agents. Code confidentiality is the most difficult of these problems. The difficulty of the problem comes from the fact that it is not possible to limit the time for analysis; therefore human analysis attacks are possible. Due to the difficulty of the problem, one might

PAGE 52

40 restrict the confidentiality of code into certain decision functions (e.g., a shopping agents purchase decision) and apply the code injection technique to those functions before splitting. In addition to arbitrary code generated by a tool randomly, other mechanisms can be applied. For example, code can be generated which consists of similar statements to the original code. Also, code libraries can be used to provide code that implements some relevant or irrelevant function to the original function. The three goals above are the generalization of broad range of diverse security requirements of the MAs. There are certain situations where combinations of the three goals above overlap. One such requirement in a mobile e-commerce environment is computing with secrets in an untrusted environment. Any such secret (e.g., a private key) cannot be revealed to any third party since the information here is more sensitive. For example, people reveal their credit card information to buy lunch but not their social security number (even if asked). So, it is crucial to have the ability not only to keep certain data secret but also to compute with that data. Digital contract signing (Sander & Tschudin, 1998) is such an example and Chapter 4 demonstrates how to do this computation remotely by a group of agents without divulging secrets or inventing new cryptographic algorithms. 3.3 Definitions The problem of protecting MAs against malicious hosts comes from the fact that they are, by definition, autonomous. Since this aspect of MAs is the most important among others and actually it is what make them special, it would not be a good idea to give it up for the sake of making them secure. But if we define autonomy not for a single MA but a group of communicating and cooperating MAs, which rely only on each

PAGE 53

41 other to perform a single task to achieve a goal, we will be able to reach autonomous secure MA groups. Definition. Autonomous MMAs. A group of mobile agents is said to be autonomous if they together have the knowledge necessary to perform a single task, and they communicate and cooperate to perform that well-defined task. What follows is the definition of the mission concept. Definition. Mission (traditional single mobile agent case). A mission consists of a mobile agent, a set of hosts to be visited, execution of the agents code on these hosts and the set of migrations of the agent between any pair of these hosts. Definition. Mission (multiple mobile agents case). A mission consists of an autonomous group of mobile agents, a set of hosts to be visited, execution of the agents code on these hosts, a set of migrations of the agents between any pair of these hosts and communication among the agents. The term mission is the counterpart of the term session in client/server computing. A mission can represent any session that carries out a computation such as a database search, a network management activity or an e-commerce task, etc., using MAs. 3.4 Mission Models Single mobile agent model. This basic model is illustrated in Figure 2-1 in Chapter 2. The mission must be accomplished by visiting several hosts, which requires process migration from host to host. The agent computes (e.g., is being executed) in these hosts and returns home at the end of a successful mission in this case. Note that the illustration in Figure 2-1 is a simplified generic case of a mission. It may not be necessary for a mobile agent to return home and a same host might be visited multiple times in the same mission.

PAGE 54

42 Mobile client/server model. Depending on the mission given, one or more of the following reasons might prevent placing an agent on a service provider host: The server may not have a mobile agent platform, The mobile agent platform supported might be a different one, The host may not be trusted or may not provide any measure to appraise trust on. Therefore in this model the mobile agent is located on a host, which provides the necessary environment and is close to the target host. The model is illustrated in Figure 3-1. HostHostHostHostAgent Owners Host Agent Agent Agent Agent Agent Agent Agent Agent Service migrationcommunication Figure 3-1. Mobile client/server model This model is not suitable for applications where it is necessary to customize certain server functionality. If the model is used for security purposes, it will not meet the second requirement mentioned in Chapter 1. Multiple mobile agents model. The multi-agent paradigm fits well with the concept of protection of an application as a whole. It is more difficult to compromise a task if the task is split into multiple collaborating agents. In the context of data secrecy, this is also referred to as information dispersal for security.

PAGE 55

43 The multi-agent model does not differ from the classical agent model in terms of the definition of the mission. The difference is due to the definition of the autonomy property of MAs. So, in the new model, MAs are autonomous as a group but not as an individual entity. The group of agents carries out a single task by communicating and cooperating. Figure 3-2 illustrates the model. In the model, we call one of the agents the master agent (Alice in the figure), who actually visits the set of hosts that are necessary to complete the mission. This set of hosts is called the itinerary of the mission. The itinerary may or may not specify the order of the hosts to be visited. The other agents are called support agents (Bob in the figure), who visit only the hosts outside of the itinerary of the master agent. Note that, the model that we describe here is the most generic multi-agent model. HostHostHostHostAgent Owners Host Bob Bob Bob Bob Bob Bob Bob Alice Alice Alice Alice Alice Alice Alice Alice Alice HostHostHost migrationcommunication Figure 3-2. Multiple mobile agents model with two mobile agents

PAGE 56

44 Variations of the model admit more than one master agent, or alternatively, a peer-to-peer architecture can be employed. In the figure, Alice and Bob, migrate according to their itineraries and communicate with each other. As it is clear, the migration of an agent or agents in a group is more complicated in this model and requires support from an underlying system that is aware of the underlying network topology. This issue is addressed in Chapters 5 and 6. 3.5 Multi-agent Systems (MAS) vs. Multiple Mobile Agent Systems (MMAS) In Chapter 2, we have defined multi-agent systems and said that multiple mobile agent systems differ from those. Following table highlights the differences between the two. Table 3-1. Comparison of MAS and MMAS Property Multi-agent Systems Multiple Cooperating Mobile Agents Interactions Not pre-defined Pre-defined Global system goal Not exist Exist Autonomy w.r.t. goal Yes No Single owner No Yes Main goal Easy, efficient, intelligent and distributed problem solving Combine MAS and MA Paradigm MA Protection However, it should be noted that the above properties of multiple cooperating agents are internal to their group. There is nothing to prevent a group of multiple cooperating agents from participating in any multi-agent system. So, from a broader point of view multiple cooperating agents can perfectly become a part of any multi-agent system.

PAGE 57

45 3.6 Proposed Architecture for MMASs In this Section we present the proposed system architecture of MMASs. We will explain the architecture by providing the step-by-step workflow of the system as illustrated in Figure 3-3. On the host side we show the components/modules of an MMAS. Note that, the Mission Planer, Mission Optimizer, Security, and the Context components can be interpreted and implemented as part of the MMAS. However, we show them as separate components in the figure for the sake of clarity. On the network side the double-line boxes represent systems rather than modules. These systems, except the Directory (a.k.a. Yellow Pages) system are distributed systems. The network positioning system is a peer-to-peer distributed system, which provides relative positions of the participating hosts via coordinates in a geometric system. The proposed architecture for this system is given in Chapter 5. The DNS is the Domain Name System. The anticipated role of the DNS will be clear in Chapter 5. The Directory system can be either a centralized or a distributed system. Although it is not addressed in this dissertation, we believe that it needs to be a distributed system. The primary responsibility of this system is to maintain and provide the information about the hosts, which employ a MA System and the services provided. The workflow and the responsibilities of the components in the architecture are given below.

PAGE 58

46 UI Application MMAS Mission Planner Mission Optimizer Context Network Positioning MA System Security Directory HOSTNETWORK 18 1 17 2 3 4 16 12 13 5 9 6 7 8 11 10 14 15 DNS Figure 3-3. Multiple mobile agent system architecture Step 1: The Application receives the information from the user through the User Interface. Two example applications are provided in the next Section. Step 2: The Application presents the information to the Multiple Mobile Agent System (MMAS). Steps 3 & 4: The MMAS gives the related information to the Security module. This module is responsible for determining the security level required for this instance of the Application and deciding the number of agents and the necessary communication among them. The module returns this information to the MMAS. Note that, apart from the workflow presented, the MMAS and the Security modules can interact to create the group of mobile agents necessary for the mission by observing the necessary dispersal of information, code and data, at the later steps in the workflow.

PAGE 59

47 Step 5: MMAS presents the information provided by the Application and the Security module to the Mission Planner. This module is responsible for planning the mission by coordinating the other support modules. Steps 6 & 7: The Planner module first asks the Context module for information about where and how this particular instance of the application could take place as a mission. The context module in turn communicates with the Directory service to obtain contextual and network/topology information. Steps 8 & 9: The mission planner receives the contextual information. Steps 10 & 11: The planner then asks the Mission Optimizer to compute the best possible itineraries for each agent by taking into account their interactions during the mission, in terms of the total execution time of the mission. Step 12: The planner presents the optimized mission information to the MMAS. Step 13: MMAS using all the information provided by the modules creates the mobile agents to accomplish the mission and passes the agents to the MA System. Any existing MA System can be used here, however one might expect some modifications on the existing system for integration/interoperation of the MMAS and the MA System. Steps 14 & 15: The MA System, just as in the single mobile agent applications send out the agents to the network. Mobile agent(s) return to the MA System with the result. Steps 16, 17 & 18: The result of the mission is presented to the user. Following chapters of this dissertation deals with the research issues of Security, Mission Optimizer and Context components as well as the Network Positioning System. More precisely, Chapter 4 is related with the Security component. Chapter 6 addresses

PAGE 60

48 the issues with the Mission Optimizer component and also makes it clear how context-awareness is an important concept in MMASs and their security. Some issues with the Context component and a proposed architecture for a network positioning system are given in Chapter 5. Due to the lack of the Directory component, which is out of scope of this study, we assume its existence, however we make no assumptions about the use of contextual concepts. The TPNP system (Chapter 5) is capable of providing this information as a peer-to-peer system. A directory system will only need to cooperate with the TPNP to obtain contextual (including location) information. 3.7 Example Missions In this Section we present two real-world examples of multiple mobile agent applications based on the system architecture given in the previous Section. Example 1. Shopping Agent. The shopping agent is a classical example of mobile agent applications in e-commerce (See Chapter 2). The job of the agent or the group of agents is to visit on-line merchants of the product of interest, negotiate and finally purchase the product by making the payment. We assume that the user would like to purchase flowers. The user presents the details of preferences for this purchase (e.g., a dozen red roses, under $10, with a gift card) to the shopping agent applications using the user-interface provided by this application. The user either indicates the security requirements specific for this mission or the application uses a preference file to use default or existing set of requirements for this kind of missions. The application passes this information to the MMAS possibly in XML format. MMAS consults the Security module to determine the mechanisms needed to apply to be able to meet the security requirements of the user.

PAGE 61

49 For example, the purchase may require a digital signature to be generated and presented to the merchant, which is the subject of Chapter 4. We assume that the Security module decides to use a master/support model with two agents; Alice and Bob from Section 3.4. MMAS passes all the information about the mission to the Mission Planner. The planner needs first the context information, which consists of the potential merchant hosts to be visited by Alice, the set of hosts of which a subset would form Bobs itinerary, their trustworthiness and locations. This is the job of the Context module in the architecture and this module contacts the Directory system for this purpose. The directory system executes a query given the input as the transaction of purchasing flowers from potential merchants. The result of the query appears to be a list of merchant hosts on the Internet. This part is exactly the same as of the classical single mobile agent applications. The directory service will also provide additional information about these hosts. This information needs to be the level of security provided by these hosts, the hosts that Bob will be visiting, the level of security provided by these support hosts and location information of all the hosts. The network positioning system, TPNP is capable of providing all these information, which is the subject of Chapter 5. The directory system returns the information about merchants and potential support hosts to the Context module. The mission planner at this point has two issues to consider, which are to find best possible itinerary for Alice to visit merchants and the selection a subset of hosts returned by the Context module for Bob. The mission planner may consult the user for choice of possible merchants or may use a file to determine the preferred merchants. The planner then consult the Mission Optimizer module to provide the order of hosts to be visited to make the mission as short as possible. In addition, the mission

PAGE 62

50 optimizer is responsible for choosing the closest support agent hosts to a subset of merchant hosts. The result of this selection is the itinerary of Bob including the order of hosts. This is the subject of Chapter 6. When the mission planner returns its decisions, the MMAS is ready to create the agents for the flower mission and then pass them to the MA system to be forwarded to the network. Example 2. Software Distribution. Our second example is from a relatively new application area of mobile agent technology. The scenario is as follows. A software vendor has a product running on their customer sites around the world. The company continuously improves its products and provides updated versions to the customers. They also need to provide their customers with software patches for newly found security flaws in their products. The company figures out that mobile agent technology is a viable alternative for this problem, that is using a push model with mobile agents is rather powerful than the pull model in client-server computing. They also know that security is still a drawback of mobile agent technology. But they also are aware that a group of cooperating multiple agents provide the level of security they need. So, they develop a multiple mobile agent system following the architecture presented in the previous section and ship the MA execution environment part of this product to their customer sites along with their application software. When a new security patch is ready to be installed for a recently discovered flaw in their application software, they launch agents to the Internet to update their customer systems. They organize their software in well-designed small modules so that when they

PAGE 63

51 need to update some module, their agents will only carry that small module as the payload. We will not repeat the whole process for this application but we will provide only the differences from the previous example. In software distribution, the number of sites to be visited are expected to be much larger than the e-commerce applications. So, several agents or group of agents may need to be deployed according to their locations. Since the customers are well known by the company, the directory systems main responsibility of providing host information is not useful. However, context and network information is still quite important. This application may use the master/support agent model as well as the peer-to-peer model. The former may be preferred for small number of customer sites. The latter is more suitable when the number of sites is large. In this case, agents need to act both as a master agent to do the primary job of software distribution and checking the integrity of peers for security. The alternative is to use the former model with multiple master agents, and make the support agent responsible for checking all of them. We assume that the security component decides to use a master/support agent model with two agents, Alice and Bob. The software module to be installed is split up by the MMAS with the help from security and mission optimizer components. Security component makes sure that the payload of either agent would not reveal essential information about the module. Mission optimizers responsibility is to balance the load of agents so that the cost of the mission will be minimized in terms of agent migration and communication.

PAGE 64

52 Both Alice and Bob have the credentials to check the integrity of the payload of each other. On every host Alice visits, she contacts Bob and sends the payload integrity check to Bob. Bob verifies the code as well as the identification of host on which Alice is running. If all checks are successful, Bob sends Alice the part of patch he is carrying. Alice after checking the Bobs information installs the new module in the customer system and migrates to the new site in her itinerary. Bob, if necessary also migrates to the next host in his itinerary. Neither agent in this application needs to return home after the mission completes. 3.8 Related Work Multiple agents have first been used by Minsky et al. (1996) for fault-tolerant distributed computing with MAs. The proposed scheme is deploying clones of an MA to identical servers at each stage of the computation and then comparing the results. In this scheme MAs do not communicate or cooperate. The assumptions that the identical servers would be available and that they would be under different administration domains, so that they would behave independently, are not realistic. Yee (1999) proposed a fault-tolerant approach, where replicated agents are sent to the same set of hosts to figure out airfare prices for a flight ticket purchase. Agents traverse the hosts in the reverse order and at the end the minimum prices they come up with are checked. In the one malicious server case it is possible to find out the actual best price. This is one of the earliest proposals using multiple mobile agents which is application and case specific. Ng (2000) used multiple agents for security purposes. In this scheme, again the agents do not cooperate; instead the task is split into multiple agents so that any agent alone would not reveal any useful information. In contrast to the multiple agent model we

PAGE 65

53 use, agents in this scheme visits the same hosts, therefore they need to be completely anonymous to be able to defeat attacks. Cooperating multiple agents have been first used by Roth (1998). It is shown that two cooperating agents, under certain assumptions, can verify the path each agent takes and whether the migration patterns adhere to the itinerary of the agents.

PAGE 66

CHAPTER 4 REMOTE DIGITAL SIGNING WITH MOBILE AGENTS 4.1 Introduction Although the MA paradigm opens many interesting applications, to validate it as an alternative to traditional client/server computing, one must address its security issues. In particular, it should demonstrate the ability to compute with secrets in remote public domains. A good example of the need for this is digitally signing a contract for m-commerce (and in general e-commerce) applications with MAs as shown by Sander and Tschudin (1998). We call this problem remote digital signing. In this chapter, a multi-agent architecture is used and a solution to this problem is presented. The techniques we explore and analyze are based on information dispersal in distributed system security terms as well as multisignatures and secret splitting in cryptographic terms. The idea is to devise a secure way of sharing secret keys among members of a multi-agent group and signing with shares. 4.2 Electronic Commerce and Mobile Agents Among many application areas of MAs (such as information retrieval, e-commerce, network management, network/site security, distance education, and software distribution) e-commerce draws the most attention from both academic and industrial researchers, for example see Busch et al. (1998) and Klusch (1999). This is mostly due to the fact that, MAs and in general agent systems have the capability of representing users (i.e., customers) in the cyberspace. Agents can effectively profile user preferences, act on behalf their owners, participate in e-auctions, watch stock prices, search for commodities 54

PAGE 67

55 and find the best offer from competing vendors, purchase goods by paying and committing to transactions, communicate and cooperate with other agents of relevant goals. Although it is now agreed that MAs are not a new enabling technology, they offer many technical capabilities together (i.e., all-in-one) over the traditional client/server computing (Chess et al. 1995a; Chess et al. 1995b; Lange & Oshima 1998). Mobile commerce (m-commerce), which is a rapidly growing field in e-commerce, is especially a suitable application area of MAs. 4.3 Mobile Commerce and Mobile Agents Mobility of agents brings unique advantages to m-commerce. Mobile devices such as PDAs and laptop computers have limited battery life, intermittent and low-bandwidth connections to the fixed network. Traditional client/server computing which was originally designed for and very well fit into the fixed wireline networks is not suitable for m-commerce due to these limitations. MA paradigm enables disconnected operation (Chess et al., 1995a; Gray et al., 1996), where a brief connection to the fixed network from a mobile device through the wireless network is sufficient to launch an MA (or MAs) to engage in a mobile commerce activity. For example, a laptop owner, which has a wireless connection to the Internet, through a cell phone, may launch an agent to search for the best offer for an airline ticket and make a purchase. While the agent working towards the goal of purchase, the owner can (or may be forced to) disconnect from the network. When the MA accomplishes the goal, it takes another brief connection to receive the agent with the results. 4.4 Mobile Agent Security in Mobile Commerce There are two aspects of the security issues in MA technology which are known as the malicious agents problem and the malicious hosts problem. In the former case, the

PAGE 68

56 hosts that are to accept and execute the agents should be protected against any possible hostile behavior of agents. There are known mechanisms such as sandboxes proposed and implemented. The latter case is considered to be much more challenging due to the remote nature of the platforms where the MAs are to be run. Since these platforms are owned and operated by other parties, it is difficult to establish trust. Classical security mechanisms designed for distributed systems, including the cryptographic ones come short for threats against the MAs due to the assumptions, which do not hold for MAs (Chess, 1998). So, protection mechanisms are needed to make MAs safe in possibly hostile environments. E-commerce is the most security demanding application of the MA paradigm. This is not different for m-commerce, which is a special case of the broader topic of e-commerce. In fact, it can be argued that if all the security requirements of e-commerce applications are met, then the general MA security problem is solved altogether. The shopping agent application where a MA is deployed to find the best possible price for some good such as an airline ticket, flowers or CDs, and make a purchase, has become the classical problem for discussing the requirements of MA security and proposing solutions to certain aspects of the requirements (see for example, Berkowitz et al. (1998), Hohl (1998), and (Yee 1999)). Hohl (1998) provides an extensive list of attacks using a shopping agent application example that could be launched against an agent. The focus of this chapter is the remote digital signing problem for shopping agents. In any trade, principals engaged in the activity need to authenticate each other. A merchant would like to know whether the credit card presented by the buyer really does belong to the party or whether a check provided is legitimate and authentic. Customers

PAGE 69

57 would like to make sure they present their confidential information such as a credit card to the merchant of their choice, but not anybody else. Similarly, merchants need to authenticate the MAs and their owners. This is necessary to prevent repudiation, which could be a very simple attack to devise using MAs. Even honest users may change their minds well after the transaction took place and deny that they didnt send any MAs to buy any such product. On the other hand, a hostile MA could masquerade a legitimate MA and hence its owner, to engage in fake trading to harm either or both of the principals of the transaction. Therefore a MA should be capable of digitally signing a contract agreed on by both parties to authenticate themselves and their owners, remotely and publicly, meaning that on the hosts they execute. 4.5 Objectives Our objective in general, is to meet the requirements of solutions proposed for any aspect of MA security problem. These requirements were identified in Chapter 1. Our specific goals in this chapter are to achieve a solution to the remote digital signing problem which should be as simple, realistic, flexible and ubiquitous as possible. With simplicity, we mean that the solution will be easy to understand and implement. By the use of already established and standardized digital signature schemes, such as RSA and El Gamal algorithms, if the original signing and verification functions can be used then specific implementation may not even be needed for our problem. To be realistic, it is meant that a proposed solution should fit into the real world environments, where they are to be used. For example, in theory, threshold signature schemes seem to fit very well in the MA paradigm when a multi-agent model is used. However, in practice it is necessary to identify the hosts where these MAs are going to be executed. The number and location of these hosts are to be restrictive as explained in detail later. Flexibility is

PAGE 70

58 related to the autonomy of MAs from another perspective. Unlike some other solutions proposed, it is important to distinguish what can be done (i.e., signed) by a MA and what actually has been accomplished. Ubiquity is again related with the cryptographic functions used. Widely implemented cryptographic signature schemes improve the scalability in terms of number of hosts where MAs may need to find and use these schemes. 4.6 Background Multiple agents have first been used by Minsky et al. (1996) for fault-tolerant distributed computing with MAs. The proposed scheme is deploying clones of an MA to identical servers at each stage of the computation and then comparing the results. In this scheme MAs do not communicate or cooperate. The assumptions that the identical servers would be available and that they would be under different administration domains, so that they would behave independently, are not realistic. Ng (2000) used multiple agents for security purposes. In this scheme, again the agents do not cooperate; instead the task is split into multiple agents so that any agent alone would not reveal any useful information. In contrast to the multiple agent model we use, agents in this scheme visit the same hosts, therefore they need to be completely anonymous to be able to defeat attacks. Cooperating multiple agents have been first used by Roth (1998). It is shown that two cooperating agents, under certain assumptions, can verify the path each agent takes and whether the migration patterns adhere to the itinerary of the agents. Sander and Tschudin (1998) introduced the concept of Mobile Cryptography. The idea is to encrypt agents as a whole and apply computing with encrypted functions and data. Although it is limited to polynomial and rational functions, this is a good example of a software solution to the MA security problem that is based solely on cryptography.

PAGE 71

59 In the same paper they also introduced the concept of undetachable digital signatures, which is based on the concept of computing with encrypted functions. They point out that this is a possible realization of an agent would like to use the secret in public e.g., to compute the digital signature of an order form but without disclosing the secret needed to do so. In this approach, user constraints are glued together with the general purpose signature function to enforce them to be a part of the signed contract; hence the term undetachable signatures. Nevertheless, they also point out that the scheme on which their proposal is based has been successfully attacked. Kotzanikolaou et al. (2000) proposed a solution to the problem introduced by Sander and Tschudin (1998). They use RSA (Rivest et al., 1978), which is based on exponential functions rather than rational functions. However, as the term undetachable digital signatures implies, the solution given by Kotzanikolaou et al. (2000) requires that the signature be generated by the user (i.e., owner of the agent) and given to the agent before the mission takes place. This contradicts MA autonomy. This is due to the fact that the purchase decision has to be made strictly before negotiation with the sellers. User constraints, which have to be signed before these negotiations, therefore need to be pure data. However, it is desirable that a decision function be executed after or during the negotiation or bargaining process. This means that agents should be capable of deciding what to buy, where to buy, under what conditions, price, type of payment, delivery options, etc. For example, the user demand should be able to be stated as flexibly as possible with I would like to purchase as many blank rewritable CDs as possible and Ive got $100. The result of the decision function will have a direct effect of the contract to be signed. Therefore what we need is to make the agents capable of computing with

PAGE 72

60 secrets in public as the quoted sentence in the previous paragraph implies. Without this capability, either the user must have a perfect knowledge of market conditions that might change rapidly, or user interaction during the mission is necessary. In the former case it is highly possible that the mission may fail, in the latter, autonomy is sacrificed. The problem arises from the fact that a malicious host should not be able to manipulate or directly use the agent in order to sign arbitrary documents. On the other hand, agents should also be capable of preparing the documents to be signed. The challenge is to resolve this contradiction. A threshold signature scheme in conjunction with the use of multiple agents and an undetachable threshold signature scheme, which combines undetachable signatures with threshold signature schemes, have been proposed (see Borselius et al. (2001) and further references). While the former is vulnerable to attacks when used alone the latter still carries the concerns with threshold signatures. First concern is that threshold signature schemes come in great variety. They are neither standardized nor widely accepted. This means that MAs may face problems in finding the hosts to execute, which would have standardized implementations of these schemes. The second concern is threshold signature schemes tacitly assume that there would be sufficient number of shareholders to sign a document. Even small values of this sufficient number may not be feasible for MAs since in practice, existence of hosts for MAs to execute on, finding those hosts and location of them in the underlying network are problems as will be explained later. So, threshold schemes are reduced to multisignature schemes by these restrictions. Nevertheless, their complexity remains.

PAGE 73

61 4.7 Multiple Cryptography Multiple cryptography, as the name implies, covers the cryptosystems that deal with more than two parties as opposed to the classical cryptography where there are only two parties: the one who encrypts or signs and the other who decrypts or verifies. In fact, there are many real-world applications that have multiple parties involved. For example, in a banking application, electronic fund transfers require approvals of bank officials of different ranks. Usually, at least two people are involved for a single transaction. Ironically, this is such an application that, in the digital world, a more realistic abstraction of the real world than the real world itself may be possible. Using the same example, a bank cannot have a signature. Only people who work for the bank have signatures, and they sign on behalf of the bank. But with multiple cryptography, it is possible to assign a key to the bank, and shares of this key with the individuals who work for the bank. When these officials sign a document like a check, the signature they generate perfectly represents the bank itself, but not the individuals who really signed the document. So as the example implies, it is possible, with multiple cryptography not only to share the secrets but also compute with them without regenerating the secrets. Our focus in this chapter is on multiple digital signatures or multisignatures, which are a special case of multiple cryptography. The term refers to digital signature schemes, which enable multiple parties to sign documents or messages cooperatively but independently of each other using keys or shares of a key generated for this purpose. Boyd (1988) shows the generalization of RSA and use it as a multisignature scheme. A brief explanation of Boyds work, which is related to our application, will be given later. Multiple cryptography, in general, is intended for classical applications (e.g., a banking application). In these applications, shareholders are usually individuals who

PAGE 74

62 represent an organization or a company. There is an important distinction between these applications and the MA applications. MAs are nothing but software entities. They are neither organizations nor individuals. Moreover, they are owned by individuals or organizations. In fact, it can be argued that, the MA owner and a bank have some kind of resemblance. So, the officials of the bank and the MA perform similar operations when signing a document. While this is not wrong, the actual difference comes from the fact that, MA owners are active players, while organizations or companies like a bank are not. A bank is actually an abstraction and cannot for example sign a document. But in the case of a human MA owner, this individual can equally sign documents him/herself. Also, the shareholders do not always exist. They are created when necessary and after they complete their work they cease to exist. In addition to the threshold schemes like Shamirs (1979), techniques which are known as threshold cryptography for the purpose of not only sharing keys but also being able to compute with them without a central authority, have been proposed. A survey of research in this area was provided by Desmedt (1997). A threshold multisignature scheme has been given by Frankel and Desmedt (1992). In this scheme, authors combine RSA signature scheme by Rivest et al. (1978) together with Shamirs (1979) threshold scheme to distribute and to sign documents with shares. It is also possible to generate the shares of a secret in a distributed fashion, which enables the shareholders to compute their own shares without the necessity of a central authority. An example using RSA is given by Boneh and Franklin (1997). The threshold multisignature schemes are in fact the generalization of the multisignature schemes. While key sharing is k-out-of-k in the latter,

PAGE 75

63 it is t-out-of-k in the former, which means that t of the total of k shares are enough to generate signatures. Nevertheless, threshold schemes do not have specific advantages over simple secret splitting techniques we are using, with MAs. While it is feasible to use these secret splitting schemes to both share the keys and compute with them, it is also feasible to come up with very simple techniques to create multiple combinations of keys for providing fault-tolerance, as demonstrated by Wu et al. (1999). On the other hand, in our application, secret splitting has two important advantages: simplicity and ubiquity. We use very simple secret splitting schemes, which use only addition and multiplication. The secret splitting schemes we use require nothing but the implementations of the standard public key cryptosystems, namely, de facto industry standard RSA and the official Digital Signature Standard (DSS), which is based on El Gamal public key scheme. So, these schemes do not need any new algorithms or an implementation of those algorithms. It should also be noted that what makes it possible to use these simple secret splitting schemes with the El Gamal cryptosystem and DSS is the unique property of the application that the whole secrets and all of the shares are to be computed and known by the MA owner; therefore it is possible to perform computations in advance to be used later when the complete signature is computed. Details of these computations are given in the next section. 4.8 Key Splitting and Signature Generation Boyd (1988), by using the multiplicative property of RSA, showed that the classical RSA is actually a specialization of a general multisignature scheme. For an RSA implementation for sequential signing, we will use this property. Boyd (1989) also mentions about a similar technique, which enables to perform signature generation in

PAGE 76

64 parallel. This is the RSA part of the techniques we will use in parallel signing. Note that, both techniques use nothing but original RSA signing and verification algorithms. The RSA implementations, which are standardized and used in practice, and their implications on remote digital signing will be discussed later in the chapter. In the following, we present techniques to do the same with El Gamal Cryptosystem, which again use original signing and verification procedures, by using a property that is unique to MAs, as explained. 4.8.1 Using the Multiplicative Property of RSA Classical public key cyptosystems use two keys, one is the public key and the other is the private key. It was shown by Boyd (1988) that this is only a specialization of a general multisignature scheme in the case of RSA. This is possible since RSA has the multiplicative property, namely, with the same modulus and two decryption keys and 1d 2d 2121,,,ddmSddmSShh where S is the signing function and m h = h(m). Here, m is the document to be signed, h is an appropriate cryptographic hash function (i.e., SHA-1) and m h is the message digest. Note that, for clarity we defer the discussion of recent advances in theory and practice of computing the message digest m h for better security of RSA signature scheme until Section 8. The modulus n is still the product of two large primes p and q. However, unlike classical RSA, which has two keys e and d that are encryption and decryption keys respectively, in this scheme 1 k keys are chosen randomly and then the key is chosen to satisfy the property thk

PAGE 77

65 mod1121edddk The encryption key is e and when the d i s multiplied together the result is the decryption key d. So, with three partial keys and three agents can sign a document with 21,dd 3d nmmXdhdddhmod321 which can be verified by nmXedhemod 4.8.2 Using the Additive Property of RSA Boyd (1989) mentions an alternative scheme to overcome the difficulties of multisignatures with more than two signatories (e.g., different users). In the context of multisignatures it is possible to assign different keys to different users, and signing process can be done in parallel. Resulting signatures are then combined. Using the same scheme, it is also possible for our purposes to split up a key by addition instead of multiplication assuming three signatories as follows 321dddd Each agent is provided with one of the partial keys and When it is time to sign a contract, they are either provided a copy of the original contract or they prepare the same contract depending on the application (see Section 4.9). 21,dd 3d Then they sign by nmSnmSnmSdhdhdhmodmodmod321321 Note that, the message digest m h above is computed as mentioned in the previous section.

PAGE 78

66 Signatures S 1 S 2 and S 3 are sent back to the server where the signatures are required. The server computes nmnmnmmmSSSdhdddhdhdhdhmodmodmod321321321 Therefore, the server can also verify the signature by nmSSSedhemod321 The scheme can be generalized for n signatories in the obvious way. 4.8.3 Using El Gamal Public Key Cryptosystem Here we use a variant of the original El Gamal signature scheme as given by Kaufman et al. (1995). There are two reasons to do this. First is, this scheme is simpler and it is easy to compute with partial keys. The other reason is that, the scheme is actually the El Gamal version used in DSS, which in turn is based on the original idea introduced by El Gamal (1985). So this scheme will enable us an easy transition from El Gamal to DSS. The El Gamal variant that we use is summarized below (Kaufman et al., 1995): Long term public key: , secret key: S, where g S mod p = T For a message m choose random number r, compute g r mod p = T m and message digest d m (digest of m | T m ) Sign with X = r + d m S mod (p 1) Verify by pTTgmdmXmod In the following sections, we use Figure 4-1 to illustrate the signature generation scheme. There are three mobile agents, Alice, Bob and Carol. Alice is the master agent and the others are support agents. Figure uses the same mission model developed in Chapter 3, however, for clarity only a snapshot of the mission is shown.

PAGE 79

67 Host AHost BHost CDomain ADomain BDomain C Alice Alice Alice Bob Bob Carol Carol Host Host Host Host Host Host Host Host Figure 4-1. A snapshot of a mission using multiple mobile agents 4.8.3.1 Signing in sequence with El Gamal signature scheme The El Gamal cryptosystem uses a pair of private keys as opposed to RSAs single key. The first one is the long term key as in the RSA. The second is a short-term, per session, private key for each message to be signed with the long-term key. We split up both of these keys as follows: Long-term key: cbaSSSS (1) Short-term key: cbarrrr (2) Here we assume again that our MA group consists of three agents, namely, Alice, Bob and Carol. Alice is the master and the others are support agents. To sign a message, Alice computes the message digest and signs with md 1mod pSdrXamaa (3) Note that, the message digest d m here is the result of an appropriate cryptographic hash function H applied to the contract m concatenated with T m : d m = H(m | T m ) (4)

PAGE 80

68 where T m = g r mod p as given above. In sequential signing, Alice is the only agent, who needs T m and it is assumed here that she is provided by this value before the mission takes place. Then, she sends her partial signature to Bob. Bob, upon receiving Alices signature aX further signs it with his portions of partial keys as 1mod1mod pSSdrSrpSXrXbamabbbabb (5) Carol does the same on which represent the partial signature generated by Alice and Bob, bX 1mod1mod pSSSdSSrSrrpSXrXcbamcbacbccbcc (6) Unfortunately, this last equation above, unlike the RSA counterpart, is not equal to the signature X, although the last term of the equation is nothing but the last term of the original signing equation: SdSSSdmcbam (7) This leads us to the observation that the difference between the target signature X and the signature generated by the three agents X c is 1mod11 prSSrSXXacbbcc (8) Since the right hand side of the equation consists only of constants and partial private keys, it can easily be computed and given to agents before they are sent out to the network. This ability is unique to the application that we consider in this chapter. In the classical applications of digital multisignatures and threshold signatures, it is not possible to perform the same computation since the signatories are distinct parties and the secrets

PAGE 81

69 they share cannot exist in a single site as a whole. So the last agent in the row, Carol, sends the partial signature X c to Alice. Alice computes X, the target complete signature by using the equation above. The general difference equation for n signatories is 1mod1111pSrXXntntkktn (9) 4.8.3.2 Signing in parallel with El Gamal signature scheme Signing in parallel with the same variant of El Gamal cryptosystem is also possible and even easier. For this purpose we split up the keys as follows: Long-term key: cbaSSSS (10) Short-term key: cbarrrr (11) Then, each agent is given the partial keys as well as T m = g r mod p since all of the agents will need it to compute the message digest d m = H(m | T m ) where m is the contract to be signed and H is an appropriate cryptographic hash function. They sign independently of each other as 1mod,1mod,1mod pSdrXpSdrXpSdrXcmccbmbbamaa (12) and the support agents send their partial signatures to the master agent. Together with the master agents signature, the server combines the partial signatures and obtains the complete signature as follows SdrSSSdrSdSdSdrrrXXXXmcbamcmbmamcbacba (13) The scheme can be generalized to n signatories in the obvious way.

PAGE 82

70 4.8.3.3 Transition from El Gamal cryptosystem to digital signature algorithm While RSA is the de facto industry standard of public key cryptography, the Digital Signature Algorithm has been proposed as the official standard as Digital Signature Standard (DSS) by US National Institute of Standards and Technology. It is based on the original idea of the El Gamal public key scheme and is very similar to the variant of the El Gamal cryptosystem. We will neither provide the details of DSS nor the details of the signature generation by partial keys. However, we will give the differences between the El Gamal scheme presented in previous sections and DSS. The signing equation in DSS is given by qTSdrXmmmod1 (14) where 1 r is the multiplicative inverse of Therefore it can be calculated in advance and instead of splitting up r we can just as easily split up qrmod 1 r Signing in sequence with DSS. The key splitting is performed as follows: Long-term key: cbaSSSS (15) Short-term key (inverse):. (16) cbarrrr1 The signing process is very similar to El Gamal scheme. However the difference in this case is given by mccabbbcacTSrrrSrrrXX11 (17) For n signatories (i.e., agents), the general difference equation is 111111tntwwnttkkmnSrrTXX (18)

PAGE 83

71 Signing in parallel with DSS. The key splitting, signing and signature combination calculations here are very similar to the El Gamal scheme. However, the combined value is not equal to the target complete signature X. Therefore we call this value X and the difference is given by baccabcbamSSrSSrSSrTXX (19) For n signatories (i.e., agents), the general difference equation is .11ntntkkktmnSrTXX (20) 4.9 The Overall System for Remote Digital Signing As presented in the previous section, there are two major multi-signature schemes: sequential and parallel. Figures 4-2 and 4-3 provide the overall system of signing and verification processes as part of an MA mission, for sequential and parallel signature generation schemes, respectively. In this section, we discuss these protocols, compare them with respect to assumptions made and the analysis of attacks possible against each scheme. Please note that, in this chapter we do not address fully the overall security issues necessary for a whole MA mission. Signature generation is actually an integral part of the whole mission. However we provide the protection mechanisms when necessary in addition to the signature generation process to make this process more meaningful.

PAGE 84

72 Host AHost C Alice Alice 1 2 10 3 3 6 8Server Bob Bob Carol Carol 1.Alice asks the Server for a bid for her demand2.Server provides Alice with its offer along with its signature for the contract3.Alice sends the servers bid along with its signature to Bob and Carol4.Bob and Carol verify the servers signature5.Bob prepares the contract and signs it with his part of privatekey6.Bob sends the partially signed contract CBto Carol7.Carol signs the contract, partially signed by Bob, further withher partial key8.Carol sends the partially signed contract CBCto Alice9.Alice, with her partial key, further signs the contract and obtains the fullysigned contract CABC10.Alice delivers the signed contract CABCto the server11.Server verifies the contract using the public key of the user 11 9 5 4 4 7Host B Figure 4-2. Protocol for sequential signing with multi-agent model In both of the protocols, the first part is to obtain the bid of the server along with the signature for this offer and then verify this signature in steps 1 through 4. After Alice obtains servers signature, she sends it to both Bob and Carol. Signature verification is carried out by both Bob and Carol independently on different hosts in different domains. It would not make sense to let Alice verify the signature since Alice is under complete control of the very same host that made the offer. Step 5 in Figure 4-2 contains the contract preparation process performed by Bob. The protocol assumes that Host B does not have any interest in forging the computation as does Host A. Although the chances are low, this assumption is not enough for a convincing level of security, since a denial-of-service attack by Host B is possible. This is due to the drawback of this protocol that there is no way to check whether the contract signed by the first agent in the row is correct. This is true regardless of the fact that the decision function is executed in cooperation with all the members of the group. However, this drawback does not make

PAGE 85

73 the protocol totally inappropriate because even an attack cannot be prevented, it would be detected in Step 11 when the host attempts to verify the signature. Nevertheless, it is not possible to tell which host is cheating. The parallel signature generation scheme does not have this drawback as we see next. 1-4.Same as Figure 4-25.Alice, Bob, and Carol prepare the contract and sign it with their part ofprivate key and each obtain CA,CB, andCCrespectively6.Bob sends the partially signed contract CBto Alice, Carol does the samewith CC7.Alice, combines CA,CB, and CC, and obtains the fully signed contract CABC8.Alice delivers the signed contract CABCto the server9.Server verifies the contract using the public key of the user Host AHost BHost C Alice Alice 1 2 8 3 3 6Server Bob Bob Carol Carol 9 7 5 4 4 5 5 6 Figure 4-3. Protocol for parallel signing with multi-agent model In Figure 4-3, Step 5 states that all agents prepare the contract to be signed. This is possible since Bob and Carol receive the servers offer from Alice. Furthermore, any decision function that needs to be executed to reach the decision for actual purchase is shared by three agents and executed in cooperation. However, it is also possible for any one agent to prepare the contract and communicate it to the others. Once the contract is obtained either way, agents sign it with their shares of the private key for the chosen algorithm as described previously. Step 6 says that Bob and Carol send their signatures back to Alice, and in Step 7, Alice combines them to obtain the fully signed contract. This means that combining the partial signatures takes place in the host where Alice resides. This is because there is no trusted authority to ask for this computation. But for

PAGE 86

74 the application under consideration, there is no need for it either, since there is no known attack possible. 4.10 Using Limited-liability Keys and Public Key Certificates Our multi-agent model provides a high level of security by making it difficult to compromise all the agents, which together form an autonomous group. However, the secret, which is a private key of the agent owner, is an extremely sensitive piece of information. Revealing users shopping preferences or losing electronic cash is certainly undesirable, but in essence a part of our daily lives since we have just enough security to protect these valuables. But a forged signature under a document may mean anything and may not be tolerable or acceptable. So even a very small chance of the whole group of agents being compromised may not be acceptable since the consequence of this malicious action is revealing the private key of the user. Therefore we define two types of public/private key pairs as follows. Long-term public/private key pairs: These are the long-term keys, which are created, registered and assigned to the user (who becomes the owner of the keys) by a Certificate Authority (CA). The lifetime of these keys are again decided by the same authority. Limited-liability public/private key pairs: These are the short-term keys, which are created by the very same user (owner of the keys). Since the creators of the keys are the users themselves they also are the authority to decide the lifetime of the keys. There are two limitations that can be imposed on the limited-liability keys. The first one is the lifetime of the key and the second one is what can be done (i.e., signed) with these keys. Both of these limitations can be flexible or restrictive and is up to the owner of the keys. For example, the lifetime of a key may vary from a single MA mission,

PAGE 87

75 which may be limited to a couple of minutes, to a total of a couple of days that spans several different missions. Liability definition says what exactly can be signed with these keys. For example, a typical definition may say that these keys can only be used in an m-commerce transaction and the amount that could be involved in such a transaction cannot exceed $500. The other type of limitation that can be imposed is the type of the transaction. For example, it can be stated that, with these keys only one mobile phone, one color printer or one DVD player purchase contract can be signed. The problem with this scheme is the authenticity of this new pair of keys. One possible solution would be to register this pair of new keys with a CA and obtain a certificate, or ask the CA directly for a pair of new keys. Nevertheless, this solution does not make much sense, since this introduces an overhead of obtaining a new key for every single transaction from a CA, which could easily become unmanageable. Instead, the user creates this key and a certificate for this key by using his/her long-term key. The idea is that the user obtains only a single public key and a certificate for it from a CA. Using this certificate and public key, it is possible for the very same user to create and use unlimited number of other public keys. The key point here is that these new keys are certified by their owners. That is, the user in essence becomes a CA for the agents he/she sends on missions. It may seem at first that the scheme explained in this section provides enough security for the limited-liability private key. This is due to the fact that what can be signed by this key is restricted by the certificate provided for it. However, it is not so for two reasons. First problem is the same problem that the undetachable signature schemes have as explained previously, which is the difference between the limitation of what can

PAGE 88

76 be signed and what actually is signed. A certificate can only enforce what can be signed with the key, for which it is issued. But in fact, it is necessary for agents to be able to engage in transactions with the most favorable choices. For example, a certificate may allow for a purchase of up to $500. However, this should not mean that the agent would accept an offer of this amount. If the servers original bid is $300, then the server should not be able to enforce the agent to involve in an agreement for the allowed full amount of $500. The second problem is that an attack is possible by any host visited. Any such host for example might learn the complete limited-liability private key from agent Alice, and then can sign a contract to sell something. Also, even if the support agents are involved in the decision function to be executed, this is not enough since a single agent who possesses the complete key could be manipulated. In short, this scheme when used alone could open a can of worms. Therefore, the limited-liability keys are protected by splitting them up and giving them to members of a group of MAs. Their usage, on the other hand, is protected by the certificate created by the user using the long-term key. The complete protocol for using the certificates and limited-liability keys for agents is given in Figure 4-4. In the protocol, P and S represent the long-term public and private keys respectively and p and s represent the limited-liability keys. The protocol assumes that user already has P and S. Note that P, S, p and s, are symbols for the private and public keys, for example in the case of RSA, P and p indicate (E, N) and (e, n) respectively. The certificate contains p and the description of the liability. Any document, which is signed with s and therefore can be verified by p, should conform to this description to be valid.

PAGE 89

77 Note that a certificate chain that would also include CA's certificate for (P, S) rules out the necessity for the server to connect the CA and ask for verification. 1.User creates (p, s) or uses a pre-computed pair of keys2.User splits up s, using one of the techniques mentioned3.User prepares a certificate and signs with S4.Server uses Pto verify the certificate and obtains the identity of the user and p5.Agents sign the contract with their shares of s6.Server verifies this signature using p Figure 4-4. Limited-liability key protocol Now lets look at what can and cannot be accomplished with these limited time and liability keys and what can go wrong. The analysis involves three parties that can act maliciously; agent owner, the host to which a signature is provided, and third parties, which could presumably acquire the limited-liability private key. Since the private/public key pair is arbitrary, meaning that they are neither created nor registered by a CA, the host on which the transaction took place may sign a contract that states that the agent purchased 500 mobile phones for the price of $100 each. Since the host also knows the credit card information of the user, it can perform a transaction and bill the users credit card for this transaction. The solution to the dispute requires the proof of the users demand for this kind of purchase. But the certificate which is signed by users long-term private key pair states that the transaction amount may not exceed $500 and it is only valid for a purchase of a single mobile phone. Therefore there is no way for the host to prove such claim. Now, suppose that a third party was able to compromise all the agents in a group and therefore acquire the limited-liability key. Then this party could sign an arbitrary contract on behalf of the user by masquerading as the user. In this case, however, it is not possible to bind the user to this contract since there is no certificate signed by the user

PAGE 90

78 using the long-term private key. So, such signed document is invalid because the user can deny it rightfully. Third attack involves a malicious user, and is known as non-repudiation problem. The user cannot deny a contract that states a purchase demand that conforms what is stated in the certificate signed by the users long-term private key. This is what we expect since this is the aim of the certificate and is completely legitimate. Also, the user cannot deny the legitimacy of a contract by claiming that the contract was signed after the limited-liability key had been expired. That is because agents are supposed to check whether the expiration date and time has passed. On the other hand, as explained in the previous paragraph, the user can deny any illegitimate contract signed by the limited-liability key that does not conform to the certificate. Another similar attack might be possible, if an attacker creates and uses a limited-liability key by also creating a fake long-term key without registering this long-term key by any CA. Then the attacker prepares a certificate for the limited-liability key using this fake long-term key. The last step for the attacker is to let the agents engage in transactions and then deny their existence. These transactions may or may not conform to the certificate prepared. So, the merchants/sellers should always check the legitimacy of the short-term keys by checking the certificates prepared for them, as well as the legitimacy of the certificates by checking the long-term keys used to prepare them possibly consulting the CA, if not provided. 4.11 Practical Issues of Remote Digital Signing In this section we examine the issues related with using the Remote Digital Signing in practice. First we look at the issues related with the security level and robustness of the multisignature schemes by discussing the recent theoretical advances in digital signatures, their impact on implementations in practice and particularly on remote digital

PAGE 91

79 signing. Then, we look at the broader picture of multiple MAs paradigm and discuss the performance issues that might arise in practice and how to address them. 4.11.1 Probabilistic Signature Scheme and its Impact on Practice Probabilistic Signature Scheme (PSS) has been proposed by Bellare and Rogaway (1996). It is applied to the hashing but the signature generation is the same. The idea is to mix the document to be signed with a random salt in a specific way and the result is a better security proof. This is due to the fact that security of PSS can be tightly related to the difficulty of inverting RSA. We refer the interested reader to Bellare and Rogaway (1996) for details. As the name implies, PSS is probabilistic rather than deterministic, which is the case for classical RSA commonly in use today. The scheme has practical importance and has been adopted by the RSA Corporation as a standard (PKCS#1, 2002). Unfortunately, the scheme is not applicable in environments where deterministic signature generation is necessary. In our case, it is applicable to sequential signature generation using RSA since signature generation is initiated by a single agent and appropriate hashing is only performed by the same agent. The other agents (i.e., support agents) therefore need not know the random salt value used and can apply their keys to the signature function. However, parallel signature generation with RSA requires a deterministic scheme since all the agents need to know or be able to generate the same random salt. The issue is important since our main concern is to use standardized and widely implemented and used schemes like RSA. The random salt value in PSS enhances the security by providing a tighter security proof. However, in practice, randomness is not critical to security (PKCS#1, 2002). In our case, parallel RSA signature generation is still feasible by providing a fixed value to the agents or have them compute the same value and use it when it is time to generate the underlying message digest to be signed.

PAGE 92

80 Furthermore in our scheme, the lifetime of the keys and their applicability can be extremely restricted due to the use of certificates issued for them. So, the probability of forging the signatures is extremely low and it is difficult to justify the efforts to do so. Some theoretical research results however lead us to question the probabilistic schemes like PSS. Recently, Katz and Wang (2003) showed that an equally tight security proof of PSS could be constructed in a deterministic way. The idea is to use a single bit (0 or 1) instead of a random salt value when generating the hash value. This variant of PSS may render the current proposed standardization of the original PSS obsolete, which is not convenient in environments where random generation is not possible or is not preferred as in the case with parallel signature generation presented. 4.11.2 Performance Considerations and the Big Picture Remote digital signing is in fact a part a new computation paradigm of multiple MA systems. Among many issues of this big picture, performance considerations deserve specific attention since multiple agents introduces additional communication to the classical single agent model. The immediate result follows as more communication overhead to the underlying network and degraded performance observed by the user. Network-awareness in general and specifically network distance estimation are hot research topics and aims at assisting applications, which would benefit from being aware of the underlying network characteristics and conditions. Multiple MAs are such an application area where network-awareness as well as context-awareness, which also addresses security considerations, is important. For example, choosing hosts to send the agents randomly increases the security risk of conspiracies against them. So, hosts to be chosen need to be in different administrative domains and should not have common interests to alleviate this risk. The goal, therefore, is to find the best possible combination

PAGE 93

81 of available hosts under the restrictions mentioned above, which are (in terms of network distances) close to each other. This not only addresses the performance but also the security since vulnerability of the agent communications over the network reduces. These issues are the subject of following chapters. One last remark on performance issue is the subtle difference between the client/server paradigm and the MA paradigm in general, regarding user expectations. The applications of the MA paradigm, which is in fact a special case of the multiple MAs paradigm are not user-interactive as is the case for client/server systems. Users do not expect immediate results from their MAs and it is in that aspect that constitutes the foundation for enabling disconnected operation. Therefore, performance penalties should be observed in a more relaxed fashion than it should be in the traditional client/server computing. 4.12 Conclusion Mobile commerce is a rapidly developing field of electronic commerce. Mobile devices and wireless networks, which make the mobile commerce a reality, however are not developing at the same pace. It can be expected that the limitations of these technologies will be with us several decades from now. MAs are distinguished candidates to tackle this problem. Although benefits offered by this technology are well understood by now, especially in the mobile commerce field, security and interoperability are two main concerns of this technology. It is also well understood that without proper security mechanisms in place, MAs will not be accepted. So, advances in MA security area will directly affect the future of mobile commerce applications.

PAGE 94

82 This chapter carefully examines the implementation of remote digital signing, which is a special case of computing with secrets in the public domain, within a larger picture of supporting multi-agent computing. The solution approach is based on secret sharing and the concept of protection as a whole. In addition to well-known multiplicative and additive properties of the RSA, similar techniques with El Gamal public-key cryptosystem are demonstrated to show their applicability in the MA systems. Although threshold multisignature schemes fit well into the application, it may not be feasible and even reasonable to provide the implementations of these schemes to the MAs. Moreover, the advantage of the techniques we presented in this chapter is that they use nothing but original signing and verification algorithms of RSA and DSS, which are well known and widely used. In this sense, these simple schemes address the ubiquity in a large scale MA execution environment like the Internet. The MA security problem is not limited to signature generation, however. In fact, signing a document is supposed to be a part of an MA mission. A complete solution to the problem of protection against malicious hosts is still to be addressed in our future work. However, as we have presented in this chapter, even the most challenging part of the problem, computing with secrets by MAs, is feasible using the multi-agent model. It is shown that both parallel and sequential signature generation schemes are possible. There are important properties of each scheme. The former one provides data integrity since each agent in the group signs the original document, therefore can check its integrity. However, in this scheme there is no confidentiality for the document to be signed. The latter scheme provides data confidentiality only if signing process begins at the server, where the master agent is being executed. The other hosts, where the support

PAGE 95

83 agents are running, can not see the document in clear, assuming the partially signed documents have enough strength against cryptanalysis. The schemes presented in this chapter therefore address authenticity rather than data confidentiality. In this chapter, while applying information dispersal to mobile agents to accomplish digitally signing contracts in the public, our tacit assumption was that we could position these agents in the hosts over the network; this positioning as well as the mission as a result of it would be feasible. In the next chapter we examine this positioning problem to show that it is feasible to identify the best host locations to realize the information dispersal with multiple mobile agents.

PAGE 96

CHAPTER 5 A NETWORK POSITIONING ARCHITECTURE FOR MOBILE AGENTS 5.1 Introduction Applications that can benefit from being aware of the underlying topology and the network distance information are numerous. For example, in a web caching system, clients of the system may choose the best location among the alternatives to obtain the cache copies. Similarly, the location information is obviously useful in placing WWW/FTP mirror sites in different areas on the network. In such a replica system, clients may need an automated mechanism to choose the best mirror site based on topology information. The problem of addressing this requirement for such applications is known as the server selection problem. Another important application area is in the design of content addressable networks (Ratnasamy et al., 2001) and overlay networks (Stoica et al., 2001). These systems require transformation of logical network topologies from an underlying physical network. In general, any content provider or peer-to-peer (p2p) file sharing facility (i.e., Napster and Gnutella) requires topology information for the best performance, which otherwise may not be observed. Many other topology-aware applications have been explored in literature (Ratnasamy et al., 2002). Different from the applications described above, our interest in developing a network positioning model came from the need for supporting a multiple mobile agent system. 84

PAGE 97

85 The proposed positioning model is a p2p coordinate-based system, which maps a physical host location to logical coordinates for efficient on-the-fly logical distance (e.g., communication delay) estimation between any two hosts in the system. 5.2 Related Work Much like time services in distributed systems, distance services can be provided by some servers or obtained collaboratively by some participating hosts. The IDMaps (Francis et al., 2002) is an example of the former case. This approach uses triangulation heuristics combined with a centralized, client/server architecture. Examples of the latter case are the coordinate-based Global Network Positioning (GNP) (Ng & Zhang, 2002), the Lighthouse (Pias et al., 2003) and the binning (Ratnasamy et al., 2002) approaches. The GNP and binning strategies use the concept of landmarks, which are introduced by Hotz (1994). In GNP, coordinates are computed by modeling the Internet as a geometric space. Some hosts in the system are identified as landmarks. These landmarks first measure their distances to each other and then compute their coordinates by minimizing the error between the measured and the computed distances (see Step 4 in Section 5.3.1 for details). This results in approximate distances as represented by the coordinates among landmarks. An ordinary host can measure its distance to these landmarks and use the landmarks coordinates to compute its own with the same minimization technique. Figure 5-1 illustrates two hosts A and B, which compute their coordinates using the global landmarks L1, L2 and L3. From there on, A only needs to ask B for Bs coordinates to obtain the distance to B. The GNP is a p2p architecture as oppose to the IDMaps central servers approach.

PAGE 98

86 L1L2L3 AB Figure 5-1. Global network positioning model (GNP) In the binning strategy, rather than utilizing coordinates, hosts measure their actual distances to the landmarks and place themselves in a bin based on the sequence of sorted distances to the landmarks. The idea is that hosts, which are close to each other relative to the other hosts, will have similar sequences and therefore will be placed in the same bin or in a similar one. The binning strategy assumes that fine-grained reduced errors between measured and predicted distances do not have a considerable effect on the application performance. As a result it is possible to make distance comparisons by using less information namely, only a sequence of estimated distances to a set of landmarks. However, the approach is not as flexible as the coordinate-based approaches. This is due to the fact that in the binning strategy bins are tightly bound to the landmarks, whereas in coordinate-based approaches the coordinates and the landmarks are relatively loosely coupled. The Lighthouse approach (Pias et al., 2003) shares the same idea of eliminating the landmarks to achieve scalability, as the proposed approach in this chapter. The scheme uses a transformation matrix maintained by the hosts for making conversions between the

PAGE 99

87 global and the local bases. However, the approach does not address the practical implications, namely, it is not clear how the global basis is formed and the definition of the local basis is not consistent with the positions of the hosts since the hosts are picked arbitrarily. Moreover, every host that wants to participate needs to create a local basis. While it is also not clear how to find a host that is currently participating in the system, it does not bring any advantage over GNP in terms of accuracy of the distances. The results of GNP study (Ng & Zhang, 2002) show that, the coordinate-based approach provides better estimation of distances than the IDMaps. It is also more accurate and robust due to its p2p architecture when compared to IDMaps. However, this approach has its own drawbacks. First, the landmarks must be globally distributed to the entire Internet to accurately measure the distances between two arbitrary distant hosts. But the distance estimation between two local hosts is biased with the coordinates of the widespread landmarks, which are not local to the given two hosts. Second, these landmarks are central points of failure and may become target of attacks. Third, where to locate the landmarks, how many landmarks there should be and how/where to move the landmarks or add new ones as the Internet topology changes and grows are important open scalablity problems. Finally, there is a security concern of the system. The authors point out that (Ng & Zhang, 2002) this system may not be suitable in an uncooperative environment since there is nothing to prevent a host from lying about its coordinates for being chosen or not chosen depending on the application. To address these shortcomings we propose the coordinate-based Pure Peer-to-Peer Network Positioning (Triple-P NP or TPNP) architecture, which completely eliminates the landmarks and the problems they introduce.

PAGE 100

88 5.3 TPNP Approach The idea of TPNP is similar to the basic principle of dynamic distance vector routing, except that hosts do not need a global picture (i.e., a routing table) of the network. A host that is interested in participating the TPNP system first discovers the nearby hosts that are already in the system to use them as reference hosts, which replace the landmarks for the host in question. Then, the host contacts these references to compute its own coordinates (see Section 5.3.1). Figure 5-2 illustrates the same hosts A and Bs (from Figure 5-1) coordinate computation process. A uses three other ordinary hosts C, D, and E already in the system, and B uses F, G, and H locally. These hosts, which are already in the system, are not shown in Figure 5.1 for clarity. As shown host C may have used three other locally positioned ordinary hosts for computing its own coordinates. (L2)(L3)AB (L1) CDEFGH Figure 5-2. Local network positioning model (TPNP) Unlike GNP or any other global positioning system local measurements as of TPNP are likely to give more accurate results between local hosts. There are two

PAGE 101

89 important facts that support this argument. The first one is that the network traffic of hosts that are close to each other in terms of network distances tend to be routed the same way in most cases. For example, suppose we are interested in measuring the distances between two hosts in Asia. Landmarks, in Europe or North America would not contribute to the accuracy of the estimation. For instance, congestion happened in North America will not affect the end-to-end delay in Asia. In fact, those landmarks at distant locations may have a negative effect on the accuracy. In the global case, we show that the local measurements will have at least, comparable accuracy to that of GNP. For the other fact suppose there are two hosts in the same region (i.e., a country) and the network traffic originated from these two hosts to outside of the region follow different paths, which might have different characteristics (e.g., bandwidth, delay, average load). So, the coordinates of these two hosts that are computed relative to the globally distributed landmarks may seem totally unrelated (i.e., far away). However the hosts may be connected with a reasonably fast metropolitan area network, which makes the distance between the two very small. Majority of the positioning systems including the ones, which are based on coordinates, do not require on-line distance estimations. In fact, this is one of the major advantages of coordinate-based systems. To figure out the distance between any two hosts in the network, all we need to know is the coordinates of these hosts. However, the Internet is an extremely dynamic ever-changing environment. Therefore, the coordinates should be recomputed by the hosts periodically in order to reflect the changes to provide up-to-date distance/delay information. The next subsection presents the algorithm for a

PAGE 102

90 host to join the system. Recomputing the coordinates of an already participating host is very similar and therefore is not given. 5.3.1 The Algorithm The steps of the basic algorithm to join in the TPNP system by a host are: 1. Discover nearby hosts that are already in the system. 2. Select a subset of the hosts discovered. 3. Measure distances (i.e., delay) to every selected host. 4. Compute own coordinates. 5. Store and advertise own coordinates. Step 1: Discovery. The discovery algorithm is given in Figure 5-3. The algorithm uses IP-multicast. Two types of messages are used: Multicast message: an IP packet indicating a TPNP inquiry with a specified Time-To-Live (TTL) value. Response message: an IP packet, with a payload of: 1coordinates of the responding host, 2coordinates and IP addresses of the reference hosts of the responding host. The algorithm gradually expands the multicast ring to find necessary number of reference hosts. The first phase of inquiry process takes place in lines 01 through 10. If the predetermined number of hosts cannot be found and the threshold value for the multicast depth is reached, lines 14 through 18 are executed to check whether at least one reference host was found. If this is the case further references of the reference hosts are also to be used by the current host. If the current host found that there was no candidate reference hosts then the multicast ring is expanded by using multicast depth values between d thresh and d max

PAGE 103

91 DEFINE Hr : set of hosts that replied to the current TPNP inquiry Hn: set of newly discovered hosts responded to the current TPNP inquiry N TPNP : number of reference hosts to be used globally in TPNP d : multicast depth d init : predetermined initial value of d d thresh : predetermined threshold value of d d max : predetermined maximum value of d t inq : response wait time for the inquiries 01 Hr ; 02 d = d init ; 03 REPEAT 04 Hn ; 05 multicast an inquiry message with TTL = d; 06 wait(t inq ); 07 check responses; 08 ; HnHrHr 09 increment(d); 10 UNTIL threshTPNPddORNHr ; 11 IF TPNPNHr 12 RETURN(Hr); 13 ELSE 14 FOR EACH (i) responding host in Hr 15 FOR EACH (j) reference host used by Hr i 16 IF HrHr ij 17 Contact Hr ij and obtain reference host info; 18 ijHrHr Hr 19 IF Hr 20 REPEAT 21 Hn ; 22 multicast an inquiry message with TTL = d; 23 wait(t inq ); 24 check responses; 25 HnHrHr ; 26 increment(d); 27 UNTIL max1ddORHr ; 28 IF 1Hr 29 EXECUTE 14 through 18 30 RETURN(Hr); 31 ELSE 32 // No participating hosts found in the vicinity, 33 // Contact DNS for global host information. Figure 5-3. Discovery algorithm

PAGE 104

92 The same procedure is then repeated in lines 20 through 27. If there is still no response from any hosts, then the algorithm gives up. In this case, the DNS needs to be contacted (see Step 5) to figure out some global hosts, which are participating in the system, since there is no local participating host in the vicinity. Step 2: Selection. The selection of reference hosts from the candidates determined by the discovery procedure above is presented in Figure 5-4. The algorithm uses a heuristics to perform its job as explained below. IF TPNPNHr Hr is the final set of hosts to be used as references; IF TPNPNHr apply the selection heuristics: A) Pick the hosts, which reside in outside domains or use greatest number of hosts in different outside domains as their own reference hosts, B) Pick the hosts, which are closest to origin in Euclidean space (i.e., the ones with absolute smaller coordinate values), C) Pick the closest hosts (i.e., quick responding hosts), and prepare the final set of hosts as references. Figure 5-4. Selection algorithm (A) in Figure 5-4 tries to ensure that the coordinates converge not only locally but also globally. (B) tries to ensure that the system/coordinates converge(s) toward a fixed point to prevent chaos. Coordinates may go out of control over time due to absence of fixed hosts (e.g., landmarks), accumulated error terms and periodic recalculations. Similar to the concept of combining GMT and atomic clock for providing global time and preserving accuracy of time dissemination, we use a single point that never changes its coordinates to solve the similar problem. For example, this point can be set to O(0, 0) as the origin, assuming a two-dimensional space. A computer engineering department of a university, for example, may configure all its hosts to serve this purpose. Except hosts closest to the origin no other host needs to contact to this origin. When computing the

PAGE 105

93 coordinates for the fist time, a host can choose the reference points that are closer to the origin as compared with the others. In recomputing coordinates, they may also consider their own coordinates to select the reference points with respect to the origin. (C) tries to minimize the overhead into the network due to distance measurements, since sending ping packets (see Step 3 below) to closest reference hosts keeps the process local and therefore only a small part of the network is affected. The discovery part of the algorithm (Step 1) guarantees (C) and therefore it is already taken into account in the first two. So, it is applied when the first two cannot make a decision. Step 3: Measuring distances. The distances (delay) are measured using ICMP ping. However, it is well known that ping can easily be abused. The protocol in Figure 5-5 was designed to use ICMP ping in a secure manner for TPNP. The source in the protocol is the host to join in the TPNP system. The target is one of the reference hosts (nodes) used by the source. 1. Source connects to Target and asks for ping permission. 2. If the Target grants the permission, it returns a random ephemeral port number to be used for ping along with a one-time password to Source. If Target is busy serving other requests, it may simply respond with a contact later message. 3. Target opens the ping port by starting the ping server listening on the ping port. 4. Source pings the Target on the ping port. The ping packets include the one-time password. 5. Target checks the password and if valid responds to the request, otherwise the packet is discarded. 6. After the predetermined number of ping requests received or time-out occurred, Target closes the ping port. Figure 5-5. Distance measurement protocol Step 4: Computing coordinates. A host, which is computing its own coordinates, needs the coordinates of its reference hosts and the distances to these hosts. In this step, this information is ready as the result of the previous steps. TPNP uses the coordinate computation process of GNP (Ng & Zhang, 2002). This process is a non-linear

PAGE 106

94 computation that involves a minimization function. It is subject to future research to use linear functions similar to the ones proposed by Lim et al. (2003) and Tang and Crovella (2003). The coordinate computation process tries to find a solution to a multi-dimensional minimization problem. It is formally the minimization of the objective function liijijpmf,),((.) where is an error measurement function, m ij and p ij are measured and predicted distances among the hosts, respectively. Informally, the error measurement function computes the difference between the measured and the predicted distances. The one we use is the normalized error measure, which was rated the best by Ng and Zhang (2002): 2/)(),(ijijijijijmpmpm The inputs to the process are measured distances obtained in the previous step in the form of a matrix and coordinates of the hosts obtained in Step 1. At each iteration the minimization function is computed and new computed coordinates are assigned to the host as the hosts coordinates and used by the following iteration. Iterations continue until the error is reduced below a predetermined minimal value. Final coordinate values minimize the overall error between the computed and measured distances from the current host to the chosen reference hosts. Step 5: Storing and advertising coordinates. A host, which completed the previous steps should store its coordinates and make them available to the outside world. The coordinates may be required by the other hosts for two purposes. First one is for applications, which would benefit and therefore use distance information between the hosts in the Internet. The second one is that other hosts that would like to join in TPNP

PAGE 107

95 may request coordinate information from the current host. The same is true for hosts that may need to recompute their coordinates. In addition to making the coordinates available for application purposes at each host, DNS can be used to provide host-name/location or IP-address/location resolution that would eliminate the need to contact hosts for coordinate information. Lastly, the current host should join the IP-multicast group reserved for TPNP to receive and reply TPNP requests from other hosts, which might like to join in TPNP afterwards. The host should also prepare for handling ICMP ping requests as explained in Step 3. 5.3.2 Starting the System One of the major issues in realizing TPNP is how to start up the system. In most server-based distributed systems, servers are first configured and then start running. Problems such as load balancing, scalability, proximity and fault-tolerance arise later and continue throughout the lifetime of the system. Within TPNP however, the opposite is true. Once the system is started the problems mentioned diminishes and even disappears over time with the increase in the number of participating hosts. There are two ways to start up the system, namely, sequential joining from the beginning and participation of a set of hosts in parallel. The former scheme is used in our simulations and explained in Section 5.4. The latter can be achieved by simultaneous participation from fixed sites (such as universities) with centrally and statically computed coordinates as in the GNP approach. However, in TPNP this is to be done only once, and these hosts might even cease to exist over time with no effect on the system. Furthermore, the number of such hosts needs not be greater than the number of reference points desired.

PAGE 108

96 One way to figure out the participating hosts in the system is to use IP multicast as used by the algorithm given in the previous section. It would be safe to assume that the first responses come from the closest hosts. This scheme fits nicely into the local distance estimation in TPNP because it is very easy to find the closest hosts using multicast. Otherwise, it would not make sense to talk about closest hosts when we are already discussing a distance estimation scheme. One nice side effect of the peer finding process in TPNP is the fact that every host discovered by a new participant reveals more hosts giving more than enough nearby hosts for references. The alternative is to use DNS to explore the participating nearby hosts in the system by exploiting the Local and Authoritative Name Servers. However, although DNS hierarchy gives clues, it is not easy to find the distant hosts especially during the early stages of the system. Further research is necessary to determine how best DNS could be as an alternative with minimal changes and overhead to the existing system. 5.3.3 Scalability Issues Contrast to the common scalability problem in distributed systems, system growth has a positive affect on the TPNP system due to its p2p architecture. The GNP approach is clearly more scalable when compared to a centralized client/server model like that of IDMaps. However landmarks, which are cornerstones in GNP introduces other important scalability problems as explained in Section 5.2. Since the TPNP eliminates the landmarks completely, these problems disappear altogether. However, use of multicast as the discovery mechanism introduces load into the underlying network. But this overhead diminishes and even disappears as the number of hosts participated in the system increases. In fact, in most cases, the overhead of multicast is observed only when a new host wants to join in the system. Even then, if the

PAGE 109

97 number of the nearby hosts, which are already in the system, is no less than the required number of hosts, the multicast overhead will be minimal. For the same reason, hosts do not have to measure their distances to distant landmarks which will reduce the overhead introduced into the network. Therefore, it can be said that the approach is positively scalable, in terms of the load introduced into the network for both multicast and delay measurements. 5.3.4 Security Considerations The TPNP approach also addresses the security of the system. The security aspect of TPNP is two-fold. First, as pointed out before, GNP cannot prevent hosts from lying about their coordinates. For TPNP, because hosts compute their coordinates relative to nearby hosts, and these nearby hosts have to provide their reference points along with the coordinates, it is possible to check using this information whether a host's coordinates are correct. Heuristics can be devised to verify the correctness of the host coordinates by asking the coordinates of the reference hosts of the target host. Several levels of security can be provided at the expense of communication overhead by increasing or decreasing the number of hosts to check. The second security problem in landmarks is that they may become target of attacks since they must answer each ping request directed to them. The problem is more prevalent for TPNP since each participating host would have to answer any ping request coming from any host in the Internet. The solution we propose is to customize the use of ping. The distance measurement protocol given as Figure 5-5 serves this purpose. 5.4 Experimental Evaluation We have conducted simulation experiments to determine how TPNP performs, that is, how accurate the predicted distances among the hosts will be in the system.

PAGE 110

98 5.4.1 Simulation Environment Our simulation system employs a hierarchical structure, which models individual Internet domains (i.e., autonomous systems) either as an Inet or a Waxman topology. Every domain in a given topology has an equal probability of having either a Waxman or Inet model, and has any number of nodes ranging from 20 to 200. In the Waxman model, the nodes are placed randomly in a two dimensional grid. Links are added pairwise between all the nodes in the network by considering whether a link should exist according to a probability function, which takes into account how close the nodes are to each other and how many links are expected to exist in the network. The borders between domains use the Inet, which provides a hierarchical, power-law topology. Earlier studies have shown that the Internet follows a power-law topology (Faloutsos et al., 1999; Tangmunarunkit et al., 2001). These studies report on several power-law relationships observed on domains connectivity degree, degree frequencies, and the neighborhood size within any given hop count from a domain. For example, the first power-law given by Faloutsos et al. (1999) states that the outdegree of a node is proportional to the rank of the node to the power of a constant where the rank is the nodes index in the order of decreasing outdegree. A more recent study by Ratnasamy et al., (2002) related with ours also confirms that results obtained with power-law topologies better match with the actual Internet traces. To apply GNP in our simulation environment and to compare with TPNP we have integrated the GNP software by Ng and Zhang (2002). We have used the software for GNP computations and for TPNP where possible, without modifications other than the ones necessary for integration.

PAGE 111

99 5.4.2 Simulation Parameters In our experiments, we used 10 landmarks for GNP and 10 reference nodes (peers) in TPNP (except the first 10 nodes to join). The number of dimensions is two for both. It is important to note that the choice of ten landmarks and two-dimensional coordinate system is for simulation simplicity and efficiency. Our aim is to compare the two approaches and therefore our first priority in selecting parameters is to ensure fairness. Using only two dimensions has the advantage of much less computation overhead. When the number of landmarks and reference points increases, both approaches benefit and GNP benefits more since the results with two-dimensional space are not very accurate and there is more room for improvement. As reported by Ng and Zhang (2002), there is a saturation point for both number of dimensions and reference nodes. We confirm the results for GNP and report that the same is true for TPNP. For prediction accuracy, we use the same performance metric by Ng and Zhang (2002), which is the following: ),min(||ReestimatedmeasuredestimatedmeasuredErrorlative Our choice of the metric as opposed to the simple percentage or simple ratio metrics, which are used by Gummadi et al. (2002), Ratnasamy et al. (2002), and Pias et al. (2003) is due to the fact that while percentage error metric hides underestimates, ratio error is not suitable to compute average undirectional error due to the magnitude difference of over and underestimates. 5.4.3 Simulation Strategy Our simulation strategy is to obtain the coordinates of all the hosts in the topology and therefore estimations for all the shortest path distances among every pair of nodes.

PAGE 112

100 For TPNP, we have used the downhill-simplex method (Ng & Zhang, 2002), which used for GNP for minimizations. To select the best possible nodes to be landmarks for GNP, we implemented the N-cluster-medians technique, which was rated the best (Ng & Zhang, 2002). We applied the technique to the whole network to find the nodes, which represent all the nodes with an aggregation based on proximity. It should be noted that this technique is only feasible in a simulation environment and in favor of GNP. All of the results presented in this chapter were obtained by using three different topologies of roughly the same size and average values of the three simulation runs are reported. This is to make sure that the results are repeatable which is especially important for TPNPs stochastic behavior due to random node join order. To simulate the actual formation of the TPNP system, we pick a random node on the whole network and assign the coordinates of origin (0,0) of the Euclidean system for convenience. Since we are using a 2D Euclidean system, only the second and the third nodes coordinate computation process differs from the rest. For these two nodes, we measure distance of shortest paths between them and previously joined nodes. We place the second node on the x-axis and pick the positive value for the third node among the alternatives for convenience. For the rest of the nodes, the same minimization technique of GNP is used, however, 4 th through the 10 th nodes use the available number of reference points while the rest use exactly 10 of them. 5.4.4 Simulation Results and Analysis As seen in Figure 5-6, when the number of domains increases, prediction performance of GNP is negatively affected. This is the case even though the landmarks are chosen using the N-cluster-medians of the entire network.

PAGE 113

101 00.20.40.60.811.21.41.61.80102030405060708090100Network Size in Number of DomainsAverage Relative Error GNP TPNP Figure 5-6. Average relative error It is clear from the figure that using a pure p2p approach without landmarks, better accuracy can be achieved. This is again due to the fact that global landmarks are not adequate for local distance estimations. In Figure 5-7 we have plotted the intra-domain distance predictions of the both approaches with increasing network sizes. The figure shows clearly that the local (intra-domain) relative error remains constant in TPNP regardless of network size and the number of domains. However GNPs intra-domain relative error is correlated with network size. Moreover, even with a fairly small network size of only one thousand nodes, which is the first point in Figure 5-7 with 10 domains, GNPs accuracy is still not as good.

PAGE 114

102 0123456789100102030405060708090100Network Size in Number of DomainsAverage Relative Error GNP local TPNP local Figure 5-7. Average local relative error Although excluding outliers in statistical data has merit, in practice it is desirable for a system to be as fair as possible to its users or applications. Since we expect some form of uniformity from TPNP, we also plotted the graphs for average relative error of values greater than 1, which we call anomaly in Figure 5-8. As expected, TPNP provided the uniformity of anomalies with also smaller error terms when compared to GNP. As it is clear from the figure, GNP has larger anomalies, which scale with the network size. 012345670102030405060708090100Network Size in Number of DomainsAverage Relative Error GNP Anomaly TPNP Anomaly Figure 5-8. Average outliers relative error

PAGE 115

103 Within TPNP, due to cascading coordinate computation, one might expect that the predicted distances would be less accurate due to accumulated errors when the number of hops (peers) increases between any given two hosts. To provide an insight, we plotted the graphs in Figure 5-9. These graphs have been obtained from 7000-node topologies. 0123456789100100020003000400050006000700080009000Path LatencyAverage Relative Error GNP TPNP A 0500000100000015000002000000250000030000000100020003000400050006000700080009000Path LatencyNumber of Paths B Figure 5-9. Distribution of average relative error to path latencies

PAGE 116

104 Figure 5-9.A shows relative error distribution to the path latency intervals. We created 200 ms intervals of path latency starting from zero and plotted the prediction errors of all the paths whose measured distances fall in that interval. Figure 5-9.B shows the distribution of paths into these latency intervals in the network. With an average of 100 ms of hop latencies in the network a slight increase arises at 7000 ms point for TPNP. This means that error accumulation due to many predictions across the network due to the p2p nature of TPNP, may not be significant. However, until the 2500 ms point, GNP predictions of shorter paths are not as good. GNPs accuracy clearly increases when the path latency increases due to very well-positioned landmarks in the simulation environment, but the number of paths in this upper range is fairly small as seen in Figure 5-9.B. 5.5 Conclusion In this chapter we presented a p2p coordinate-based network position estimation scheme that does not rely on landmarks for coordinate computation as in previously proposed approaches. The goal of eliminating the landmarks is to achieve greater scalability. The overall architecture is presented and the goal justified. The simulation analysis also shows that the system performance in terms of local distance prediction accuracy can be significantly improved over GNP. Even with a two-dimensional Euclidean space its overall performance is within an acceptable range. The pure p2p nature of the architecture lends itself very well with the robustness of the system. Some security issues are also addressed. In the next chapter, TPNP is used for the quantitative analysis of multiple mobile agent systems. It is also made clear how TPNP provides context-awareness for these

PAGE 117

105 systems. Moreover, we show in the next chapter that a positioning system is also proved useful for traditional single mobile agent systems.

PAGE 118

CHAPTER 6 QUANTITATIVE ANALYSIS OF MULTIPLE MOBILE AGENT SYSTEMS 6.1 Introduction In Chapter 5, we have proposed a peer-to-peer network positioning architecture. We have said that a general-purpose system such as TPNP, which is based on this architecture could provide coordinates of the hosts in a network and simple off-line computations could use this coordinates to estimate the inter-host distances. This chapter shows how the knowledge of inter-host distances could be useful for mobile agents and what would be the mechanism to do this. We are basically looking for the answers to two important questions: can we alleviate the performance problem introduced with multiple agents by making them network-aware? and can the overhead of off-line computation be justified? In addition to answering these questions, we will explore more details on the network-awareness and context-awareness concepts in the context of multiple mobile agent systems. In this study we do not target a specific mobile agent application. Any application, which does not impose an ordering of hosts to be visited, is a potential application. Examples are information search and retrieval, software distribution/update, remote education and e-commerce. Note that in this chapter, we use the master/support agent model, which is given in Chapter 3. We use terminology specific for the chapters purposes and this needs a notation change from previous chapters. The MA stands for Master Agent rather than 106

PAGE 119

107 Mobile Agent, and SA is similarly the acronym for Support Agent. We also refer to the itineraries for both types of agents as master itinerary and support itinerary for short. 6.2 Network-awareness in Mobile Agent Computing Network-awareness is a broad concept. What we mean with being network-aware in the context of mobile agent systems is to be able to obtain distance (i.e., delay) information among the hosts. A common use of distance information is to locate the closest server or object. The problem could be generalized and formalized as finding the nearest neighbor in a given finite set of nodes in some domain. In mobile agent computing however, we add the concept of itinerary, which is a list of nodes to be visited by an MA(s). The concept is rather vague in the mobile agent literature. Usually, itinerary in this context means that a mobile agent has an ordered set of hosts to visit. If the ordering is not important or defined, the mobile agent is said to be itinerary-less. Our view is however different, we define an itinerary for a mobile agent as the set of hosts to be visited for a given mission. This means every mobile agent has one. However the order of the visits may or may not be enforced by the itinerary. Moreover, the itinerary may be fixed as well as flexible meaning that it may change during the mission depending on the application. The flexible itinerary concept raises some interesting issues for future research. One of the most important characteristics of the software agents in the field of artificial intelligence is, without a doubt, their being intelligent entities. In mobile agent research the intelligence of agents is mostly assumed by referring to the general field of software agents. However, artificial intelligence research cannot address the intelligence in mobile agent migration because software agents are static entities. Even if the mobile agents used, for example, learning algorithms in some specific application, we still could

PAGE 120

108 not say much about their intelligence, if they still were wandering around the network to accomplish some distributed task. We need ways of making agents intelligent using network-awareness concept in terms of distance information. Not surprisingly, given an itinerary and the distances among the hosts in the itinerary, the problem becomes an instance of the well-known Traveling Salesperson Problem (TSP). 6.3 The Traveling Salesperson Problem The TSP is a classical problem in combinatorial optimization. The general classical TSP is defined as follows: A salesperson starting from the home city is required to visit n cities without repetition before returning home. The objective is to find out the minimum-cost tour given the inter-city distances. The input to any classical TSP instance is a distance/cost matrix. The output is a permutation of cities, which represents an optimal tour. There are many variants of TSP such as symmetric TSP where the distances of edges in a graph are the same in either directions or asymmetric TSP otherwise (Lawler et al., 1985). The definition of the classical TSP can be directly applied to mobile agent computing and simply be called the Traveling Agent Problem (TAP). However, just as the original TSP, different mobile agent applications are expected to require variants of the TAP. For example, an application may employ several clones of an agent, which would correspond to the multiple salesman or vehicle routing problem (VRP) (Lawler et al., 1985). The classical TSP however, is not directly applicable in our case since we do not have inter-host distances but only coordinates of hosts in the Euclidean space. For a given instance of the problem, these distances can be computed easily using the coordinates, however, this computation is not efficient. Therefore what we need is a variant of TSP,

PAGE 121

109 which is known as the geometric (or Euclidean) TSP. In geometric TSP the input is n points and their coordinates in k-dimensional space and the output is a permutation that corresponds to an optimal TSP tour. The length of the tour is the sum of the distances between adjacent points under a specified metric such as the Euclidean metric. The geometric TSP is known to be NP-hard (Lawler et al., 1985). TSP is the most attacked problem in combinatorial optimization. Since the problem is NP-complete, most of the research is focused on heuristics to find nearor sub-optimal solutions and their analysis. The TSP literature has a vast amount of material on the heuristics and the consequence is that there is a large number of variant of the problem and heuristics to choose from. The heuristics are classified as follows (Bentley, 1992; Lawler et al., 1985): Heuristics that grow fragments. The algorithms in this category maintain fragment(s) of tours. The main body of the algorithms consists of a loop. While the tour is being built in the loop, the fragment represents a path of the subset of points. At each iteration of the loop a new point is added to the fragment. Finally, the two ends of the fragment, which corresponds to a complete path of all the points, are connected together to yield a complete tour. Depending on the heuristic one or more fragments can be maintained simultaneously. Heuristics that grow tours. As the name implies, these are the algorithms that maintain complete cycles of points as tours, instead of fragments. There are three selection rules (nearest, farthest and random) and two expansion rules (addition and insertion). Thus, the heuristics are cross product of these rules. The selection rules are explained in Section 6.4.2. In the expansion rules only the definition of point expansion

PAGE 122

110 differs. The algorithms main body consists of a loop, which maintains a complete cycle of a subset of points as a partial tour. Starting with a single point, at each iteration of the loop the tour is expanded by choosing a new point by any of the selection rules and then choosing where to add it by using one of the expansion rules. Note that the terminology is a little confusing since addition and insertion deal with where to add the new point but not how to add/insert it. A new point is added/inserted by deleting an edge and adding two new edges. Heuristics based on trees. These are the heuristics, which are based on a structure in a graph such as a Minimum Spanning Tree (MST) or directly on an underlying data structure such as a K-d tree (see Section 6.4.1). The algorithms that are based on an MST first build the tree. Then they traverse the tree to yield a tour. According to the algorithm chosen, the operations performed during tree traversal differ. The second category of the algorithms traverses directly the physical tree structure to build a tour of the points stored in the tree. Local optimization heuristics. The three groups of heuristics above start with a set of points and actually build the tour. Thus, they are referred to as starting heuristics. This last group of heuristics however makes local improvements to the given tours already built by any of the algorithms mentioned above. Thus, the input to the algorithms is a complete tour and the output is a shorter/better tour. The algorithms in this group are identified by using the notation -Opt. indicates how many edges are removed and added at each step of the algorithm. 2-Opt, 2H-Opt and 3-Opt algorithms are used to perform local optimizations. However 4-Opt algorithm is no longer a local optimization one. The 2H-Opt algorithm deals with 5 points instead of 4 as in 2-Opt or 6 as in 3-Opt.

PAGE 123

111 6.4 Application of TPNP and TSP to Classical MA Model Bentley (1992) provides a detailed analysis of the heuristics and reports results of the fast algorithms and their implementations. We picked one heuristic from each of the four categories above and implemented them. These are: Nearest Neighbor (NN), Random Addition (RA), Fast Recursive Partitioning (FRP) and 2-Opt, respectively. Our selection criteria is as follows: Performance. Algorithms ability to produce shorter tours, which is analyzed theoretically or measured by experiments. Efficiency. Algorithms ability to produce the tour quickly. In addition to asymptotic complexity we are also interested in actual running times based on experimental results. Robustness. A heuristic is said to be robust if its performance with different input distributions is not far from its performance for uniform distribution. Clearly it is a relative metric. Bentley (1992) and Bentley (1990b) provide ten such different distributions and analyze the robustness of heuristics mentioned above. Simplicity. Heuristics understandability and ease of implementation. 6.4.1 The Data Structure Our implementation is based on a data structure known as K-d tree proposed by Bentley (1975). K-d tree stands for K-dimensional binary tree, which generalizes single dimensional ordinary binary trees. We use a more efficient variant of the K-d trees, which is semidynamic K-d tree (Bentley, 1990b). A semidynamic K-d tree allows deletions and undeletions of nodes but new nodes cannot be added once the tree has been built. However, it is sufficient for our purposes with added advantage of efficiency, due to the assumption that the itinerary of an agent (set of hosts to be visited) is known before the

PAGE 124

112 mission starts at the home. A K-d tree supports several operations such as nearest neighbor searching and fixed-radius near neighbor searching (Bentley, 1990b). The nearest neighbor procedure accepts as input a point and returns the nearest point in the tree to the input. The fixed-radius near neighbor procedure accepts two points. The first point is the target and the second one is to define a ball, whose radius is the distance between the two points and the center is the target. The procedure returns the closest point in the tree to the target which lies in the ball. The basic operations on K-d trees are used to solve several closeness problems such as minimum spanning trees and TSP heuristics including the local optimizations (Bentley, 1992). The K-d tree can be built in O(KN log N) time (Bentley, 1990a). Sampling techniques reduces the complexity to O(KN + N log N) (Bentley, 1990b). Semidynamic K-d trees allow bottom-up operations to be performed in O(1) time which would take O(N) time for a procedure that starts at the root (Bentley, 1990b). All the implementations of the algorithms in this chapter are based on K-d trees and therefore bounded by their complexity of the operations used. These are building the tree, deletion, undeletion, nearest neighbor searching and fixed-radius near neighbor searching. 6.4.2 The Heuristics The NN heuristic is a simple greedy algorithm. It starts with a point and connects the nearest point to the previous one until the cycle completes all points in the list. A variant of the algorithm enlarges the path by adding points to each end of the fragment. The RA heuristic (Bentley, 1992) is a variant of Nearest Addition (NA) and Farthest Addition (FA) algorithms. The NA adds the next point as the point that is not in the tour and is closest to any of the points that are already in the tour. The FA does the opposite by choosing the farthest point. The RA however, picks the next point randomly.

PAGE 125

113 Surprisingly, due to random selection it runs much faster than the NA and FA with a little degradation on performance, which is the quality of the tours produced. The FRP algorithm is based on the underlying K-d tree. It first creates the K-d tree from the set of input points, traverses the tree, and finds short fragments of the points in the buckets of the tree by performing an NN search and connect the bucket fragments together which yields a tour. The 2-Opt heuristic is a local optimization algorithm. It takes a complete tour as input and produces a shorter tour as output. The 2-Opt means that two edges are removed and two new smaller cost edges are inserted. This procedure is repeated on the tour until no possible optimization remains at which point the tour is said to have the 2-Opt property. All the heuristics use the nearest neighbor procedure while 2-Opt also uses the fixed-radius near neighbor search procedure. 6.5 Experimental Evaluation In this section, we present the details of applying TSP heuristics to the single agent model via simulation experiments. 6.5.1 Simulation Environment and Parameters We have run the code that implements these heuristics in the same simulation environment we used in Chapter 5 where TPNP was also implemented and simulated. The programming language used is C++. All simulation experiments in this chapter have been done on a laptop computer with a 2-GHz Intel Pentium 4 M processor and 512 MB of main memory, running Windows XP OS. This processor is reported to have a 512KB L2 cache.

PAGE 126

114 Simulation parameters for TPNP are the same as the ones used in Chapter 5. We use 10 reference nodes and the same performance metric, which is the relative error. Unless indicated otherwise, the number of dimensions used in the experiments is 4. We have used networks with roughly 5000 nodes in the simulation runs with the number of domains being 50 and the average number of nodes per domain of 100. The number of hosts in any mission is 100 unless indicated otherwise. On the TSP side, K-d tree implementations need the bucket size parameter, for which we use 5. This means that the maximum number of nodes in a single bucket may not exceed this value. 6.5.2 Simulation Strategy The strategy is to pick the hosts in the itinerary randomly from all the hosts in the network. The same is true for the home of the agents. To ensure repeatability, for the random tour computations, we pick 100 different sets of hosts and report their averages. For all the experiments, we pick 3 different host sets for the same reason and report the averages. We do not consider different distributions of nodes because we use the TSP heuristics with known robustness ratios for several different distributions as explained before. In this part of the study, we measure and report only the length of the tours for a given itinerary. The goal is to figure out how good a tour we can compute using predicted distances in the network. Thus, we use predicted distances in our computations but we analyze the results by using the measured distances. 6.5.3 Results and Analysis Figure 6.1 shows the computed tour lengths for varying number of hosts. The tours, of which lengths are displayed, all have the 2-Opt property. The scalability of computed

PAGE 127

115 tours are remarkable when compared with the average of random/arbitrary tours. Results of the NN and RA algorithms are so close to each other that they overprint in the graph. The results are consistent with Bentley (1992)s original results in that FRP performs worse than the other two heuristics. It is important to note here again that we compute the tours with predicted distances, but the values in the figure are the measured distances. 01000020000300004000050000600007000080000900000100200300400500600700800Number of HostsTour Length (ms) NN RA FRP Random Figure 6-1. Performance of 2-Opted TSP heuristics across the problem size Figure 6.2 displays the tour lengths with 2-Opt property of the same heuristics with the input of different node coordinate values of varying dimensions in the TPNP system. The Random line is shown as a baseline for comparison. The NN and RA values again overprint each other. It is interesting to observe that as opposed to the theoretical results of distance prediction schemes like GNP (Ng & Zhang, 2002) and TPNP (Chapter 5), increase in number of dimensions after the value of 4 does not reflect any significant improvement or any improvement at all. Closer analysis with varying number of dimensions is presented below.

PAGE 128

116 0200040006000800010000120001400001234567Number of TPNP DimensionsTour Length (ms) NN RA FRP Random Figure 6-2. Performance of 2-Opted TSP heuristics across the number of TPNP dimensions Tables 6-1, 6-2, and 6-3 present the results of running the implementations of NN, RA, and FRP heuristics, respectively, including the 2-Opt optimizations applied to all tours generated by each heuristic. The first column of tables indicates the number of dimensions used in TPNP. The next column is the average of random tour lengths created from the same set of nodes. The next set of columns gives the predicted and corresponding measured distances of the tours created by each heuristic along with their relative errors between these distances. The following set of columns shows the application of 2-Opt local optimization heuristic to the computed tours of starting heuristics. The last set of columns displays the percentage improvement of the 2-Opt optimization. Although the execution times of the algorithms are of great importance, we do not display them since surprisingly each run of any of the algorithms we implemented completes on the average in less than 1 millisecond with default simulation parameter values. This is true also for the extreme cases, for example computing a 2-Opted NN tour with either 700 hosts or 6-dimensional space. The results justifies that employing TPNP

PAGE 129

117 and TSP for mobile agent computing does not impose much off-line computation overhead that would offset the benefit achieved by improved tour lengths. Clearly the off-line computation time is negligible when compared to the improvements on actual measured tour lengths. We should note here that in our simulations we did not use any compiler or code optimizations other than using most efficient implementation of K-d trees. Although there are known code optimization tricks for K-d trees (Bentley, 1990b) for further efficiency improvements, we did not use them in our code to keep it more understandable. The results also indicate that several performance improvements can also be made with small degradation of efficiency since we have a lot of room for total running times. For example, heuristics, which are known to perform better but takes more CPU time could also be employed. For example, instead of using FRP, the original heuristic (Lawler et al., 1985) could be used which takes more time to complete but provides better performance. Depending on the number of hosts in a given mobile agent application, execution times of single digit milliseconds may still be acceptable. Caution however is needed since mobile agents are likely to be employed in mobile computing where mobile devices might not have sufficient processing power and memory as the one we have used in our experiments. Also, the time needed for gathering the network information should be taken into account.

PAGE 130

118 Table 6-1. Application of NN heuristic with TPNP NN Tour Length NN + 2-Opt Tour Length Improvement # Dim Average Random Tour Length Pred. Msrd. Err. Pred. Msrd. Err. Pred. Msrd. 2 11494.48 2408.13 4109.37 0.71 1821.03 3401.32 0.87 0.24 0.17 3 2701.83 4186.77 0.55 1913.98 3467.35 0.81 0.29 0.17 4 2727.46 3731.45 0.37 1932.40 3177.63 0.64 0.29 0.15 5 3151.12 3992.68 0.27 2191.03 3205.98 0.46 0.30 0.20 6 3220.87 3881.28 0.21 2419.65 3274.62 0.35 0.25 0.16 Table 6-2. Application of RA heuristic with TPNP RA Tour Length RA + 2-Opt Tour Length Improvement # Dim Average Random Tour Length Pred. Msrd. Err. Pred. Msrd. Err. Pred. Msrd. 2 11494.48 2017.51 3698.99 0.83 1809.57 3413.57 0.89 0.10 0.08 3 2264.22 3804.00 0.68 1911.46 3479.81 0.82 0.16 0.09 4 2310.22 3395.87 0.47 1961.92 3196.09 0.63 0.15 0.06 5 2460.88 3340.74 0.36 2173.13 3161.17 0.45 0.12 0.05 6 2762.21 3492.40 0.26 2406.50 3281.76 0.36 0.13 0.06 Table 6-3. Application of FRP heuristic with TPNP FRP Tour Length FRP + 2-Opt Tour Length Improvement # Dim Average Random Tour Length Pred. Msrd. Err. Pred. Msrd. Err. Pred. Msrd. 2 11494.48 5998.78 10012.23 0.67 3503.33 6490.34 0.85 0.42 0.35 3 6201.88 9840.16 0.59 3592.91 6350.11 0.77 0.42 0.35 4 6500.16 9495.04 0.46 3889.43 6251.32 0.60 0.40 0.34 5 6992.51 9300.32 0.33 4112.55 6020.00 0.46 0.41 0.35 6 7312.72 9288.71 0.27 4311.45 6102.02 0.42 0.41 0.34 One can argue that comparing random tours with the tours achieved by using heuristics would be analyzing something that could easily be guessed. Clearly, creating intelligent tours with the help of heuristics should outperform the random ones. However, it should be noted that in reality we do not know the actual distances and cannot obtain them under the efficiency constraint. Therefore we have to run the implementation of algorithms with the input of predicted distances. However, we measure the performance

PAGE 131

119 using measured distances. Application of TSP heuristics with predicted input is not necessarily intuitive as explained in the following. It seems we have two contradictory results. The first one is that predicted tour lengths (Pred columns) are increasing with increase in dimensions. The reality is that due to underestimations, the distances seem shorter when the accuracy of the estimations is lower. But while the accuracy is getting better with the number of dimensions, which is clear from the relative error (Err columns), the predicted distances grow closer to the actual distance values. So, even we cannot see the direct effect of better tours achieved using heuristics in predicted distances, we actually see the clear improvement in measured distances that we are interested in. The second is that in some cases in the tables, although the prediction accuracy is better with more dimensions (Err columns), the tour lengths are not shorter as expected (Msrd columns). It is easy to explain this behavior. When the number of dimensions changes, the nodes are assigned new coordinates in the more dimensional space. The direct consequence is that the predicted distances among the nodes also change, which yields different tours for the same set of nodes. Increasing number of dimensions in coordinate-based approaches is expected to yield more accurate predictions to some extent. The GNP study (Ng & Zhang, 2002) shows that improvement is gained until 7 dimensions of Euclidean space. The TPNP study (Chapter 5) showed that it is possible to improve the results in lower dimensional values such as 2 and 3. The results in the tables indicate that for our application 4 dimensions are sufficient. In most part, after 4 dimensions results are not improved, improvements are negligible or they are even degraded. Of course the MA computing is

PAGE 132

120 not the only application area of distance estimation schemes. We note that a careful analysis of all potential applications should be taken into account before deciding the number of dimensions that would be used in a real system. The cost of using more dimensions may not justify the benefit that could possibly be gained. 6.6 Context-awareness in MA Computing Context-awareness is an important characteristic for multiple mobile agent systems and more so for autonomous group of multiple mobile agent systems. This concept is subtle in classical mobile agent model since majority of the studies on mobile agents assumed that an itinerary, which is specific to a mission, could easily be obtained from a so-called directory service. Others assumed a closed network where the hosts to be visited are fixed or known in advance. For example, in a closed network, security is not much of a concern and therefore as long as the agents are within a pre-specified environment no context change occurs. Once an itinerary formed in either way, context information becomes out of context. For an autonomous group of agents the first type of contextual information is the available and suitable mobile agent systems where the agents could be executed. Recall from Chapter 2 that mobile agents require their own system to be loaded and executed. This information applies also to the single mobile agent model. As the second type of contextual information, location/proximity becomes necessary. Knowledge of some suitable systems existence does not necessarily imply that we could use it in a specific mission. Those hosts may simply be located too far from our target environment which makes them out of context in terms of location. The last type of contextual information is about the security requirements of the missions. It is necessary to find out the level of security provided by each host to be

PAGE 133

121 considered as a part of a mission. This aspect is detailed in Section 6.7.1 where we discuss trust model and requirements. We have mentioned two alternative architectures in Chapter 3 for the network part of our overall framework of multiple mobile agent systems. One uses an additional distributed directory component while the other uses the TPNP system. We consider the latter in this study because of its self-formation property. In this architecture, a directory system still exists but its function is identical to the one which is sufficient for classical single mobile agent systems. Although the TPNP is basically a network distance prediction scheme, we call it a network positioning system to distinguish it from other systems since it is capable of providing contextual information. Step 1 in Section 5.3.1 details the discovery phase of the basic TPNP algorithm. To gather contextual information we extend both the inquiry Multicast and the Response messages by adding an application identification part. The inquiry messages include a field to identify the application that uses TPNP. The response messages consist of two parts. The first part is the same as of Chapter 5, which is related to coordinate specific information. The application identification part consists of the following: The application using TPNP that is running on the host, Parameters that are necessary for this application. The first field uniquely identifies the multiple mobile agent or any application that could benefit from TPNP. The second field can contain sub-fields. For our application these are: Which mobile agent system(s) is running on this hosts, Type and level of security provided by the system, Other hosts known that have similar services provided.

PAGE 134

122 6.7 Multiple Cooperating Mobile Agents Model The overall system framework includes three models: a mission model, a trust model and a performance model. The trust and performance models are based on the mission model. Mission models for multiple autonomous groups of mobile agents have been introduced in Chapter 3. In this chapter we assume the simple master/support mission model for two autonomous mobile agents. One is the master agent with an itinerary and the second is the support agent, which needs an itinerary to be computed according to the itinerary of the master agent. Following sub-sections present the trust and performance models. 6.7.1 Trust Model To the mobile agent security problem, there is no single solution with either non-technical trust establishment mechanisms (note that some of these mechanisms may be based on technical countermeasures) or technical countermeasures. Even combination of a few technical proposals cannot address every attack possible against agents. Therefore, a combination of technical solutions with non-technical trust establishment mechanisms and relationships are necessary. Trust establishment mechanisms can be summarized as follows: Hosts employ and advertise trusted hardware as explained in Section 2.4.2 Social or organizational trust which includes trust by reputation as explained in Section 2.4.2. Hosts employ some agreed-upon security evaluation criteria and advertise this. Trust establishment system: hosts advertise mobile agent transactions served by themselves via third parties that evaluate and certify claimed (number of) transactions similar to eBay ratings on sellers.

PAGE 135

123 However, level of trust established via the above mechanisms differs, depending on the applications and end-user. The assumption we make here is that trusted hosts exist in the assumed environment; usually these are not the ones that offer services sought by agents. The autonomous group of multiple mobile agents scheme is complementary to the trust establishment mechanisms above. Therefore we define three levels of security in the system based on the trust establishment mechanisms above: Untrusted master itinerary, untrusted support itinerary. This is the most difficult situation to address. Agents do not have anything other than mechanisms they employ to check each others computations since no trust establishment can be recognized by any of the mechanisms above. Untrusted master itinerary, trusted support itinerary. This case use hosts for the support agents, that have one or more of the trust establishment mechanisms above in place. Trusted master itinerary, trusted support itinerary. This case may not seem to need any additional security measures or mechanisms. However, as we stated above, the techniques we employ are complementary to the trust establishment mechanisms. Depending on the application and user requirements, those mechanisms alone may not necessarily be sufficient to put trust into the system. The security in the mission model given in the previous section is centered on the communication or more precisely on the messages exchanged between the agents. Therefore, we define the trust levels in the system around these messages. We define mainly three categories of trust levels as follows.

PAGE 136

124 Number of messages. Indicates how many messages are to be exchanged between two migrations; in other words when the agents are still executing on the same hosts. One can argue that agents may report to each other in a single message, however, an application may require a sophisticated checking mechanism or require agents to execute a challenge-response protocol. We will call the levels of trust in this category as primary trust levels. Each level is represented with an integer as the number of messages exchanged. Thus the lowest level is 1. Frequency of communication. The agents may not need to communicate on every host they visit. For example, it may be sufficient for the agents of some less security demanding application to exchange messages on every other host visited. We define three levels as A, B, and C, A being the highest level. In level A, agents are required to communicate on each host, level B requires communication on every other host and C means every third host will be sufficient. We will call the levels of trust in this category as secondary trust levels. Size of messages. The larger the message the better the security since message size is a direct indication of how much intermediate computation result and/or state information are exchanged among the agents. In Section 6.8.3 we will analyze the communication overhead of the first two categories of trust levels. The notation, i.e., A3 means that the primary trust level is 3 and the secondary trust level is A. 6.7.2 Performance Model Strasser and Schwehm (1997) introduced a performance model for mobile agents. Although aimed to be a generic model, their tacit assumption was that mobile agents examine and return vast amount of data to their home site, which is valid for information

PAGE 137

125 search and retrieval applications. Their work uses a selectivity factor which is defined as the mobile agents ability to refine the search results to be returned to the user. This factor is the key point in their model and suitable for comparisons between client-server and mobile agent computing. Our aim however is not to compare these two distributed computation models. Our main concern is to investigate the communication overhead introduced by multiple agents for a single mission in addition to the time it takes for a single agent to perform the same mission. Therefore we use a flexible, simple, and basic performance model which can easily be extended to more sophisticated models required for more specific applications. So when we remove the selectivity factor given by Strasser and Schwehm (1997), we are left with the basic communication time equation: Communication Execution Time (CET) = Propagation Delay + Transmission Delay The propagation delays are predicted and provided by TPNP. It is observed for every migration and message communication regardless of their load or size, respectively. Transmission delays are related to the transmission rate of the link used and size of the messages exchanged. Unfortunately there is no known way of measuring transmission rates of the links in a large scale internetwork as opposed to the propagation delay predictions provided by TPNP and other similar systems. In addition, transmission rates can always be improved. However, within propagation delay we are physically limited with the speed of light. So, any optimizations in terms of propagation delay will be useful and more meaningful towards future networks that might possibly have more and more transmission rates.

PAGE 138

126 So for mobile agents we have Mission Communication Time (MCT) = Agent Migration CET + Inter-Agent CET In the single agent model only the agent migration CET is considered. 6.8 Application of TPNP to Multiple Cooperating MAs In Section 6.5 we presented the results of performance analysis of applying TPNP and TSP to the classical single mobile agent model. In this section we consider multiple cooperating mobile agents by taking the communication between them into account. For simplicity we are using two agents, one master and one support agent. This problem is significantly more complex than the single agent model. Here we are given two sets of hosts. The first one contains the itinerary of the master agent and the second one is the available hosts for the support agent. There are many possibilities for deciding the tours of each set. One possibility is the pair wise matching, which finds the best possible tour for the MA and then to decide the individual SA host for each host in the master itinerary. This should give us the best performance in terms of inter-agent communication time since we are capable of finding the best SA host for each host in the master itinerary. However, this is not a practical solution for several reasons. First, the available SA hosts might be limited. Second, this complicates the itinerary of the SA and therefore the application. Third, we would need to take into account the time for the support agents migrations. The last one is that the support agents tour may need to repeat some hosts meaning that the support agent would have to travel among the hosts back and forth to be near the MA hosts, not to mention the increased network load. For the reasons above, we are taking a clustering approach that is more manageable and secure. We do this by clustering the hosts in the master itinerary and select the best possible SA host for each cluster. The approach is more manageable because the number

PAGE 139

127 of hosts reduces to the number of clusters. It is more secure since it requires fewer number of SA migrations. Therefore, the number of clusters is equal to the number of hosts in the support itinerary. Once the master agent completes visiting the hosts in one cluster, it migrates to the first host in the next cluster. At the same time the support agent migrates to the next host in its own itinerary, which is the closest host to the new cluster. We call this problem Multiple Autonomous Traveling Agents Problem (MATAP). Figure 6-3 illustrates an instance of the problem. The double-line arrows indicate the tour of the MA, while the single-line arrows show the tour of the SA. The clusters created out of the MA tour are shown as circles. For clarity, only the SA hosts that are selected from all available ones are shown. The dashed lines indicate the distance between the hosts in the cluster of the MA tour and the selected SA host for that cluster. The small rectangles represent the hosts in the master itinerary while the small circles represent the hosts in the support itinerary. The labels in the figure will be clear in the following subsection. HomeC0C1C2HB0HB1HB2SM0SM1 SS0SS1hCF0hCF2hCF1hCL0hCL2hCL1 Figure 6-3. Illustration of MATAP

PAGE 140

128 An alternative approach could be to start from the set of available SA hosts, pick the subset of best hosts in the master itinerary for each chosen host for the support itinerary. However the selection of best SA hosts seems like a difficult problem. The only way of doing this is a brute-force computation of distances between each SA host and all the hosts in the master itinerary. Therefore this alternative does not seem like a viable solution. So, the MATAP is to minimize both the master agents tour and the inter-agent communication between the master and the support agents. The formalization of the problem is given in the next sub-section. 6.8.1 Problem Formalization We define the following parameters: miMnihH0| ; set of hosts in the master itinerary ciniCC0| ; set of clusters hicijinjhC0| ; set of hosts in the cluster jiCC for all jiji therefore n c = | C | n hi = | C i | n m = | H M | ssiSnihH0| ; set of available hosts for the support itinerary cbiBnihH0| ; set of support agent hosts selected from H S SBHH and | H B | = n c

PAGE 141

129 h Bi C i ; h Bi is the support agent host corresponds to/selected for C i T H : TSP tour of H M T C : corresponding TSP tour of C (not used, helps understand the T S ) T S : corresponding TSP tour of H B Given the parameters we can define the MATAP as follows: The problem consists of finding the optimal TSP tour T H finding the optimal TSP tour T S selecting SBHH where the sum of the distances between h Bi and h cij is minimum. The corresponding minimization problem is to minimize the expression 1010110101),(),(),(cchimninibibinjijcbiniiihhhhhh where is the function that defines the distance between two hosts a and b in Euclidean metric. ),(ba The first term in the expression denotes the TSP tour of T H the last one is for TSP tour of T S and in between is the inter-agent distances of selected support agent hosts and the corresponding hosts in the clusters. However, the expression above is not exactly what we are to deal with since it denotes the whole distance (delay) of a mission. The first and the third terms actually overlap in time, and the former dominates the latter and is the one which is important. So, considering the mission execution time we need to refine the expression by replacing the last term with the total difference between the inter-cluster migration times of MA and the corresponding migration times of SA. We first need to define two more parameters:

PAGE 142

130 cCFiCFnihH0| ; set of hosts in the clusters to be visited by the MA First in the cluster cCLiCLnihH0| ; set of hosts in the clusters to be visited by the MA Last in the cluster where and iCFiCLiChh, MCLCFHHH, and we define ),(),(11bibiSiCFiCLiMihhShhS where 10cni so the SA wait time is given as otherwiseSSSSSAMiSiMiSiwi;0; where 10 cni So, when the last term in the above expression replaced the refined MATAP becomes the minimization of the expression 102010101),(),(cchimniniwinjijcbiniiiSAhhhh The MATAP is NP-hard since a deterministic polynomial time solution to this problem would also solve the clustering problem and TSP.

PAGE 143

131 6.8.2 Heuristics for MATAP We consider two heuristics for MATAP. The idea of the first algorithm follows the FRP heuristic given in Section 6.4.2. FRP is based on the patching heuristic (Lawler et al., 1985). They use the assignment problem heuristic to start with and create clusters/tours for smaller parts of the given input set of nodes. Then they use the patching heuristic to patch the tours together to obtain a complete tour of all nodes. It is possible to obtain good tours at the expense of computation time (Bentley, 1992). So, FRP provides a compromise between performance and efficiency. Using FRP it is easy to obtain clusters while building the tour. This is due to the fact that, FRP uses a K-d tree and its buckets as clusters and connects the clusters of hosts in buckets to obtain a complete tour. So, the idea is to use the clusters in FRP to provide a sub-optimal solution to the TSP, and to compute fragments in the master agent tour and use them to figure out the nearest support agent locations. As presented in Section 6.5.3, FRPs performance is poor compared to the other heuristics. Therefore we also introduce another simple heuristic with much better performance and efficiency as follows. We start with an NN tour, which has the 2-Opt property (note that a 2-Opted RR would also work), and form the clusters by considering the longest fragments between each two consecutive nodes in the tour. For example, if we need 5 clusters, we find the longest 4 such fragments in the tour and consider the nodes between each two consecutive fragments as one cluster. If we refer to Figure 6-3, the S M0 and S M1 are chosen as the longest fragments. In our implementation the only constraint is that the longest fragments chosen cannot be adjacent. This requires linear time on the number of nodes. Other constraints may be introduced; for example number of nodes in clusters can be made more balanced in polynomial time. The advantage of the heuristic is that we

PAGE 144

132 already have a near-optimal tour provided by 2-Opted NN for the master agent. By creating clusters out of this tour we just need to figure out the nearest hosts in the set of available support agent hosts, to these clusters. One way of doing this is to build a K-d tree of available SA hosts, compute the averages of coordinates in each cluster and then perform a nearest neighbor search on the tree with the input of cluster averages. Heuristic arguments can be summarized as follows: We need to compute a near optimal tour for the master agent anyway, and efficient implementations of algorithms are already in place. Because we form clusters as fragments in the master TSP tour, intra-cluster distances are already small. Because the inter-cluster fragments are the longest ones as possible (due to constraints) it can be expected that the possibility of SAs having a longer path to migrate between trusted hosts while the MA migrates to leave a cluster and enter the next one, is low. Therefore wait times for MA due to SA migrations can be ignored for more efficient computation. Because we form clusters as TSP tour fragments and then choose the nearest hosts to these clusters from the host set of support agent, it is highly likely that the tour of the support agent will be near-optimal under the other constraints the algorithm observes. 6.8.3 Experimental Evaluation We conducted simulation experiments for both of the heuristics from the previous subsection. In this subsection the details of our simulation experiments are given. 6.8.3.1 Simulation parameters The simulation parameters defined in Section 6.4.1 for single agent computations are valid here. In addition to them new parameters are defined as given in Table 6-4.

PAGE 145

133 Table 6-4. Simulation parameters Parameter Default value Number of hosts in the master itinerary 100 Transmission rate of all the links in the network 1 MB/s Primary security level 2 Secondary security level A Number of SA hosts 7 Number of available SA hosts 20 Size of an agent 40 KB Size of inter-agent messages 1 KB Size of messages in client-server communication 1 KB 6.8.3.2 Simulation strategy We follow generally the same strategy in Section 6.4.2 of single agent model. So, we choose the hosts in the master and support itineraries randomly from all the hosts in the network. The same is true for the home of the agents. These three sets of hosts are distinct. To ensure repeatability, for the random tour computations, we pick 100 different sets of hosts and report their averages. For all the experiments, we pick 3 different host sets and report the averages for the same reason. That is, for each of the three runs, we choose a set for MA itinerary, SA itinerary and the home. In this study, our main goal is to measure the mission communication time, which is the time observed by the end-user. So, we look at the problem from the application point of view rather than the network load overhead that is introduced by multiple agents. 6.8.3.3 Results and analysis Figure 6-4 shows the mission communication times for each selected mission strategy. The Single-Random and Single-Computed represent single agent missions. The former uses a random tour of an itinerary while the latter has a computed near-optimal tour of the same itinerary. The Client-Server line shows the time necessary to exchange two messages between each host in the itinerary and the home. Our aim is not to compare mobile agent computing with client-server computing which has been done before by

PAGE 146

134 many researchers, since the comparison yields many different conclusions depending on the application and the direct effect of this to the size of messages transferred between the two hosts. Our aim however is to give an idea about the size of the missions in our simulation environment and to be able to associate the values with real-life cases by using the client-server paradigm as the connection between the simulation environment and the actual Internet environment. The rest of the lines show the results of multiple-agent missions. In this category, the values in the graph includes both the MA tour and the inter-agent communication times. Both-Random means that both the tour of the MA and the selection of SA hosts are performed randomly. This is clearly the situation where we expect the worst results. FRP-Random and FRP-Selected both correspond to the MA tours computed using FRP, which correspond to the first heuristic of Section 6.8.2; the former picks the SA hosts randomly, while the latter selects the nearest SA hosts. The selection process uses a K-d tree where we build a tree of all available SA hosts and then use the nearest neighbor search routine to find the closest host to the given cluster. The input to the procedure is the simple average of the coordinate values of all the hosts in the cluster. The output of the procedure is the host that is closest to the given cluster average which represents all the nodes in the cluster.

PAGE 147

135 0500001000001500002000002500003000000100200300400500600700800Number of HostsMission Comm. Time (ms) Client-Server Single-Random Single-Computed Both-Random FRP-Random FRP-Selected NN-Selected Figure 6-4. Mission communication time across problem size NN-Selected uses the NN heuristic for the MA tour and selects the SA hosts with the same procedure as explained above. This corresponds to the second heuristic introduced in Section 6.8.2. Since the result of random selection behavior is already observed with the FRP heuristic above, we do not include the NN-Random strategy. It is interesting to see in the graph that the Single-Random and NN-Selected values are so close to each other that they cross each other at several points and overprint at some segments. The Single-Random represents the case where we have a single agent for the mission with no optimizations; that is the current situation in which we do not have TPNP and do not use TSP at all. The latter represents two agents as well as the communication between them, which uses two messages at each MA host as the default security level values. The conclusion is that the inter-agent communication overhead is compensated by the optimization of the tour length. Figure 6-5 displays a bar chart of MCTs versus categories of combined security levels defined in Section 5.2. The bar labeled as Average corresponds to Both-Random in the previous figure. As explained before security levels are defined as the number of

PAGE 148

136 messages exchanged between the agents. So, migration CETs are the same for each heuristic category in the figure. What changes is the number of messages (1,2, 3, or 4) exchanged and at what frequency (A, B, or C) the communication takes place. Some categories are almost the same in terms of the MCTs as can easily be observed from the figure. For example categories A2 and B4 have very similar MCT values since the total number of messages exchanged is the same. They are not exactly the same because the inter-host distances are not exactly the same. However, the trust that we can place on each category is different and may be interpreted as completely different depending on the application. This interpretation is subject to further research. 01000020000300004000050000600007000080000C1C2C3C4B1B2B3B4A1A2A3A4Security LevelMission Communication Time (ms) Average FRP-Random FRP-Selected NN-Selected Figure 6-5. Mission communication time across security level category In Figure 6-6 we show the results of another experiment to illustrate whether we can by chance create a near-optimal tour for the master itinerary and select good SA locations so that the results would be close to the computed configurations of the tour and the hosts. For this purpose we plotted for each category, average, minimum and maximum values of the Both-Random configuration. As it is seen in the figure, NN-Selected configuration outperforms even the minimum values of Both-Random category

PAGE 149

137 out of 100 different random configurations. We note here that the results are based on experimental evaluation and statistical analysis of the heuristic is subject to future research. 0100002000030000400005000060000700008000090000C1C2C3C4B1B2B3B4A1A2A3A4Security LevelMission Communication Time (ms) Min Average Max NN-Selected Figure 6-6. Mission communication time across random selection distribution over security levels Since there is no known way of predicting transmission rates of links in a large scale internetwork, in our experiments we have used a fixed value of 1 MB/s for all the paths in the network. Figure 6-7 displays how the configurations used in the experiments behave as the transmission rates increase. In the client-server case, the difference between points is so small that the line appears almost to be straight. This is due to our assumption of 1 KB message sizes. The two interesting configurations NN-Selected and Single-Random here shows another interesting behavior. Single-Random performs slightly better than the NN-Selected when the transmission rates increases. The reason is that there is no inter-agent communication in the Single-Random case meaning that there is no message exchange of 1 KB size. The MCT is consist only of 40 KB agent migrations, which explains why it is more prone to transmission rate increases. The summary of the figure is

PAGE 150

138 that transmission rate increase in the network has limited effect on the overall application performance, even with larger mobile agent sizes. We are still limited with the propagation delays and this validates our results which depend on network propagation delay estimations. 050001000015000200002500030000012345678Transmission Rate (MB/s)Mission Comm. Time (ms) Client-Server Random FRP-Selected NN-Selected Figure 6-7. Effect of transmission rates on mission communication time As mentioned before, we create different configurations of hosts for the home, the master itinerary and SA hosts from which the support agent itinerary is created. These hosts are selected in a pseudo-random fashion out of all the hosts in the topology. In this environment we wanted to see the effect of creating more available support agent hosts to choose from. While the default value is 20 as given in Table 6-1, Figure 6-8 tells us that the value we have chosen randomly was actually pretty good and no significant improvements are made with increasing numbers of potential SA hosts. The conclusion is that it is more valuable to have these hosts well distributed over the network rather than having more of them. This result tells us that context-awareness of TPNP is rather powerful characteristic than we have initially anticipated.

PAGE 151

139 05000100001500020000250000510152025303540Number of Avaliable SA HostsMission Comm. Time (ms) FRP-Selected NN-Selected Figure 6-8. Heuristic performance with the available SA hosts in the network A similar graph is presented in Figure 6-9. This time, we want to see the effect of the number of clusters, which is equal to the number of SA hosts used. The default value is 7 as given in Table 6-1. The increase clearly has a positive performance effect. But this increase diminishes at point 10. Although it is always possible to increase the performance by using more clusters, as discussed before this has a negative effect on the complexity of the system, security, and the difficulty due to availability of the SA hosts in the environment.

PAGE 152

140 0500010000150002000025000300000246810121Number of Clusters (SA hosts)Mission Comm. Time (ms) 4 FRP-Selected NN-Selected Figure 6-9. Heuristic performance with the number of clusters 6.9 Related Work Theilmann and Rothermel (2000a) proposed an approach to use Internet distance information for a specific application of mobile agents in information retrieval/filtering. The approach is called the dissemination of mobile agents. Their motivation is the assumption that every host on the Internet is a potential data warehouse but that not all of them can be assumed to employ a mobile agent system. Thus, the necessity of finding nearby hosts to interested warehouses that run a mobile agent system arises. The dissemination approach uses an underlying distance prediction system which is called the Internet Distance Maps (Theilmann & Rothermel, 2000b). The dissemination approach requires mobile agents to be forwarded to hosts participated in the system. Once a host receives a mobile agent, it decides whether forwarding the agent to another host would be beneficial in terms of communication costs. Thus, the agents are forwarded from host to host until they reach a host, which is closest to the intended warehouse. However it is not clear whether the underlying distance maps system is intended for this specific

PAGE 153

141 application only. If this is not the case, mobile agents are to be forwarded to ordinary hosts which do not have the mobile agent system to run them. So, these hosts are intermediaries which used only as routers. This introduces another problem to the already difficult problem of mobile agent protection. If the approach, on the other hand, is intended for mobile agent systems only, then it clearly fails to be a general-purpose, global system. Moreover, the dissemination approach do not address the security problems either the ones introduced by it, or the other general ones. As we already mentioned above, the approach addresses only a specific application area. To the best of our knowledge, the only study that considered the TSP for mobile agent applications is Brewington et al. (1999). Their target application is again information retrieval. They defined the Traveling Agent Problem, which adds the classical TSP, the probabilities of success for a mobile agent to complete a task, which is to find some specific information on a host. Once the agent finds the information needed it returns home immediately. Since the problem they defined is NP-complete, they simplified it by assuming constant latencies on the network. This makes the problem much simpler so that a polynomial time solution could be given. However, as we have shown in this chapter, there are numerous heuristics for TSP that could be used for mobile agent applications with success in terms of both performance and efficiency. The literature is rich with studies for quantitative analysis of mobile agent systems and applications. Strasser and Schwehm (1997) proposed a performance model for mobile agent systems for information retrieval applications. Johansen (1998) in addition to performance analysis of mobile agent systems shared their experiences with real mobile agent systems they had been using for years. The work on mobile agent

PAGE 154

142 performance evaluation can be categorized as modeling, quantitative analysis of communication and execution times as well as scalability. A summary survey for both categories is given by Gray et al. (2001). None of these studies however, considered network-awareness. 6.10 Conclusion and Future Work In this chapter we have shown how the knowledge of inter-host distances could be useful for both classical mobile agent systems and multiple mobile agent systems using the well-known TSP heuristics. We have also shown that the answers to the questions we asked at the beginning of the chapter are both yes. In multiple mobile agent systems we have shown that performance overhead of providing protection to mobile agents using the concept of information dispersal for security can be alleviated with negligible off-line computation overhead. For this purpose we have defined categories of security levels and analyzed the communication overhead introduced. We have also clearly presented the networkand context-awareness concepts in mobile agent computing. Overall the goal has been justified. Both TSP and multiple mobile agents computing are quite broad research areas. We believe that we have introduced an interesting research field with many open questions. Within the scope of this chapter, we could provide only the tip of the iceberg. As we pointed out at the beginning of the chapter, we did not target any specific application area of mobile agents. Every application has its own requirements and characteristics and these need to be analyzed. For example information retrieval applications should consider the size of the relevant information and therefore the size of the mobile agents. In software distribution, the number of the sites to be visited and the number of agents that need to be employed should be taken into account. This application

PAGE 155

143 may lend itself to a variant of TSP, which is known as vehicle routing problem or multiple salesman problem. In addition to application execution time, network load of multiple mobile agent systems need to be analyzed. We have considered only the master/support agent model with two agents in this study. The other models can also be studied with varying number of mobile agents. For example, the master/support agent model admits more than one master agent. How many agents are to be employed for a specific mission of an application and how to route them efficiently by also observing the security requirements are all open questions. A more comprehensive study should also take into account the time necessary to obtain the network/context information. It is possible to improve the TSP implementation performance without much efficiency degradation. For example, in addition to the 2-Opt heuristic, 2H-Opt and even 3-Opt heuristics can be implemented.

PAGE 156

CHAPTER 7 SUMMARY AND FUTURE DIRECTIONS This research proposes an architectural model (MMAS) for multiple mobile agent systems as a future computation paradigm with a special focus on the support for security and mobility. Chapter 2 provides a comprehensive background on mobile agent computing and security, and justifies the use of mobile agent technologies. Chapter 3 extends the mobile agent concept to include multiple agent collaboration for enhancing security, which is considered a major hindrance toward wider acceptance of mobile agent computing. The major technical contributions in the research are categorized in three complementary system supports for MMASs: Information dispersal for agent protection The need for computing with secrets in public can be supported by a non-cryptographic scheme using information dispersal, which enhances security through protection as a whole. Chapter 4 demonstrates this concept with the application of distributed digital signing, which is an essential function for e-commerce systems. The results show collaborating mobile agents can effectively implement distributed digital signing. Positioning service for mobile agents The mobility of mobile agents require an efficient network positioning service. Chapter 5 proposes a peer-to-peer coordinate-based network positioning system for computing the distances between network nodes to facilitate the migration of mobile agents. Simulation results show that the architecture could provide more accurate predictions of the distances than previously proposed approaches, and the system is also more scalable. An additional advantage of the MMAS is that the architecture addresses not only network-awareness but also context-awareness. Itinerary management for collaborating agents The itinerary of a mobile agent(s) is a key component. Traveling with respect to an itinerary list is akin to the traveling salesperson problem, except in the context of multiple collaborating mobile agents, the problem becomes much more complex. Chapter 6 addresses the mission optimization of multiple inter-dependent itineraries, and proposes 144

PAGE 157

145 heuristics for itinerary traversal based on the positioning service in Chapter 5. Through simulation experiments, it is shown that performance overhead of providing protection to mobile agents in MMAS could be reduced to an acceptable level and is proven feasible. Likewise, the future directions of the research can be grouped in three major sub-areas: Chapter 4 addresses a difficult problem of digital signing with mobile agents for e-commerce applications. However, the responsibility of the security component in the proposed architecture is much boarder. Application of information dispersal for security to general data, code and state information carried by agents remains open. There are numerous approaches to solving the general agent protection problem. Adapting and automating some of the promising solutions in the MMAS is necessary, in particular, how detection mechanisms can be adapted as prevention mechanisms in the architecture. The network positioning service discussed in Chapter 5 is a research area of its own. The architecture we proposed provides distance information in terms of delay measurements. It would be useful to include transmission rates and hop counts. Orthogonal to this direction, the other open question is how to achieve better prediction accuracy in these systems. This question is more application-specific in mobile agent computing. We could improve the system with more contextual information in MMASs. The mission optimizer component of the MMAS architecture opens up a new and interesting field of research. Chapter 6 integrates network distance estimation and TSP into mobile agent computing, and shows the potential benefits from a broad perspective. Different mobile agent applications will require different types of missions. New mission models necessitate extensions or variants of TSP heuristics. An interesting example is to determine the applicability of multiple salesman or vehicle routing problems to mobile agent computing in general and MMAS in particular. Furthermore, the Directory system of the proposed architecture was not addressed in the scope of this study and is subject to future research of its own. In traditional mobile agent computing, this component refers usually to a centralized database system, where agents can query and locate the hosts of interest for their missions. In MMASs, the directory component should also be responsible for providing context information, in cooperation with a network positioning system that is capable of providing the

PAGE 158

146 infrastructure for obtaining the information. Therefore, we presume that such a system needs to be a full-fledged, scalable peer-to-peer distributed system in order to collect information from hosts and provide the same information to interested hosts efficiently.

PAGE 159

REFERENCES Baldi, M., Gai, S., & Picco, G. P. (1998). Exploiting code mobility in decentralized and flexible network management, Mobile Agents, Lecture Notes in Computer Science Vol. 1219, pp. 13-26, Springer-Verlag. Baldi, M. & Picco, G. P. (1998). Evaluating the tradeoffs of mobile code design paradigms in network management applications Proceedings of the 20th International Conference on Software Engineering, pp. 146 Kyoto, Japan: IEEE Press. Barak, B., Goldreich, O., Impagliazzo, R., Rudich, S., Sahai, A., Vadhan, S., & Yang, K. (2001). On the (im)possibility of obfuscating programs, In J. Kilian (Ed.) Proceedings of the 21 st Annual International Conference, Lecture Notes in Computer Science Vol. 2139, pp. 1-18, Springer-Verlag. Bellare, M. & Rogaway, P. (1996) The exact security of digital signatures: how to sign with RSA and Rabin, In U. Maurer (Ed.), Advances in Cryptology Eurocrypt 96 Proceedings, Lecture Notes in Computer Science Vol. 1070, pp. 399-416, Springer-Verlag. Bentley, J. L. (1975). Multidimensional binary search trees used for associative searching, Communications of the ACM, 18(9), pp. 509-517. Bentley, J. L. (1990a). Experiments on traveling salesman heuristics, Proceedings of First Symposium on Discrete Algorithms, pp. 91-99, Philedelphia, PA: SIAM Press. Bentley, J. L. (1990b). K-d trees for semidynamic point sets, Proceedings of Sixth Annual ACM Symposium on Computational Geometry, pp. 187-197, New York, NY: ACM Press. Bentley, J. L. (1992). Fast algorithms for geometric traveling salesman problems, ORSA Journal on Computing, 4(4), pp. 387-411. Berkowitz, S., Guttman, J. D., & Swarup V. (1998). Authentication for mobile agents, Mobile Agents and Security, Lecture Notes in Computer Science Vol. 1419, Springer-Verlag, pp.114-136. Bettini, L., Nicola, R. D., & Loreti, M. (2002). Software update via mobile agent based programming, Proceedings of the 2002 ACM Symposium on Applied Computing, pp. 32-36, Madrid, Spain: ACM Press. 147

PAGE 160

148 Boneh, D., & Franklin, M. (1997). Efficient generation of shared RSA keys, Lecture Notes in Computer Science Vol. 1233, Springer-Verlag, pp. 425-439. Borselius, N., Mitchell, J. C., & Wilson, A. (2001a). On mobile agent based transactions in moderately hostile environments, Proceedings of IFIP First Annual Working Conference on Network Security, pp, 173-186, Deventer, The Netherlands: Kluwer, B.V. Borselius, N., Mitchell, J. C., & Wilson, A. (2001b). Undetachable threshold signatures, Proceedings of the 8th IMA International Conference, Lecture Notes in Computer Science Vol. 2260, pp. 239-244, Springer-Verlag. Boyd, C. (1988). Some applications of multiple key ciphers, Advances in Cryptology, EUROCRYPT Proceeding, Lecture Notes in Computer Science Vol. 330, pp. 455-467, Springer-Verlag. Boyd, C., (1989). Digital multisignatures, Cryptography and Coding, pp. 241-246, London, UK: Oxford University Press. Bradshaw, J. M. (Ed.), (1997). Software Agents, Cambridge, MA: AAAI Press/The MIT Press. Brazier, F. M. T., Overeinder, B. J., Steen, M. V., & Wijngaards, N. J. E. (2002). Agent factory: generative migration of mobile agents in heterogeneous environments, Proceedings of the 2002 ACM Symposium on Applied Computing, pp. 101-106, Madrid, Spain: ACM Press. Breugst, M. & Magedanz, T. (1998). Mobile agents enabling technology for active intelligent network implementation, IEEE Network, Special Issue on Active and Controllable Networks, 12(3), pp. 53 60. Brewington, B., Gray, R., Moizumi, K., Kotz, D., Cybenko G., & Rus, D. (1999). Mobile agents for distributed information retrieval, Chapter 15 in M. Klusch (Ed.) Intelligent Information Agents Agent-Based Information Discovery and Management on the Internet, Berlin: Springer-Verlag. Busch, C., Roth, V., & Meister R. (1998). Perspectives on electronic commerce with mobile agents, Proceedings of 11th Amaldi Conference on Problems of Global Security. pp. 89-101, Moscow, Russia: Russian Academy of Sciences. Busse, I., Covaci, S., & Leichsenring A. (1999). Autonomy and decentralization in active networks: a case study for mobile agents, in S. Covaci (Ed.) Proceedings of First International Conference on Active Networks, Lecture Notes in Computer Science Vol. 1653, pp. 167-179, Springer-Verlag. Chess, D., Grosof, B., Harrison, C., Levine, D., Parris, C., & Tsudik, G. (1995a). Itinerant agents for mobile computing, IEEE Personal Communications, pp. 34-49.

PAGE 161

149 Chess, D., Harrison, C., & Kershenbaum, A. (1995b). Mobile agents: are they a good idea?, IBM Research Report, RC 19887, IBM Research Division. Chess, D. M. (1998). Security issues in mobile code systems, Mobile Agents and Security, Lecture Notes in Computer Science Vol. 1419, pp. 1-14. Chow, R. & Johnson, T, (1997). Distributed Operating Systems and Algorithms, Reading, MA: Addison-Wesley. Claessens, J., Preneel, B., & Vandewalle, J. (2003). (How) Can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions, ACM Transactions on Internet Technology, 3(1), pp. 28-48. Corradi, A., Montanari, R., & Stefanelli, C. (1999). Security issues in mobile agent technology, Future Trends of Distributed Computing Systems, Proceedings of the 7 th IEEE Workshop on FTDCS, pp. 3-8, Cape Town, South Africa: IEEE Press. Desmedt, Y. (1997). Some recent research aspects of threshold cryptography, Lecture Notes in Computer Science Vol. 1396, pp.158-173, Springer-Verlag. dInverno, M. & Luck, M. (2001). Understanding Agent Systems, New York: Springer-Verlag. Dyer, D. (1997). Java decompilers compared, http://www.javaworld.com/javaworld/jw-07-1997/jw-07-decompilers_p.html July 1997, retrieved September 2001. ElGamal, T. (1985). A public key cryptosystem and a signature scheme based on discrete logarithms, IEEE Transactions on Information Theory, IT-31 (4), pp. 10-18. Fabre, J.C., Deswarte, Y., & Randell, B. (1994). Designing secure and reliable applications using fragmentation-redundancy-scattering: an object-oriented approach, Proceedings of Dependable Computing EDCC-1, Lecture Notes in Computer Science Vol. 852, pp. 21-38, Springer-Verlag. Faloutsos, M., Faloutsos, P., Faloutsos, C. (1999). On power-law relationships of the Internet topology, Proceedings of SIGCOMM, pp. 251, Cambridge, MA: ACM Press. Farmer, W., Guttman, J., & Swarup, V. (1996). Security for mobile agents: authentication and state appraisal, Proceedings of the 4 th European Symposium on Research in Computer Security (ESORICS), pp. 118-130, London, UK: Springer-Verlag. Feigenbaum, J. & Lee, P. (1997). Trust management and proof carrying code in secure mobile code applications, Proceedings of DARPA Workshop on Foundations for Secure Mobile Code, Monterey, CA: Kluver Academic Publishers.

PAGE 162

150 Francis, P., Jamin, S., Jin, C., Jin, Y., Raz, D., Shavitt, Y., & Zhang, L. (2002). IDMaps: a global Internet host distance estimation service, IEEE/ACM Transactions on Networking, 9(5), pp. 525-540. Frankel, Y. & Desmedt, Y.G. (1992). Parallel reliable threshold multisignature, Technical Report: Department of E.E. and C.S., University of Wisconsin-Milwaukee, TR-92-04-02. Franklin, S. & Gaesser, A. (1997). Is it an agent, or just a program? A taxonomy for autonomous agents, in J.P. Muller, M.J. Wooldridge, N.R. Jennings, (Eds.) Intelligent Agents III, Proceedings of Third International Workshop on Agent Theories, Architectures and Languages, Lecture Notes in Artificial Intelligence Vol. 1193, pp. 21-35, Springer-Verlag. Fray, J.M. & Fabre, J.C. (1991). Fragmented data processing: an approach to secure and reliable processing in distributed computing systems, Dependable Computing for Critical Applications, pp. 323-343, Berlin: Springer-Verlag. Gray, R., Kotz, D., Nog, S., Rus, D., & Cybenko, G. (1996). Mobile agents for mobile computing, Technical Report, Dept. of Computer Science, Dartmouth College, PCS-TR-96-28. Gray ,R. S., Kotz, D., Peterson, R. A., Barton, J., Chacon D., & Gerken, P. (2001) Mobile agent versus client/server performance: scalability in an information retrieval task, Proceedings of the 5 th International Conference on Mobile Agents, Lecture Notes in Computer Science Vol. 2240, pp. 229-243, Springer-Verlag. Gummadi, K. P., Saroui, S., & Gribble, S. D. (2002). King: estimating latency between arbitrary Internet end hosts, Proceedings of the (SIGCOMM) Internet Measurement Workshop, Marseille, France: ACM Press. Hartman, J., Manber, U., Peterson, L., & Proebsting, T. (1996). Liquid software: a new paradigm for networked systems, Technical Report: Department of Computer Science, University of Arizona, TR 96-11. Hohl, F. (1998a). Time limited blackbox security: protecting mobile agents from malicious hosts, Mobile Agents and Security, Lecture Notes in Computer Science Vol. 1419, pp. 92-113, Springer-Verlag. Hohl, F. (1998b). A model of attacks of malicious hosts against mobile agents, Proceedings of the 4 th Workshop on Mobile Object Systems: Secure Internet Mobile Computations, London, UK: Springer-Verlag. Hotz, S. M. (1994). Routing information organization to support scalable interdomain routing with heterogeneous path requirements, PhD Thesis, University of Southern California.

PAGE 163

151 Jamwal, V., & Iyer, S. (2003). Mobile agent based realization of a distance evaluation system, in S. Helal, Y. Oie, C. Chang, J. Murai (Eds.) Proceedings of 2003 Symposium on Applications and the Internet, pp. 362-369, Los Alamitos, CA: IEEE Press. Jansen, W. A. (2001). Countermeasures for mobile agent security, Computer Communications, Special Issue on Advanced Security Techniques for Network Protection, Elsevier Science BV. Jansen, W, Mell, P., Karygiannis, T., & Marks, D. (2000). Mobile agents in intrusion detection and response, Proceedings of the 12 th Annual Canadian Information Technology Security Symposium, Ottawa, Canada. Johansen, D. (1998). Mobile Agent Applicability, Proceedings of Mobile Agents: Second International Workshop, MA'98, Lecture Notes in Computer Science Vol. 1477, pp. 99-111, Springer-Verlag. Karjoth, G., Asokan, N., & Gulcu, C. (1998). Protecting the computation results of free-roaming agents, Proceedings of 2 nd International Workshop of Mobile Agents, Lecture Notes in Computer Science Vol. 1477, pp. 195-207, Springer-Verlag. Karnik, N. (1998). Security in mobile agent systems, Ph.D. Dissertation, Department of Computer Science and Engineering, University of Minnesota. Katz, J., & Wang, N. (2003). Efficiency improvements for signature schemes with tight security reductions, Proceedings of the 10th ACM Conference on Computer and Communications Security. pp. 155-164, New York, NY: ACM Press. Kaufman, C., Perlman, R., & Speciner, M. (1995). Network Security, Englewood Cliffs, NJ: Prentice Hall. Kiniry J., & Zimmerman D. (1997). A hands-on look at Java mobile agents, IEEE Internet Computing, July-August 1997, pp. 21-30. Klusch M. (Ed.) (1999), Intelligent information agents, Agent-Based Information Discovery and Management on the Internet, Berlin: Springer-Verlag. Kotzanikolaou, P., Burmester, M., & Chrissikopoulos, V. (2000). Secure transactions with agents in hostile environments, Lecture Notes in Computer Science Vol. 1841, pp. 289-297, Springer-Verlag. Lange, D. B., & Oshima, M. (1998). Programming and Deploying Java Mobile Agents with Aglets, Reading, MA: Addison-Wesley. Lawler, E. L., Lenstra, J. K., Kan, A. H. G. R., & Shmoys, D. B. (Eds) (1985). The Traveling Salesman Problem: A Guided Tour of Combinatorial Optimization, Chichester: John Wiley & Sons.

PAGE 164

152 Lee, P., & Necula, G. (1997). Research on proof-carrying code for mobile code security, Proceedings of the DARPA Workshop on Foundations for Secure Mobile Code, Monterey, CA: Kluver Academic Publishers. Lim, H., Hou, J. C., & Choi, C-H. (2003). Constructing Internet coordinate system based on delay measurement, Proceedings of Internet Measurement Conference, pp. 129-142, New York, NY: ACM Press. Malkhi, D., & Reiter, M. K. (2000). Secure execution of Java applets using a remote Playground, IEEE Transactions on Software Engineering, 26(12), pp. 1197-1209. Marques, P. J., Silva, L. M., & Silva, J. G. (1999). Security mechanisms for using mobile agents in electronic commerce, Proceedings of the 18 th IEEE Symposium on Reliable Distributed Systems, pp. 378-383, Washington, DC: IEEE Press. Meadows, C. (1997). Detecting attacks on mobile agents, Proceedings of DARPA Workshop on Foundations for Secure Mobile Code, Monterey, CA: Kluver Academic Publishers. Meer, H. D., Corte, A. L., Puliafito, A., & Tomarchio, O. (2000). Programmable agents for flexible QoS management in IP networks, IEEE Journal on Selected Areas in Communication, 18(2), pp. 145-162. Minsky, Y., Renesse, R., Schneider, F. B., & Stoller, S. D. (1996). Cryptographic support for fault-tolerant distributed computing, Technical Report, TR96-1600, Dept. of Computer Science, Cornell University. Murch, R. & Johnson, T. (1998). Intelligent Software Agents, Englewood Cliffs,NJ: Prentice Hall. Ng, S-K. (2000). Protecting mobile agents against malicious hosts, Masters Thesis, Division of Information Engineering, The Chinese University of Hong Kong. Ng, T. S. E. & Zhang, H. (2002). Predicting Internet network distance with coordinates-based approaches, Proceedings of IEEE INFOCOM 2002, Vol. 21, No. 1, pp. 170-179. Oaks, S. (1999). Java Security, Sebastopol: OReilly and Associates. Onbilger, O.K., Newman, R., & Chow, R. (2001). A distributed and compromise-tolerant mobile agent protection scheme, Proceedings of International Conference on Intelligent Agents, Web Technologies and Internet Commerce, Las Vegas, Nevada, pp. 394-400. Oppliger, R. (1999). Security issues related to mobile code and agent-based systems, Computer Communications, No. 22, pp. 1165-1170, Elsevier Science BV.

PAGE 165

153 Ordille, J. J. (1996). When agents roam, who can you trust?, Proceedings of the First Conference on Emerging Technologies and Applications in Communications, Portland, OR: IEEE Press. Papavassiliou, S., Puliafito, A., Tomarchio, O., & Ye, J. (2002). Mobile agent-based approach for efficient network management and resource allocation: framework and applications IEEE Journal on Selected Areas in Communications, 20(4), pp. 858 Pias, M., Crowcroft, J., Wilbur, S., Harris, T., & Bhatti, S. (2003). Lighthouses for scalable distributed location, Proceedings of the 2 nd International Workshop on P2P Systems, Lecture Notes in Computer Science Vol. 2429, Springer-Verlag. PKCS#1: RSA Cryptography Standard, Version 2.1, RSA Laboratories (2002). Rabin, M. O. (1989). Efficient dispersal of information for security, load balancing, and fault tolerance, Journal of the ACM, 36(2), pp.335-348. Ratnasamy, S., Francis, P., Handley, M., Karp, R., Shenker, S. (2001). A scalable content-addressable network, Proceedings of SIGCOMM 2001, pp. 161-172, San Diego, CA: ACM Press. Ratnasamy, S., Handley, M., Karp, R., and Shenker, S. (2002). Topologically-aware overlay construction and server selection, Proceedings of IEEE INFOCOM 2002, Vol. 21, No. 1, pp. 1190-1199. Riordan, J., & Schneier, B. (1998). Environmental key generation towards clueless agents, Mobile Agents and Security, Lecture Notes in Computer Science Vol. 1419, pp. 15-24, Springer-Verlag. Rivest, R.L., Shamir, A., & Adleman, L. (1978). A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM, 21(2), pp. 120-126. Roth, V. (1998). Secure recording of itineraries through co-operating agents, Proceedings of 4 th ECOOP Workshop on Mobile Object Systems, London, UK: Springer-Verlag. Roth, V., Jalali, M., Hartman, R., & Roland, C. (2000). An application of mobile agents as personal assistants in electronic commerce, Proceedings of 5th Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, pp. 121-132, Manchester, UK: Springer-Verlag. Roth, V. (2001). On the robustness of some cryptographic protocols for mobile agent protection, in G. P. Picco (Ed.) Proceedings of 5 th International Conference on Mobile Agents, Lecture Notes in Computer Science Vol. 2240, pp. 1-14, Springer-Verlag.

PAGE 166

154 Sander, T., & Tschudin, C.F. (1998). Protecting mobile agents against malicious hosts, Mobile Agents and Security, Lecture Notes in Computer Science Vol. 1419, pp. 44-60, Springer-Verlag. Sandholm, T., & Huai, Q. (2000). Nomad: mobile agent system for an Internet-based auction house, IEEE Internet Computing, 4(2), pp. 80-86. Schill, A., Held, A., Bohmak, W., Springer, T., & Ziegert, T. (1998). An agent based application for personalized vehicular traffic management, In K. Rothermel and F. Hohl (Eds.) MA, Lecture Notes in Computer Science Vol. 1477, pp. 99-111, Springer-Verlag. Shamir, A. (1979). How to share a secret, Communications of the ACM, 22(11), pp. 612-613. Stamos, J. W., & Gifford, D. K. (1990). Remote evaluation. ACM Transaction on Programming Languages and Systems, 12(4), pp. 537-564. Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., & Balakrishnan, H. (2001). Chord: a scalable peer-to-peer lookup protocol for Internet applications, Proceedings of SIGCOMM 2001, pp. 17-31, San Diego, CA: ACM Press. Strasser, M., Schwehm, M. (1997). A performance model for mobile agent systems, H. Arabnia (ed.), Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications, Volume II, pp. 1132-1140. Tanenbaum, A. S., & van Steen, M. (2002). Distributed Systems, Principles and Paradigms, Upper Saddle River, NJ: Prentice Hall. Tang, L. & Crovella, M. (2003). Virtual landmarks for the Internet, Proceedings of Internet Measurement Conference, pp. 143-152, New York, NY: ACM Press. Tangmunarunkit, H., Govindan, R., Jamin, S., Shenker, S., & Willinger, W. (2001). Network topologies, power laws and hierarchy, Technical Report, TR01-746, University of Southern California. Tennenhouse, D. L., & Wetherall, D. J. (1996). Towards an active network architecture, Computer Communication Review, 26(2), pp. 5-17, April 1996. Tennenhouse, D. L., Smith, J. M., Sincoskie, W. D., Wetherall, D. J., & Minden, G. J. (1997). A survey of active network research, IEEE Communications, 35(1), pp. 80-86. Theilmann, W., & Rothermel K. (2000a). Optimizing the dissemination of mobile agents for distributed information filtering, IEEE Concurrency, pp. 53-61. Theilmann, W., & Rothermel, K. (2000b). Dynamic distance maps of the Internet, Proceedings of 19 th IEEE Infocom 2000, pp. 275-284, Tel Aviv, Isreal: IEEE Press.

PAGE 167

155 Tschudin, C. F. (1999). Mobile agent security, Chp. 18 of M. Klusch (Ed.) Intelligent Information Agents Agent-Based Information Discovery and Management on the Internet, pp. 431-445, Berlin: Springer-Verlag. Vigna, G. (1998). Cryptographic traces for mobile agents, Mobile Agents and Security, Lecture Notes in Computer Science Vol. 1419, pp.137-153, Springer-Verlag. Wilhelm, U. G., Staamann, S., & Buttyan, L. (1998). On the problem of trust in mobile agent systems, Proceedings of NDSS, San Diego, CA: Internet Society Press. Wilhelm, U. G., Staamann, S., & Buttyan, L. (1999). Introducing trusted third parties to the mobile agent paradigm, Secure Internet Programming Security Issues for Mobile and Distributed Objects, Lecture Notes in Computer Science Vol. 1603, pp. 469-489, Springer-Verlag. Wohlmacher, P. (1999). Introduction to the taxonomy of multiple cryptography, Proceedings of the Multimedia and Security Workshop at ACM Multimedia'99, Orlando, FL: ACM Press. Wu, T., Malkin, M., & Boneh, D. (1999). Building intrusion tolerant applications, Proceedings of the 8th USENIX Security Symposium, pp. 79-91, Washington DC: Usenix. Yee, B. S. (1999). A sanctuary for mobile agents, Secure Internet Programming Security Issues for Mobile and Distributed Objects, Lecture Notes in Computer Science Vol. 1603, pp. 261-273, Springer-Verlag. Young A., & Yung, M. (1997). Sliding encryption: A cryptographic tool for mobile agents, in E. Biham (Ed.) Proceedings of the 4 th International Workshop on Fast Software Encryption, Lecture Notes in Computer Science Vol. 1267, pp. 230-241, Springer-Verlag. Zander, J., & Forchheimer, R. (1988). The SOFTNET project: a retrospect, Conference Proceedings on Area Communication, 8 th European Conference on Electrotechnics, EUROCON, pp. 343-345, Stockholm, Sweden: IEEE Press.

PAGE 168

BIOGRAPHICAL SKETCH Oguz Kaan Onbilger received his Bachelor of Science degree from the Department of Computer Science and Engineering at Hacettepe University, Turkey, in 1990. He received his Master of Science degree in computer engineering from Middle East Technical University, Turkey, in 1995. He will receive the Doctor of Philosophy degree from the Department of Computer and Information Science and Engineering at the University of Florida in December 2004. Between and during the academic programs he completed, he worked in the industry several years before he joined the doctorate program. His research interests are computer networks and security, mobile code systems, and Internet/distributed computing. 156


Permanent Link: http://ufdc.ufl.edu/UFE0008327/00001

Material Information

Title: A Computation Paradigm for Multiple Mobile Agent Systems
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0008327:00001

Permanent Link: http://ufdc.ufl.edu/UFE0008327/00001

Material Information

Title: A Computation Paradigm for Multiple Mobile Agent Systems
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0008327:00001


This item has the following downloads:


Full Text












A COMPUTATION PARADIGM FOR MULTIPLE MOBILE AGENT SYSTEMS


By

OGUZ KAAN ONBILGER













A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2004

































Copyright 2004

by

Oguz Kaan Onbilger





























To
my unborn son Alpkan















ACKNOWLEDGMENTS

I would like to express my gratitude to my advisor, Dr. Randy Chow, for his

guidance and support, which made this study possible and for sharing his wisdom with

me. I also would like to thank my co-advisor, Dr. Richard Newman, for fruitful

suggestions, and sharing his intelligence and experience. I thank both of my advisors for

patiently listening to my presentations during the weekly group meetings and providing

their guidance.

I also would like to thank my committee members, Dr. Jih-Kwon Peir, Dr.

Abdelsalam Helal and Dr. Suleyman Tufekci, for their efforts and brainstorming to make

it clear what I was trying to do and their helpful comments and suggestions. Special

thanks go to Dr. Shigang Chen for providing the network simulation software he

developed and his collaboration and discussions. Thanks go again to Dr. Randy Chow for

encouraging this collaboration.

Very special thanks go to my parents for their continual emotional support from

thousands of miles away.

Finally, I express my gratitude to my beloved wife, Derya, for her constant love,

encouragement, patience, and support through difficult times. Without her, this study

would never have been completed.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF TABLES ........................................................ ........... ........... .. viii

LIST OF FIGURES ......... ......................... ...... ........ ............ ix

ABSTRACT .............. .................. .......... .............. xi

CHAPTER

1 INTRODUCTION ................................................................. ..... ....

2 BACKGROUND .................................. ...... .... ..................

2.1 Softw are Agents and M ulti-Agent System s ........................................ ................7
2.2 The M obile C ode C oncept........................................................... ............... 9
2.3 The M obile Agent Paradigm ...................................................... ..................11
2.3.1 Applications of M obile Agents ................ .................. ....................13
2.3.2 M obile A gent System s ........................................ .......... ............... 15
2.3.3 W hat M obile Agents Offer .............................. ..................................... 19
2.3.4 Drawbacks of the Mobile Agent Paradigm ..............................................22
2.4 Security Problem of Mobile Agents ........................................... ...............23
2.4.1 M alicious A gents Problem ......................... .... .... ............... .... 25
2.4.1.1 General protection mechanisms against possibly malicious mobile
code ............... .......... ....... ........................... ...... ....... 25
2.4.1.2 Specific protection mechanisms against possibly malicious agents 27
2.4.2 M alicious H osts Problem ........................................ ....................... 29

3 MULTIPLE COOPERATING MOBILE AGENTS ...............................................35

3 .1 In tro du ctio n .................. ................................................ ................ 3 5
3.2 R equirem ents and Objectives ........................................ .......................... 37
3 .3 D efin ition s ................................................................4 0
3.4 M mission M models .................... .............. ....... ....... .. ..... .. ...... ... .......... 4 1
3.5 Multi-agent Systems (MAS) vs. Multiple Mobile Agent Systems (MMAS).......44
3.6 Proposed Architecture for M M ASs ........................... ....................45
3.7 E xam ple M issions............. .......................................................... ...... .... ..... 48
3.8 R elated W ork ............................................................... 52


v









4 REMOTE DIGITAL SIGNING WITH MOBILE AGENTS................................54

4.1 Introduction ...................................... ............................................ .. 54
4.2 Electronic Commerce and Mobile Agents............... .............. ...................54
4.3 M obile Commerce and M obile Agents...................................... ............... 55
4.4 Mobile Agent Security in Mobile Commerce ............................................... 55
4 .5 O b je ctiv e s ....................................................... ................ 5 7
4.6 Background .................................... ................................ .........58
4.7 M multiple C ryptography ................................................ ............................. 61
4.8 Key Splitting and Signature Generation...................... ..................63
4.8.1 Using the Multiplicative Property of RSA.................. ..................64
4.8.2 Using the Additive Property of RSA.......................... ................. 65
4.8.3 Using El Gamal Public Key Cryptosystem .............................................66
4.8.3.1 Signing in sequence with El Gamal signature scheme...................67
4.8.3.2 Signing in parallel with El Gamal signature scheme .....................69
4.8.3.3 Transition from El Gamal cryptosystem to digital signature
algorithm ..... .................. .... .. ...................... 70
4.9 The Overall System for Remote Digital Signing............................................71
4.10 Using Limited-liability Keys and Public Key Certificates.............................74
4.11 Practical Issues of Remote Digital Signing ................... ................... ........... 78
4.11.1 Probabilistic Signature Scheme and its Impact on Practice ...................79
4.11.2 Performance Considerations and the Big Picture................................80

5 A NETWORK POSITIONING ARCHITECTURE FOR MOBILE AGENTS......... 84

5 .1 In tro d u ctio n ................................................... .............. ................ 8 4
5.2 R elated W ork ................................................................................ .. ................. 85
5.3 T PN P A approach .......... .............................................. .............. .......... ....... 88
5.3.1 T he A lgorithm .......................... ...................... ............ .. ........... 90
5.3 .2 Starting the Sy stem ......................................................................... .. .... 95
5.3.3 Scalability Issues ....................................... ...... ............ ............. 96
5.3.4 Security C onsiderations.................................... ......................... ........... 97
5.4 Experim ental Evaluation ............................................. ............................. 97
5.4.1 Sim ulation Environm ent....................................... .......................... 98
5.4.2 Sim ulation P aram eters.................................................................... ..... 99
5.4.3 Sim ulation Strategy ............................................................................. 99
5.4.4 Sim ulation R results and A nalysis.............................................................100
5.5 C conclusion ............................................................... ... ... ......... 104

6 QUANTITATIVE ANALYSIS OF MULTIPLE MOBILE AGENT SYSTEMS... 106

6.1 Introduction .............................. ... .................. ........ ................. 106
6.2 Network-awareness in Mobile Agent Computing ......................... ...........107
6.3 The Traveling Salesperson Problem .................................... .........................108
6.4 Application of TPNP and TSP to Classical MA Model .............. .................111
6.4.1 The D ata Structure...................... .... ............................... ..111
6.4.2 The Heuristics .................. ..................................... ... ........ 112









6.5 Experim mental Evaluation ...................................................... ...... ............... 113
6.5.1 Simulation Environment and Parameters .............................................. 113
6.5.2 Sim ulation Strategy ........................................................ ............... 114
6.5.3 R results and A nalysis....................................................... .................. 114
6.6 Context-awareness in MA Computing .................................... ............... 120
6.7 Multiple Cooperating Mobile Agents Model ............................................. 122
6.7.1 Trust M odel ...................... .................. ... .... .. ....... .. ....... 122
6.7.2 Perform ance M odel ....................................... ...... .................... 124
6.8 Application of TPNP to Multiple Cooperating MAs .............. .... ...............126
6.8.1 Problem Form alization ................................... ............................. ....... 128
6.8.2 H euristics for M A TAP ........................................ ......... ............... 131
6.8.3 Experim ental Evaluation ....................................................................... 132
6.8.3.1 Sim ulation param eters................................................................ 132
6.8.3.2 Sim ulation strategy...................................... ........ ............... 133
6.8.3.3 R results and analysis ............................................ ............... 133
6.9 R elated W ork ............................................................................... 140
6.10 Conclusion and Future Work................ ...................... .... ........... 142

7 SUMMARY AND FUTURE DIRECTIONS.......................................... .....144

R E F E R E N C E S ....................................... ........................................................... .. 14 7

BIOGRAPHICAL SKETCH ............... ............ ................................ ............... 156
















LIST OF TABLES

Table page

3-1. Comparison of MAS and MMAS................................................................ 44

6-1. Application of NN heuristic with TPNP ............ .......................................... 118

6-2. Application of RA heuristic with TPNP.............................................................118

6-3. Application of FRP heuristic with TPNP ...........................................................118

6-4 Sim u nation p aram eters ................................................................... ..................... 133
















LIST OF FIGURES

Figure page

2-1. M obile agent execution m odel .............................................................................12

2-2. M obile agent execution platform .......................................................... .... ............ 16

3-1. M obile client/server m odel ............................ ............... ..... .... ............ ............... 42

3-2. Multiple mobile agents model with two mobile agents........................... ...........43

3-3. Multiple mobile agent system architecture...... ....................... ...........46

4-1. A snapshot of a mission using multiple mobile agents ...........................................67

4-2. Protocol for sequential signing with multi-agent model ........................................72

4-3. Protocol for parallel signing with multi-agent model ...........................................73

4-4. Lim ited-liability key protocol......................................................... ............... 77

5-1. Global netw ork positioning m odel (GN P)....................................... .....................86

5-2. Local network positioning model (TPNP) ..................................................88

5-3 D iscov ery alg orith m ........................................................................ .....................9 1

5-4 Selection algorithm ............ .............................................................. ....... ............ 92

5-5. D instance m easurem ent protocol.......................................... ............................ 93

5-6. A average relative error .......................................................................... 101

5-7. A average local relative error ......................................................................... ... ... 102

5-8. A average outliers relative error...................................................................... .. .... 102

5-9. Distribution of average relative error to path latencies ................... ............... 103

6-1. Performance of 2-Opted TSP heuristics across the problem size ..........................15

6-2. Performance of 2-Opted TSP heuristics across the number of TPNP dimensions... 116









6-3. Illustration of M A TA P .................................. ................ ..................................... 127

6-4. Mission communication time across problem size............................135

6-5. Mission communication time across security level category ................................136

6-6. Mission communication time across random selection distribution over security
lev e ls ...................... .. .. ......... .. .. .................................................. 1 3 7

6-7. Effect of transmission rates on mission communication time..............................138

6-8. Heuristic performance with the available SA hosts in the network .......................139

6-9. Heuristic performance with the number of clusters .................................................140















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

A COMPUTATION PARADIGM FOR MULTIPLE MOBILE AGENT SYSTEMS

By

Oguz Kaan Onbilger

December 2004

Chair: Randy Chow
Cochair: Richard Newman
Major Department: Computer and Information Science and Engineering

Mobile agent (MA) systems have been proposed as a potentially useful computing

paradigm for distributed applications. An MA is an autonomous computing entity, which

migrates from one host to another carrying its code/data/state information, to accomplish

a task on behalf of its owner. The concept is attractive since mobility of the agent brings

execution closer to the remote resources resulting in a great reduction of communication

overhead, and the autonomy property of the agent relieves the attention of the initiating

owner, rendering more concurrency for the applications.

The primary hindrance that prevents MA systems from wider acceptance is the

concern of MA security. Protection of agents from malicious hosts is considered a

difficult problem. Our goals are to prove that sufficient degree of agent security can be

achieved to make MA systems a reality, and to propose prototype architecture for secure

multiple MA systems.









Our approach relies on the assumption that security can be enhanced through the

use of multiple collaborating MAs. We conjecture that security can be strengthened

through protection as a whole meaning that attacks to some of the agents cannot corrupt

the entire group of agents performing collaboratively on a common task. One of the

problems tackled in this research is the requirement of the ability to compute / i/h secrets

in public domain. Our research focuses on a special case of this problem, i.e., remote

digital signing with multiple agents. Multiple collaborating MAs are a natural extension

(with mobility) of the research on multi-agent systems in artificial intelligence.

Central to the design of mobile systems is the ability to track the locations of

migrating agents. In our proposed multiple MA system, agents need contextual

information based on location to optimize their traveling itineraries. We propose a

general coordinate-based peer-to-peer network-positioning scheme for the system. The

design of such a location service opens up many new and interesting variations of the

classical traveling salesperson problem. The location service is used in a simulation tool

for analyzing the performance and communication overhead of the MA-based network.














CHAPTER 1
INTRODUCTION

The concept of software agents is a natural extension of the notion of processes in

traditional operating systems. In the context of distributed systems, software agents are

autonomous processes deployed at various sites to perform some specific functions or

tasks. When collaborations among these agents are needed, they form a Multiple Agent

System (MAS) to achieve a common goal. The design issues on MASs generally fall into

two complementary research areas, distributed systems and artificial intelligence. The

distributed systems research community is concerned with the system supports for the

agent technologies such as synchronization and communication of interacting agents,

while in the AI community, the focus is more on the intelligence and decision support of

the cooperating agents. This research adds another dimension, mobility, to the multiple

agent systems we term, Multiple Mobile Agent Systems (MMAS). In such a MMAS,

mobile agents exhibit strong mobility in that they need and are allowed to dynamically

migrate from host to host carrying with them their code/data/state information to

accomplish their missions.

The concept of code migration or mobile code is not new. Most Internet users have

experienced its impacts in both positive and negative ways. On the positive side, we have

enjoyed downloaded programs such as Java applets in web browsers for all kinds of

operations ranging from banking transactions to animating cartoon characters. This

aspect of mobile code technology helps to realize the important goals of transparency and

efficiency in distributed systems. On the negative side, we have seen numerous malicious









uses of the technology in the forms of viruses and worms that disrupt our daily computer

operations. Similarly, Java servlets, which are the server counterpart of applets, have

become commonplace for many Internet applications. Like applets, their code migration

is static, meaning that codes are uploaded to servers, run there and cease their existence.

The emerging mobile agent technology takes the applet and servlet concepts one step

further to allow dynamic and continuous migration of the agent processes autonomously.

Mobile agents have been proposed and used in some limited application domains

such as e-commerce, information retrieval, network management, software distribution,

distance education, and even as a security mechanism for intrusion detection. It has been

argued that using mobile agents as a programming paradigm is a perfect fit for distributed

systems since the autonomous characteristics and mobility of agents facilitate naturally

the implementation of asynchronous and dynamic interaction of concurrent execution in

distributed applications. More precisely, the mobility of agents brings execution closer to

the remote resources resulting in great reduction of communication overhead, and the

autonomy property of agents relieves the attention of the initiating agent owners

rendering more concurrency for the applications. However, the concept has received

much skepticism until the current millennium, out of concern that interoperability and

security might not be justified if agents are to roam freely in an open and large-scale

network. This research addresses the security issue of mobile agents. In particular, it

claims that utilizing multiple collaborating mobile agents can actually enhance the

security of the applications.

There are two separate categories of threats in mobile agent security, malicious

agents and malicious hosts. Protection of hosts against malicious agents is well









understood and has been implemented at least in some degree in most systems. Common

solution approaches to the problem are host hardening and agent containment such as the

built-in security mechanisms for byte-code execution in Java language and virtual

machine. The protection of mobile agents against malicious hosts, however, is less

intuitive. First, the assumption that a user would send its agent processes to untrustworthy

hosts is less conventional. Second, the secrecy and integrity of the agents and the need to

execute the code in public might conflict with each other at times. Total agent protection

is considered unsolvable without special hardware by some researchers. The main

difficulty comes not only from agent mobility but also autonomy. Especially, their ability

to migrate from one host to another poses vulnerabilities, which could easily be exploited

by the very host platforms they execute on. This dissertation focuses on the problem of

protecting mobile agents against malicious hosts.

There are threats to mobile agents which lead to very simple attacks that could be

devised: denial-of-service and replay attacks. A host platform which receives an agent

may simply not execute the agent at its own discretion, which leads to denial of service.

Similarly, a host platform can reuse the agent by using the credentials delegated to it by

its owner (i.e., user) to masquerade the original host and user, which leads to replay

attacks. These two types of attacks are not properly addressed by the known or proposed

mechanisms. A complete description of attacks possible against mobile agents and a

background information about proposed solutions and their classification are given in

Chapter 2.

We have identified several requirements for a solution for the malicious hosts

problem. These are summarized as follows:









1. A solution proposed to protect hosts from possibly malicious hosts should not
jeopardize the protection of hosts from agents,

2. The second important requirement is that solutions should not limit the potential
benefits of mobile agents,

3. It is vital to address easier attacks against mobile agents, which are denial-of-
service and replay,

4. The concept of the network trusted computing base needs to be extended to be
applications and case specific.

Details of these requirements are provided in Chapter 3.

The theme of this dissertation is to address the protection of mobile agents from

possibly malicious behavior of host platforms by keeping in mind the requirements

pointed out above. The proposed technique is based on an autonomous group of multiple

agents designed to accomplish a single well-defined task, which in turn relies on the

concept of information dispersal for security. Information dispersal is not a new concept.

Both cryptographic and non-cryptographic means of protection via the technique have

been proposed and implemented. Cryptographic mechanisms are mostly related with key

sharing and threshold cryptography. Non-cryptographic means are directly applied on

data to be protected. For example, sensitive information is split up and distributed to

several hosts connected with a computer network. Penetration to one or some of the hosts

would not reveal the information, and intrusion to several hosts is considered more

difficult than intrusion into a single host. Similarly, sensitive information carried by

mobile agents (this may also include the code) can be split up and given to multiple

agents. Therefore a successful attack against the group of agents is more difficult than

attacking a single agent. Agents in the group should be located on different hosts, and

furthermore on different administrative domains. Agents in the group should









communicate and cooperate to accomplish the task given. Therefore, tampering with one

of the agents could be detected by the others in the group.

The feasibility of the described approach however does not only depend on

information dispersal. To apply the concept into dynamic mobile agents, we first need to

figure out how to position multiple mobile agents, specifically how to find the hosts to

locate the agents in a feasible manner. This opens up very interesting research issues

including making mobile agent systems aware of the underlying network topology. While

we are focusing on one specific application of information dispersal in Chapter 3, our

focus in Chapter 4 is on the network positioning models to be able to apply information

dispersal into multiple mobile agents in an open internetwork environment.

This dissertation is organized as follows.

In Chapter 2, we provide a brief description about software agents and multi-agent

systems, mobile code concept and its applications, mobile agents, their benefits and

drawbacks. Then we provide background information about mobile agent security from

both perspectives described above and proposed solutions and their categories in more

detail.

In Chapter 3, we explain the concept of group of multiple cooperating agents for

security. We provide models applicable to this concept and our proposed model. We

define the mission concept and model and distinguish this concept from the multi-agent

systems. The proposed multiple mobile agent system architecture is also introduced.

Chapter 3 is the foundation for the rest of this dissertation.

In Chapter 4, we address the remote digital signing problem of mobile agents. For

the mobile agent paradigm to be widely accepted and used, one must demonstrate that









mobile agents are capable of performing computations that are possible with the

client/server model. Digitally signing a contract is one such computation in e-commerce

applications that needs to be performed by mobile agents. We demonstrate that it is

feasible to perform this computation with multiple cooperating agents using the

information dispersal for security concept, as presented in Chapter 3.

In Chapter 5, we examine the network distance measurement approaches and

propose a general, highly scalable coordinate-based peer-to-peer network-positioning

scheme, one that fits better to the requirements of the mobile agent systems. By using a

simulation tool, we analyze and demonstrate the achieved accuracy of the approach.

In Chapter 6, we apply the network positioning system proposed in Chapter 5

together with traveling salesperson problem heuristics to traditional mobile agent

computing and multiple mobile agent systems. We are looking for the answers to the

questions about whether we can alleviate the performance problem of multiple mobile

agent systems and if we can do it efficiently without canceling out the performance

benefit achieved. This chapter also deals with network- and context-awareness in mobile

agent systems.

Finally, Chapter 7 summarizes our work and provides future research directions.














CHAPTER 2
BACKGROUND

Mobile agent paradigm has two descendants: software agents and mobile code.

Mobile agents are software agents with the added feature of mobility. On the other hand

what makes them mobile is the general concept of mobile code. So, mobile agents

combine these two unrelated concepts, and become a unique technology in distributed

systems. In this chapter we provide a brief outline of software agents in general and then

have a look at the mobile code concept and its applications. The rest of the chapter is

dedicated to mobile agents, their applications, systems, standards, pros and cons. A

detailed survey of the security problem of this technology and the proposed solutions

ends the chapter.

2.1 Software Agents and Multi-Agent Systems

Software agents are an active research area in Artificial Intelligence (AI) and

distributed computing systems. In this section we use the term "software agent" to refer

to software entities that are subject to research in these two fields, in general. So,

autonomous agents, intelligent agents, interface agents, virtual agents, information

agents, and mobile agents are all software agents.

The difficulty with the definition of an agent in the AI community is to distinguish

a software agent from a software program (Franklin & Gaesser, 1997). Bradshaw (1997,

pp. 7) cites the definition given by Shoham (1997), with the hope that it might be

acceptable to most researchers: "A software entity which functions continuously and

autonomously in a particular environment, often inhabited by other agents and









processes." Murch and Johnson (1998, pp. 16) provide a survey of definitions and as a

result they conclude that "agents are, by consensus, autonomous, goal seeking, persistent,

reasoning, productive, and communicative." So, it seems like characterization of agents

makes more sense than giving an exact definition. Bradshaw (1997, pp. 8) shares the

same point and as the result of his own survey concludes that "consistent with the

requirements of a particular problem, each agent might possess to a greater or lesser

degree attributes like the ones: reactivity, autonomy, collaborative behavior,

communication ability, inferential capability, temporal continuity, personality, adaptivity,

and mobility."

From the distributed computing systems perspective, however, our focus is on

mobile agents, which is a specialization of generic software agents with the added ability

of mobility. The details on mobile agents are given in Section 2.3.

A precise description of multi-agent systems is given by d'Invemo and Luck (2001,

pp. 6):

Multi-agent systems are typically distributed systems in which several distinct
components, each of which is an independent problem-solving agent come together
to form some coherent whole. There is generally no pre-established architecture or
configuration incorporating the agents, and the interactions between them are not
pre-defined, as is usually the case with traditional processes in concurrent
programs. More importantly, there is no global system goal, the agents being
heterogeneous with their own goals and capabilities. In consequence, agents in a
multi-agent system need to coordinate their activities and cooperate with each
other, in order to avoid duplication of effort, to avoid unwittingly hindering other
agents in achieving goals, and to exploit other agents' capabilities.

What is not clearly specified in the above description is that owner or users of the

agents participating in a multi-agent system may be different parties.









It is necessary to distinguish the multi-agent systems and the multiple-agent model

we use in our research for better understanding. This distinction is made clear in Chapter

3 where we define multiple cooperating agents concept.

2.2 The Mobile Code Concept

The mobile code concept may be best understood by examining the applications. In

the following we provide brief descriptions of mobile code applications.

In traditional distributed computing systems, applications are built on the

client/server paradigm. Usually, the client process sends a request to the server process

over the network. The server processes the request and returns the result to the client. The

communication between the clients and servers are handled through message passing or

Remote Procedure Calls (RPC). This is a synchronous process in the sense that clients

usually block after sending the request until the reply arrives or a certain timeout is

observed. Although asynchronous RPC changes the classical synchronous

communication nature of the client/server model, the request/reply scheme remains the

same. The mobile code concept however makes a paradigm shift in distributed

computing.

In contrast to the request/reply scheme, in mobile code systems, not only the data

but also the code to be executed is exchanged between the applications. Remote

evaluation has been first proposed by Stamos and Gifford (1990). In this scheme, code to

be executed is sent to the remote machine. The result of execution is sent back as data

only.

As is true for other resources, processor cycles can also be shared in distributed

systems. The mechanism necessary for sharing such a static component requires code

migration in the form of processes, which is known as process migration. The first









objective of process migration in distributed systems is to redistribute load and improving

performance by migrating processes from node to node. The secondary objective is to

achieve location and performance transparencies by distributed process scheduling

(Chow & Johnson, 1997).

Perhaps the most well-known mobile code mechanism that is widely used today is

Java applets. An applet is a Java object that is associated with a web page. When the page

is requested by a client browser, applet is downloaded into the client machine along with

the web page and executed in the Java Virtual Machine installed on the same machine.

Applets are static in the sense that they cannot move anywhere other than the client

machine, Moreover, their communication to the outside world is restricted to the

originating server machine due to security concerns.

The server counterpart of applets is an object known as a servlet in Java. So,

servlets are uploaded from the client to the server to make the server functionality

customized according to the specific requirements of the client. Code migration,

therefore, follows the opposite path of an applet. Servlets are widely used today by the

web servers, which are implemented in Java. However, servlets in use today are created

and used by the server host, mostly due to the security concerns. Therefore, the capability

of code migration, which was explained above, is not used. Java applets and servlets are

said to be examples of code-on-demand paradigm (Lange & Oshima, 1998).

Active networks are an active research area employing the mobile code concept

(Hartman et al., 1996; Tennenhouse et al., 1997; Tennenhouse & Wetherall, 1996). The

area has its roots in the SOFTNET project, which is a multihop packet radio network

developed in the 1980s (Zander & Forchheimer, 1988). In active networks, specialized









packets, which are called capsules (Tennenhouse & Wetherall, 1996), carry not only data

but also code. The code is injected into the nodes along the route of the capsule.

Subsequent packets which are related to the original capsule trigger the execution of the

code previously stored in the nodes. The result is that the routers of the network and

therefore the network itself are programmed by its users. Immediate advantages of the

described scheme are that customized computation for individual applications can be

carried out inside the network and new network protocols can be installed on the routers

easily, on-the-fly.

2.3 The Mobile Agent Paradigm

Mobile agents (MAs) are an approach to distributed computing employing the

mobile code concept. MAs are autonomous entities, which are composed of code, data

and state information. They visit hosts (e.g., servers) possibly using an itinerary, perform

some execution on those hosts using their codes and migrate with their state information

from host to host. As in the case with stationary agents, they act on behalf of their owners

(e.g., senders). They are autonomous in the sense that they have all the knowledge needed

to perform the assigned task on behalf of their owners. The traditional mobile agent

execution model is illustrated in Figure 2-1. The mobile agent is launched from the

originating platform by the owner. It visits the hosts to accomplish its task and return to

the owner.

The most important difference between the MA paradigm and the other mobile

code systems is the strong mobility of MAs. None of the mobile code systems and

mechanisms except the process migration mentioned in the previous section has the

strong mobility feature. This means that the execution state of the transmitted mobile

code is not carried. Therefore, the code (e.g., program, procedure or method) starts










execution from the beginning and terminates at a certain point. In the case of mobile

agents, execution stops but not terminates and resumes at the next platform, where the

mobile agent migrates.



Host I Agent Agent Host






Host Agent \ I Agent Host





Agent Owner's Host
Figure 2-1. Mobile agent execution model

Migrating processes are not allowed to choose where and when to migrate in

contrast to mobile agents. While processes are migrated to balance the load transparently,

mobile agents autonomously migrate to hosts where the information or services are of

interest. Another difference between the two is that processes in general can migrate

among homogeneous environments whereas mobile agents are designed to run on the

middleware, which makes them platform (machine and operating system) independent.

Active network architecture is mainly proposed for network level tasks, although

application level customization is also possible. Mobile agents, in contrast, are mostly to

be used at the application level. While the target hosts are the network routers in the

former, target of mobile agents can be any host. One last distinguishing feature is that

mobile agents have execution state, whereas an active capsule has no such state.

However, active networks and mobile agent systems are not mutually exclusive. Active









network architectures and models, which employ mobile agents, have been proposed

(Breugst & Magedanz, 1998; Busse et al., 1999).

2.3.1 Applications of Mobile Agents

Mobile agents have been proposed to be useful in a wide range of applications. We

classify these applications in the following and give a brief insight about the application

areas.

E-commerce, m-commerce. Among many application areas of MAs, e-commerce

draws the most attention from both academic and industrial researchers (Busch et al.,

1998; Marques et al., 1999; Klusch, 1999; Roth, 2000; Sandholm, 2000). This is mostly

due to the fact that, MAs and in general agent systems have the capability of representing

users (i.e., customers) in the electronic marketplaces. Agents can effectively profile user

preferences, act on behalf their owners, participate in e-auctions, watch stock prices,

search for commodities and find the best offer from competing vendors, purchase goods

by paying and committing to transactions, communicate and cooperate with other agents

of relevant goals.

Network management. Code mobility in the form of mobile agents has been

proposed by many researchers as a promising technology in network management. Some

examples are Baldi, & Picco, 1998, Papavassiliou et al. 2002, and Meer et al., 2000.

Baldi and Picco (1998) model network management activities using client/server model,

remote evaluation and mobile agents and summarize advantages of using mobile code in

network applications as semantic compression of information, a higher abstraction level

to the network manager and autonomy of management agents.

Information retrieval. The information retrieval problem is getting more difficult

everyday on the Internet due to the amount of information available to the users. Mobile









agents can search, filter and retrieve vast amount of information locally. Therefore

information retrieval has become one of the most important and popular application areas

of the mobile agent paradigm. Brewington et al. (1999) provides a qualitative and

quantitative analysis of the use of mobile agents in information retrieval applications.

Johansen (1998) discusses pros and cons of mobile agents in different application areas

and provides quantitative analysis of real applications. One of these applications is

StormCast where several servers receive weather data from meteorological censors.

Users in turn, by sending their mobile agents can learn about the weather conditions in

their area, and even set alarm conditions which are watched by their agents. Agents react

by notifying the their users when the condition is occurred.

Software distribution. Mobile agents are capable of customizing server side

functionality by moving the client specific code to the server and this capability is one of

most important benefits of the mobile agent paradigm. This concept therefore can even be

used to deliver software for permanent use of server and client computers. Using this

push model, subscribed code consumers may enjoy immediate software installation and

updates. In fact, active networks are a good example of using mobile code in the form of

specialized packets to install new protocols to the network routers, on-the-fly. An

example of software update application using mobile agents is given by Bettini et al.

(2002).

Other application areas. Other example specific application areas are

distant/remote education (Jamwal & Iyer, 2003), and vehicular traffic management

(Schill et al., 1998). Mobile agents have also been proposed as alternatives to provide









security in distributed systems. An example is intrusion detection systems, which utilize

mobile agents (Jansen et al., 2000).

2.3.2 Mobile Agent Systems

Informally a mobile agent system is a middleware where mobile agents live. This

middleware typically sits on top of a runtime environment. The runtime environment is

responsible for running the mobile agents and in some cases also for the execution of the

mobile agent system itself as in the case of Java systems. The instances of these

middleware systems, which run on hosts are known as places (Lange & Oshima, 1998) or

platforms. We prefer the term "platform". So, the mobile agents are created, executed and

terminated in these platforms. When we say that mobile agents migrate between hosts,

what we actually mean is that they migrate between the platforms, running on different

hosts connected through a network. The mobile agent systems are responsible for all the

operations of mobile agents. Creation, migration, communication with other systems and

agents, cloning, security and termination are all handled by the underlying platform.

Figure 2-2 illustrates the mobile agent system concept and relationships with the

other components of a host, which employs a mobile agent platform. The runtime

environment is typically a high-level language interpreter or Java virtual machine, since

vast majority of mobile agent systems today are built using the Java programming

language. Java has been the common ground for mobile agent systems, mostly due its

standard, object-orientedness, support of mechanisms such as serialization and reflection,

support of distributed objects as in RMI, and inherent security features. However,

because different mobile agent systems themselves and mobile agents are implemented in

the same programming language and executed by the same standard Java virtual machine






16


does not mean that these systems would be interoperable. More details on interoperability

problem are given in Section 2.3.4.

HOST

Mobile Agent Platform

Agents
migration


___ +communication
T JVM T


OS


Figure 2-2. Mobile agent execution platform

Today, there are more than fifty mobile agent systems. It is difficult to keep track

of all the mobile agent systems exist today around the world. Some of the earlier ones

ceased to exist as they become unsuccessful in the market or some of them have been

experimental research systems. However, many new projects have been started to

develop new systems which usually to overcome the deficiencies of the existing or

previous systems.

Kiniry and Zimmerman (1997) provide a survey of both commercial and research

based Java mobile agent systems. Brewington et al. (1999) classify the systems as

multiple language, Java based or others which are written mostly in script languages, and

compare the systems. Lange and Oshima (1998) give a brief description of popular

mobile agent systems. Karnik (1998) classify mobile agent system according to several









criteria including the security features provided by these systems. We classify the mobile

agent systems as in the following.

Programming language used. Most of the latest mobile agent systems are

developed in Java. Hence, mobile agents themselves are implemented in the same

language. Earliest systems however have been written in scripting languages or

interpreted bytecodes in other high level languages.

Migration state carried by the agents. There are two different approaches for

mobile agent migration. Within the first one control state of the mobile agent is captured

and send to the target machine. The execution resumes in the target where it left off in the

source machine. Within the second approach, the execution state of the mobile agent is

not sent to the target machine. The programmer is responsible for the agent state and the

execution state resume in the target host by referring to an entry point. The second

approach makes it simpler to develop the underlying system but it may be a burden to the

application programmer to capture the current state of the agents. But this is not really a

problem because migration decision is made solely by the mobile agent itself by

executing an instruction such as go. Since, migration is not forced by the underlying

system, entry points can be easily specified using the data portion of the agent rather than

the control state which includes the execution stack. This approach is taken by many of

the Java based systems for interoperability since Java does not support inspection of the

execution state of the objects due to security concerns. The former approach requires

modifications to the JVM to capture the state and hence mobile agent systems and mobile

agents developed using these systems can not run on standard JVMs.









Multi-threading of mobile agent systems and mobile agents. Many Java mobile

agent systems run the agents as a separate thread of the main process of the mobile agent

platform. Others run agents in isolated processes and some of the systems use a

combination of the two approaches. Ara is an example of the former approach whereas

D'Agents is for the latter.

Communication primitives. Different mobile agent systems use different

communication primitives among mobile agents. Some uses message passing, or RMI.

Some systems require the agents to be present at the same platform, some other provide

remote communications between sites. As examples, Aglets support sending and

receiving messages in the form of objects, Ajanta supports RMI using proxies and

D'Agents use message passing.

Security provided. This is perhaps the most important classification from our

point of view. Unfortunately, vast majority of the mobile agent system have been

developed without any security consideration at all. This is perhaps due to the fact that

these systems are not intended for large scale, open systems or networks such as the

Internet. In a company network or intranet, security may not be that important for mobile

agent systems. Kamik (1998) makes the distinction among mobile agent systems in three

categories: secure communication, server resource protection and agent protection.

Secure communication is about whether the agent migration is protected using encryption

and authentication. Server resource protection is usually associated with authorization of

agents and access control mechanisms such as ACLs. Agent protection is related with the

malicious hosts problem. Agents must be protected against any possible hostile behavior

of hosts where they are executed. This is an open research area, which is the subject of









this dissertation and only a limited number of agent systems support mechanisms within

limited contexts.

2.3.3 What Mobile Agents Offer

Lange and Oshima (1998) point out that mobile agents: 1. reduce the network load,

2. overcome network latency, 3. encapsulate protocols, 4. execute asynchronously and

autonomously, 5. adapt dynamically, 6. are naturally heterogeneous, and 7. are robust and

fault-tolerant. Gray et al. (1996) examines the benefits of mobile agents from the mobile

computing perspective. They point out the capability of mobile agents which provides a

powerful alternative for partially connected computing through mobile computers (i.e.,

laptops, personal digital assistants, etc.) and home computers, which have intermittent

connections to the fixed networks. They also highlight how mobile agents simplifies the

development, testing and deployment of distributed applications, and how it is possible to

employ a scalable, peer-to-peer architecture for distributed applications instead of the

rigid client/server model.

Chess et al. (1995b) in their classical paper in the area collect fourteen claims,

which have been given as the advantages of mobile agents over existing client/server

paradigm (i.e., message passing, RPC, etc.) and they examine each claim in detail. They

conclude that none of the claimed application areas could be uniquely addressed by the

mobile agent paradigm (one exception might be the real-time applications which could be

impaired with the network latencies between hosts that run client and server components

of such a distributed application, especially in wide-area networks). For every application

area, they could find an alternative that may well be addresses by the existing

technologies. However, as the final conclusion they point out that mobile agent

technology is unique in the sense that there is no alternative technology that could









address all of the application areas and benefits together that can be offered easily by the

mobile agents.

Johansen (1998) shares their experiences of implementing and using mobile agents

in real world applications using the Tacoma mobile agent system and also provides

quantitative analysis of the performance aspects of mobile agents. He concludes that 1.

agents are a convenient way to install client software at remote hosts, 2. their most

successful application would be to build extensible servers, 3. the asynchronous nature of

agents is important, 4. agents are shown to be a very convenient structuring technique for

the distributed applications.

We briefly summarize the benefits, which are offered by the mobile agent paradigm

as follows.

Mobile computing point of view. Mobile devices have limited battery life, and

their intermittent connection to the wireline networks have low bandwidth, and high

latency. Mobile agents overcome all these problems. They can be launched from mobile

devices in a brief connection to the fixed network. Returning results to the users requires

only another brief connection. During the computation the device can be disconnected

from the network, and can even be turned off.

Networking point of view. Mobile agents are capable of searching, analyzing and

filtering huge amounts of information available on the servers across the Internet. As a

result they can only return the most relevant information to their interested users. This

saves network bandwidth when compared to the existing client/server model of

computing where all the analysis and filtering are performed in the client side which

requires transferring all irrelevant information along with the most relevant parts.









Service point of view. Services offered by servers can be customized according to

the user requirements, on-the-fly. Servers can offer basic primitives to use their services.

Using these simple primitives, mobile agents can be programmed to reach the services

and information offered by the servers in a customized way. The alternative used today is

to provide service packages, which are offered to clients. Offering a new service requires

a long implementation and deployment process. Therefore, users have to choose from

these offered service packages. Mobile agents make the deployment process immediate.

Application development point of view. Even it is not a real problem

theoretically, client/server based application development poses the problem of a design

issue of at which component the client or server, the services should be implemented.

Mobile agents overcome this problem easily. Client side functionally can easily be

moved to the server. Mobile agents, in general, simplifies the implementation, testing and

deployment of distributed applications (Brewington et al., 1999; Johansen, 1998).

Interestingly enough, they can even be used to develop and deploy prototype distributed

applications (Chess et al., 1995a).

Application user point of view. Not only mobile agents, but in general software

agents have the capability of representing their users and user preferences, which is an

important benefit especially in electronic commerce and mobile commerce applications.

Distributed system point of view. Most distributed applications fit naturally to the

mobile agent model (Brewington et al., 1999), mostly because of the mobility of the

agents. This is the aggregate advantage and hence becomes the unique property of mobile

agents.









As a conclusion we believe that mobile agents possess an enormous potential in

building feature distributed systems, once their drawbacks are addressed convincingly, as

explained in the following sections.

2.3.4 Drawbacks of the Mobile Agent Paradigm

Two major open problems, which prevent mobile agent paradigm from being a

widespread, actively used technology today, are security and interoperability. The

security problem of mobile agents is addressed in the next section. Here, we provide brief

information about the interoperability problem.

As mentioned in Section 2.3.2 mobile agents require their own mobile agent

platforms to be executed. For example, an Aglet cannot be executed in an Ajanta

platform even though these two mobile agent platforms and agents themselves were

implemented in Java and all they need is a standard Java virtual machine. Interoperability

has several aspects such as capability of communication between the different systems

via message passing or RPC, capability of running mobile agents from different systems,

or communication between agents from different systems.

Recently, Brazier et al. (2002) proposed generative migration of mobile agents

among heterogeneous platforms. This approach is based on agent factories and blueprints

of agents. Blueprints, which could be describe with a high-level specification language,

describe the agent functionality. Agents' state is described by a language such as XML.

Agents' blueprints along with their state are migrated between host platforms where

agent factories exist. The job of the agent factory is to transform the blueprint and the

state into an executable form using libraries designed for this purpose and for the target

environment, which exists on the same host. Although the approach seems to be

promising, it raises several questions. First one is the security issue. While it is already









difficult to protect agents from malicious hosts, this approach makes it worse. For

example, the approach renders the agent protection schemes completely useless which are

based on obfuscation methods. The other concern is performance overhead introduced

with the approach to transform agents back and forth.

Another approach is to let agents migrate only between their own platforms. If and

when they need information available on some host, which does not employ the same

platform that the agent needs, the agent migrates to the nearest host to the target one, with

a platform needed for the agent. Then, assuming standard client/server interfaces are

employed between the hosts, agent becomes a client and communicate with the target

host using a request/reply scheme. This scenario is equivalent to the one with a target

host, which does not support any mobile agent platform as in (Theilmann & Rothermel,

2000). The major problem with this approach is related with performance, which is to

find the nearest available hosts to the target host. This issue is a subject of this

dissertation. Moreover, making mobile agents dependant on the client/server model limits

their capability to customize server functionality.

2.4 Security Problem of Mobile Agents

In contrast to many other technologies in distributed systems, mobile agent

technology will not be accepted and widely deployed before the security problem is

solved. Other technologies have been widely deployed before their security requirements

have been understood and mechanisms have been implemented and used.

There are two types of security threats introduced by mobile code systems. One

comes from potential malicious agents and the other from malicious hosts. The malicious

agents problem is rather old and many protection mechanisms have already been

proposed and implemented because of the fact that some kind of protection mechanisms









are common in mobile agent systems and other mobile code systems. On the other hand,

the malicious hosts problem is more difficult and considered unsolvable without

dedicated hardware. The problem is relatively new since the computation in the form of

mobile agents has never been defined to take place in a remote environment that could

possibly be malicious. We are concerned with the latter problem in this dissertation:

protecting the MAs from malicious hosts.

Chess (1998) identifies the assumptions made on the security of computing systems

in four categories: identity assumption, origin of programs, origin of attacks, immobility

of programs. These assumptions state that programs and their users can be easily

identified; programs are obtained from easily identifiable and trusted sources. Significant

security threats come from attackers running programs with a clear intent in a restricted

environment. Programs rarely cross administrative boundaries and only in controlled

ways, programs run entirely on one machine on a specific operating system and operating

system is responsible for the security. Unfortunately, these assumptions do not hold for

mobile agents and in general, mobile code systems. Therefore new security mechanisms

are necessary especially in the mobile agents case.

The protection of hosts from potential malicious agents and the protection of agents

against potentially malicious hosts are not mutually exclusive. There are two reasons for

this. First one is that, in general, solutions proposed for the former problem implies also

the protection of hosts. This is due to the fact that, a successful attack against a mobile

agent in a given platform may threaten the subsequent platforms, which the MA visits.

For example a brainwashed shopping agent may request for hundred airline tickets

instead of the correct value of two. Similarly, an agent responsible for software updates









may introduce Trojan horses to the subsequent hosts it visits, if a former platform could

fabricate this code inside the software patches carried by the agent. The second reason is

that some protection mechanisms, namely obfuscation techniques may render host

security useless, since the intent of the agent might not be easily checked or verified by

the platforms, which are to execute the agents.

2.4.1 Malicious Agents Problem

Hosts, which are to accept and execute MAs must be protected against possibly

malicious MAs. A malicious agent may access sensitive information on the host, which is

not authorized to do. Moreover, MAs may alter, fabricate or delete data or files, and may

inject malicious behavior in the form of Trojan horses.

We have a brief look at mechanisms to protect hosts from two perspectives. The

first one is the general mechanisms, which apply to almost all mobile code systems hence

to MAs. The second category is specific to MA security, which necessary due to strong

mobility and multiple execution platforms that a given MA may need to migrate and run.

2.4.1.1 General protection mechanisms against possibly malicious mobile code

Sandboxes and playgrounds. Sandbox is a restricted execution environment

where all the foreign code (i.e., downloaded from another machine) is to be executed. In

Java, the Java Virtual Machine executes foreign code in a sandbox, which is

complemented by a security manager, which checks the instructions of the code to verify

if they adheres to the security policies (Oaks, 1999). For example, foreign code has

restricted access to the file system, main memory and other assets of the computer

system. Moreover, in the case of Java applets for example, their communication to the

outside world is also restricted to the host from where they are downloaded. Since the

code inside the sandbox needs to be interpreted in order to be checked, code









interpretation is regarded as a part of the sandbox (Tanenbaum & Van Steen, 2002).

However, in general, there exist code interpreter systems that do not employ the sandbox

concept. Therefore, we consider this mechanism as a separate one in the following.

Malkhi and Reiter (2000) extended the sandbox mechanism into playgrounds.

Basically, the functionality is the same, however, playgrounds are to be placed in

physically isolated machines. Foreign code is downloaded and executed only in these

machines. The local programs can access the migrated code and data through traditional

mechanisms. However, foreign code cannot access to the other computers and local

assets in them.

Interpreting code. Code interpretation is an important concept in mobile code

systems for interoperability of heterogeneous systems. The code, which is not compiled

directly into the machine instructions but instead compiled into some intermediate code

(i.e., bytecodes in Java) can be run by standard middleware systems on top of the

underlying specific operating systems. The best known example is the standard Java

Virtual Machine, which can run almost on any operating system exist today.

A nice side effect of code interpretation is the ability to easily check the code

before execution during runtime. Therefore, each instruction can be inspected to figure

out whether there is any access violation or any behavior, which does not conform to the

security policies defined.

Code signing. It is important in mobile code systems to authenticate the source of

the code, which is migrated or downloaded. Digital signatures (through public key

cryptography) can effectively be used for this purpose. The code is signed by the

manufacturer (i.e., programmer) and/or the owner (i.e., user of a MA) by using their









private keys. The receiver uses the corresponding public key to authenticate the source of

the code. If the source is considered to be trusted then the foreign code can be assumed

safe and executed. Even in theory this works well, in practice it is difficult to assess the

trustedness of the source and the level of trust that could be associated with the source.

2.4.1.2 Specific protection mechanisms against possibly malicious agents

Here, we provide an overview of the mechanisms proposed for the host protection

against malicious agents. These mechanisms, mostly try to circumvent the issues arise

from the nature of strong mobility of MAs which is a direct result and necessity of

visiting multiple host platforms to accomplish a task.

Path histories. The idea of path histories (Chess et al., 1995a; Ordille, 1996) is to

record and carry authentication information of previously visited hosts, with an MA.

Each host platform digitally signs and inserts its own identity and the next platform to the

history using digital signatures. Meanwhile, every host, which receives an agent checks

the validity of the signatures and decides by looking at the previous hosts, whether it

would be safe to accept and execute the MA. If, for example, any of the identities of the

previous hosts is considered to be untrusted, the MA is discarded. The drawback of the

approach is that the payload of the MA increases at the every platform visited, and it is

required to check the whole path of digital signatures carried by the agent.

State appraisal. The state appraisal mechanism is to detect, to a certain extent,

whether the current state of a MA, when arrived to a new site, is not harmfully altered.

The agent code producer and the user of the agent provide appraisal functions for the

state of the agent. This function is carried by the agent along with its code and state.

When an agent arrives a new host, it must decide what specific privileges it will need at

the host. The state appraisal function is used to compute a set of privileges to request as a









function of the current agent state. In turn, the authorization mechanism employed by the

agent platform determines which privileges requested by the agent it is willing to grant

and whether the agent is in a safe state (e.g., no harmful modifications have been made)

(Farmer et al., 1996). The authors indicate however that, it may not always be possible to

detect a deceptive state from a correct one.

Proof carrying code. This is a technique, which is used by the hosts to verify that

foreign code provided by an untrusted party adheres to a predefined set of rules, which is

known as safety policy. This policy is formed by the hosts to guarantee that the

downloaded or migrated foreign code, if complies with the policy, will be safe to execute.

Two components are used with the technique: a formal proof and a proof validator. The

code producer creates a formal safety proof, which expresses the fact that the code will

behave according to the safety policy. The code consumer host uses the proof validator,

to check whether the proof is valid and therefore the code is safe to execute (Lee &

Necula, 1997). The authors indicate that there are four necessary components for the

technique: 1. a formal specification language used to express the safety policy, 2. a

formal semantics of the language used by the untrusted code, 3. a language used to

express the proofs, and 4. an algorithm to validate the proofs. Although the approach is

theoretically sound, there might be practical difficulties in implementing and using the

approach including a standard formalism for establishing the safety policy, automated

assistance for generation of proofs, and techniques to limit the potentially large size of

proofs (Jansen, 2001). In addition, the technique is tied to the hardware and operating

environment, which is in conflict with the interoperability requirements of MA systems.









2.4.2 Malicious Hosts Problem

As we have pointed out above, protecting mobile agents from possibly malicious

hosts in open environments is one of the most difficult security problems in distributed

systems. This problem has even considered unsolvable without dedicated hardware. The

obvious reason for this is that an agent in under complete control of the host it is to run

on. Hohl (1998a) identified the specific threats to mobile agents:

* Spying out and/or manipulating code,
* Spying out and/or manipulating data,
* Spying out and/or manipulating control flow,
* Incorrect execution of code,
* Masquerading as a host,
* Denial of execution,
* Spying out and manipulation of interaction with other agents,
* Returning wrong results to system calls issued by an agent.


Hohl (1998b) also provided a set of requirements for an attack model against

mobile agents. He uses the Random Access Stored Program (RASP) machines to show

that the components of the execution process of an agent program can be accessed by an

attack program and this program can be executed by another machine (in the abstract

sense) to control the execution of the agent program.

There are several approaches proposed in the literature. Different classifications of

these approaches can be given. For example, some approaches are aimed only to detect

certain attacks whereas others try to prevent them. While some of the approaches are

more general, majority of the proposed solutions target specific threats. Although we do

not give a precise taxonomy, a classification and a brief description of the proposed

solutions are presented below.









Organizational or social trust. Most of the MA systems ignore security by the

assumption of organizational or social trust. For example, an individual user may have

trust to a reputable well-known company. Therefore he/she may not expect any hostile

behavior from the company that operates the MA system, against his/her agent. But this

cannot be applied to a virtually unknown company, and such an e-commerce MA system

may not be fair to businesses that have not yet established a public trust. On the other

hand, social trust does not apply to a business-to-business e-commerce system based on

MAs. For example two competing companies could not assume the same trust to one

another as in the individual user case, even if these were reputable companies. This

potential aspect of lack of trust could severely limit the use of MAs in an open e-

commerce environment. However, we believe that together with other technical security

mechanisms, this aspect will be helpful in providing better security for MAs.

Solutions based on obfuscation. Blackbox security is an obfuscation scheme,

which does not rely on cryptography. It defines the problem as to make an agent's code

and data be messed up so that cannot be read or modified at any time (Hohl, 1998a).

Because there is no known solution to the problem, the "at any time" requirement is

relaxed to "for some known time interval." The idea is to scramble code and data of an

agent so that they do not reveal the function of the code. The interesting aspect of this

proposal is that it does not rely on cryptography. There are some issues to be solved by

the approach such as necessity of synchronized clocks to be able to realize time

limitation. Code obfuscation is a well-known method and there are many examples

especially for Java. However, there are also tools to defeat known obfuscation methods

and this is an arms race as indicated in (Dyer, 1997).









Another approach for mobile agent protection relies on cipherprogram concept

(Sander & Tschudin, 1998). It is claimed that mobile agents do not have to rely on

cleartext data, program or messages. This, in turn, relies on computing with encrypted

functions and computing with encrypted data. Encrypted functions work as follows.

Suppose Alice has an algorithm to compute a functionfon data item x. Bob has the

computation power and would like to computeffor Alice. However Alice does not want

Bob to know anything about Iffcan be encrypted in a way that another function E(f)

can be computed by a program namely P(E()), then Alice sends this program to Bob,

after execution Bob sends the result back to Alice. Alice, in turn decrypt the result to

obtain f(x).

Although it is not claimed to be a general solution to agent protection and the

computation is limited to certain functions (e.g., polynomials), this approach is a good

example for a software-based solution based on cryptography. However, recently Barak

et al. (2001) have shown that this approach is not likely to succeed.

Tracing data state and execution. Partial Result Authentication Code (PRAC) has

been proposed by Yee (1999). The goal is the technique is to ensure forward integrity

using cryptographic checksums formed using symmetric cryptography similar to

Message Authentication Codes (MAC). Forward integrity means that results of the

previously visited hosts should not be able to be forged by a malicious host subsequently

visited. The technique requires maintaining or generating keys for every host visited, with

the assumption that the hosts will destroy the keys after the computation is complete.

This raises concerns especially if the agent needs to revisits a previous host. PRACs are

aimed to provide integrity rather than confidentiality. Karjoth et al. (1998) improved the









technique using digital signatures to create a chain of results obtained from the hosts

visited.

Young and Yung (1997) proposed the sliding encryption technique to deal with the

small size data usually obtained from hosts by mobile agents when compared to the size

of the encryption keys and resulting ciphertext. The technique is to ensure confidentiality

with public key cryptography accumulating the encrypted data in each platform visited.

Another approach is called cryptographic traces (Vigna, 1998), which aims at

detecting any kind of tampering with a mobile agent. It relies on code execution

verification using traces based on cryptography. This technique requires each host visited

by a mobile agent to create a trace of the execution of agent. This trace is both maintained

in the host and forwarded to the other hosts subsequently visited by the agent. The major

concern is the size of the trace, which needs to be carried with the agents. This is another

unauthorized modification detection technique.

Hardware-based solutions. Hardware support is recognized as the only tractable

solution since no single software solution proposed so far addresses every possible attack.

One example is the Tamper-proof Environment (Wilhelm et al., 1998), which is a regular

computer with some specialized OS, manufactured only by authorized well-known

parties. Sites that offer services to mobile agents purchase these computers and advertise

this. In turn agents execute only in these isolated places by interacting with the hosts on

those sites by well-defined secure interfaces. However it might still possible to devise

some attacks and the solution does not seem feasible because of its special requirements.

A similar approach has also been taken by Yee using secure coprocessors (Yee, 1999).









Environmental key generation. Environmental Key Generation approach

(Riordan & Schneier, 1998) relies on some interesting observation that agents can find

some keys whose protection is crucial only after they are on the host on which they will

execute. A key can be sent to an environment such as a news list or a mailbox. The idea

is to not carry the keys but to know how to find them. After agents find their keys in this

manner they can do their jobs with some protection. An interesting example is given as a

search agent that needs to search remote databases without revealing what it looks for.

The solution is nothing more than using a cryptographic hash function that is applied to

the items in the database and checking the results against the already hashed value carried

with the agent. Because it is still vulnerable to denial-of-service attacks by changing the

value carried by agent this approach should be used together with some other solution to

prevent the kind of attacks mentioned.

Multiple (cooperating) agents. The idea of using more than a single agent for

fault-tolerance and security has also been studied by some authors. However this

approach has not been attracted deserved attention. Since the theme of this dissertation is

in this category, we provide related previous work in Chapter 3 in more detail.

Other approaches. Another approach protects the computation of agents by

relying on trusted third parties (Corradi et al., 1999): some sites that offer a trusted

environment for mobile agents to perform secure operations. Agents need to visit such a

site after computing in some untrusted host. Another example (Marques et al., 1999)

assumes a "neutral trusted" host for e-commerce applications. But it is not clear in these

proposals, why and how untrusted hosts guarantee to send the agents to so-called trusted

servers to compute with secrets.









Meadows (1997) proposed the detecting objects idea, which is originally proposed

for database integrity against unauthorized modification. In this scheme, some dummy

objects are inserted into the mobile agents. For example, a shopping agent can be

provided by some dummy offers as if they were coming from legitimate merchants. By

carefully selecting these objects, the owner platform can check the agent whether these

dummy objects have been tampered with. If there is no modification to these dummy

objects, then with some degree of confidence it can be said that there have been no

modifications to the other parts of the agents. However, this scheme is highly application

specific. We extended the idea to detection objects and code (Onbilger et al., 2001). In

this scheme, some dummy code fragments can be inserted into the agent code together

with dummy objects. Depending on the degree of protection desired, dense of injection

can vary for different applications. Since, it is intractable to distinguish dummy code

fragments from the original ones, execution results of the dummy code can be checked

against previously recorded results and it can be detected whether the code is executed

correctly. By combining the technique with multiple cooperating agents, detection can be

made immediate, without requiring the agent to return to the originating platform.

General discussion and survey papers for mobile agent security are given by

Tschudin (1999), Jansen (2001), Claessens et al. (2003), and Oppliger (1999). Some

flaws in the security protocols, which have been proposed before and summarized above

are identified by Roth (2001).














CHAPTER 3
MULTIPLE COOPERATING MOBILE AGENTS

3.1 Introduction

Information Dispersal is a technique used for fault- and intrusion-tolerance of

information. The study in this area consists of three phases. In the first phase, Shamir

(1979) showed how to construct a robust key management scheme for cryptographic

systems. In this scheme, a secret S is divided into n pieces in such a way that S can easily

be constructed from any of the k pieces, but the knowledge of k-1 or fewer pieces reveals

no information about the secret S. This is called a (k, n) threshold scheme. The

remarkable aspect of the scheme is that k-1 pieces give no information about S, so it is

applicable to relatively small data such as secrets. However, this scheme is not space

efficient, consequently it is not suitable for large data such as a file. Rabin (1989) showed

how to disperse a file into pieces and to use a subset of pieces to reconstruct the file later,

in a space efficient manner. In this scheme, a file F of length L is divided into k pieces

each of length L/m. The file can be reconstructed from any m pieces. The sum of the

lengths of pieces is L(k/m). Because k/m can be chosen to be close to 1, the scheme is

space efficient.

The second phase includes the techniques of Fragmented Data Processing (FDP)

(Fray & Fabre, 1991) and Fragmentation-Redundancy-Scattering (FRS) (Fabre et al.,

1994). The common goal in this phase, in addition to the concept of information dispersal

for security in the first phase, is the processing of sensitive information. FDP is designed

to employ parallel processing techniques to process fragmented and scattered pieces of









data. Sensitive information (both code and data) is fragmented into pieces in the trusted

part of a distributed system and the pieces are located on hosts in the untrusted part of the

system. The code fragments are constructed using a pre-processor and compiler so that

when collaboratively applied by the hosts on the corresponding pieces, the result

becomes exactly the same with the result of the original code applied to the original data.

Similarly, the goal of the FRS is to employ several hosts to provide fault-tolerance

of the systems and intrusion-tolerance against deliberate faults. The fragmentation

process may consist of several iterations. At each iteration, application objects, which

consist of both code and data are decomposed into more elementary objects if there is

still identifiable confidential information exists. Redundancy is achieved by either

applying techniques such as checkpointing and synchronization or relying on detection

mechanisms and voting protocols implemented over underlying multicast communication

system. Scattering phase consists of assigning the fragmented and redundant elementary

objects to the hosts in the system. The goal is to assign the elementary objects in such a

way that the objects that are assigned to the same host would not reveal any confidential

information.

We consider our work as part of the third phase in this field. There are however

important differences between the third phase and the former ones. FRS and FDP utilize

a distributed static infrastructure to provide tolerance. In our case the target environment

is already distributed and extremely dynamic. The assumption with those techniques that

there are fixed available hosts in a close environment does not hold for the MA problem.

FRS merely relies on a spatial technique (replication) but we need to consider both spatial

and temporal solutions for efficiency. Also, in addition to Shamir and Rabin's work we









also need mechanisms not only to distribute the secrets but also to be able to compute

with them again in a distributed fashion. These differences inevitably add new challenges

to the known problems and solutions.

3.2 Requirements and Objectives

There are mainly four requirements to meet in providing security to mobile agents

as mentioned in Chapter 1. The first one is that a solution proposed to protect hosts from

possibly malicious hosts should not jeopardize the protection of hosts from agents. Some

proposed solutions such as obfuscation mechanisms might not be feasible since they may

cause hosts to be vulnerable to attacks by hostile mobile agents. The second important

requirement is that solutions should not limit the potential benefits of mobile agents,

which are otherwise observed and enjoyed. While security is an important requirement

for the mobile agent technology to be accepted and widely used, it should not sacrifice

the benefits we gain from using them. One such property that is usually ignored by the

proposed solutions is the autonomy of mobile agents. Since it is one of the distinguished

features of them, sacrificing autonomy would severely limit the their applicability to the

wide range of possible applications. For example, an MA may be required to

communicate with its owner's host to perform some security sensitive operations. This

violates the autonomy property of the agents, which constitute the basis of disconnected

operation, which is a highly desirable mode of functioning in m-commerce. Another

example is to allow mobile agents to execute only on trusted hosts and then limit the use

of mobile agents into the client/server model to access the untrusted hosts. While this

model provides security it sacrifice the benefit of customizing the computations on

servers, which is another important feature of mobile agents. The third one is related to

one of the fundamental principles of security: when there are easier ways of defeating a









system, an attacker would not try to penetrate to the system through well-protected

components. So, it is vital to address easier attacks against mobile agents, which are

denial-of-service and replay. The last requirement is extending the network trusted

computing base concept. This concept has been proposed as a solution without giving

clues about how they could be realized. Simply assigning some dedicated hosts for this

purpose does not seem practical. At least, these hosts could be single points of failure and

targets of attacks. Moreover, locations of these hosts should also be considered.

Under the requirements given above, the goal is to make individual MAs

"meaningless" when they are treated as a single entity as much as possible since there is a

trade-off between openness and security. This makes them resistant against malicious

behavior of the hosts where they execute. A given task is split up into two or more MAs.

These MAs are located in different hosts and migrate when necessary. They exchange

information and partial results of execution at certain synchronization points. So, the

approach presented here is based on information (data and code) dispersal supported by

known cryptographic techniques.

In a mobile agent system there are three general security objectives:

1. Data confidentiality,
2. Correct code execution and data integrity,
3. Code confidentiality.

Data confidentiality is the easiest-to-achieve goal in our approach especially if the

data needs to be kept confidential from certain hosts that possibly could gain advantage

from knowing it. It is possible to place sensitive information (i.e., credit card) in an agent

encrypted with a nonce and place the nonce in a cooperating agent. Other more complex

means are also possible.











Data integrity can be achieved through the idea of detection objects, which has

been proposed by Meadows (1997) to detect possible modifications to MA data. Correct

code execution along with data integrity can be provided by extending the detection

objects idea and introducing detection code. Predetermined but random code fragments

are injected into the original code of the agent (possibly by also introducing dummy

data). These code fragments can be produced by a tool and the modified program can be

guaranteed to give the exact same result as the original when executed. At certain

synchronization points, agents exchange the results of the modified program together

with the results of the original program. Since the dummy code results have to be fixed,

another agent can easily check them against the precalculated values. Together with

realizing time limitations and dense injection (i.e., one line of dummy code for every

original line) it can be guaranteed that the original code was executed correctly.

Although a human can detect which portions of code are dummy by analyzing the

code, it is an undecidable problem for machines especially if data flow analysis is

prevented by mixing the data flow from the original code to the dummy code (e.g.,

y=y*x; z=y; z=z/x; y=z; y and z are dummy, x is not). Since the concern here is instant

correct execution of code and time for that execution can be limited to a few seconds, an

analysis by an human is prohibited. The approach presented is equivalent to randomized

state information that could be maintained and exchanged among agents.

Code confidentiality is the most difficult of these problems. The difficulty of the

problem comes from the fact that it is not possible to limit the time for analysis; therefore

human analysis attacks are possible. Due to the difficulty of the problem, one might









restrict the confidentiality of code into certain decision functions (e.g., a shopping agent's

purchase decision) and apply the code injection technique to those functions before

splitting. In addition to arbitrary code generated by a tool randomly, other mechanisms

can be applied. For example, code can be generated which consists of similar statements

to the original code. Also, code libraries can be used to provide code that implements

some relevant or irrelevant function to the original function.

The three goals above are the generalization of broad range of diverse security

requirements of the MAs. There are certain situations where combinations of the three

goals above overlap. One such requirement in a mobile e-commerce environment is

computing with secrets in an untrusted environment. Any such secret (e.g., a private key)

cannot be revealed to any third party since the information here is more sensitive. For

example, people reveal their credit card information to buy lunch but not their social

security number (even if asked). So, it is crucial to have the ability not only to keep

certain data secret but also to compute with that data. Digital contract signing (Sander &

Tschudin, 1998) is such an example and Chapter 4 demonstrates how to do this

computation remotely by a group of agents without divulging secrets or inventing new

cryptographic algorithms.

3.3 Definitions

The problem of protecting MAs against malicious hosts comes from the fact that

they are, by definition, autonomous. Since this aspect of MAs is the most important

among others and actually it is what make them special, it would not be a good idea to

give it up for the sake of making them secure. But if we define "autonomy" not for a

single MA but a group of communicating and cooperating MAs, which rely only on each









other to perform a single task to achieve a goal, we will be able to reach autonomous

secure MA groups.

Definition. Autonomous MMAs. A group of mobile agents is said to be autonomous

if they together have the knowledge necessary to perform a single task, and they

communicate and cooperate to perform that well-defined task.

What follows is the definition of the mission concept.

Definition. Mission (traditional single mobile agent case). A mission consists of a

mobile agent, a set of hosts to be visited, execution of the agent's code on these hosts and

the set of migrations of the agent between any pair of these hosts.

Definition. Mission (multiple mobile agents case). A mission consists of an

autonomous group of mobile agents, a set of hosts to be visited, execution of the agents'

code on these hosts, a set of migrations of the agents between any pair of these hosts and

communication among the agents.

The term mission is the counterpart of the term session in client/server computing.

A mission can represent any session that carries out a computation such as a database

search, a network management activity or an e-commerce task, etc., using MAs.

3.4 Mission Models

Single mobile agent model. This basic model is illustrated in Figure 2-1 in

Chapter 2. The mission must be accomplished by visiting several hosts, which requires

process migration from host to host. The agent computes (e.g., is being executed) in these

hosts and returns home at the end of a successful mission in this case. Note that the

illustration in Figure 2-1 is a simplified generic case of a mission. It may not be necessary

for a mobile agent to return home and a same host might be visited multiple times in the

same mission.










Mobile client/server model. Depending on the mission given, one or more of the

following reasons might prevent placing an agent on a service provider host:

* The server may not have a mobile agent platform,
* The mobile agent platform supported might be a different one,
* The host may not be trusted or may not provide any measure to appraise trust on.

Therefore in this model the mobile agent is located on a host, which provides the

necessary environment and is close to the target host. The model is illustrated in Figure 3-

1.



e Host

Host [Agents





Host IAgent [Agent Host





M- migration
4....... communication
Agent Owner's Host
Figure 3-1. Mobile client/server model

This model is not suitable for applications where it is necessary to customize

certain server functionality. If the model is used for security purposes, it will not meet the

second requirement mentioned in Chapter 1.

Multiple mobile agents model. The multi-agent paradigm fits well with the

concept of protection of an application as a whole. It is more difficult to compromise a

task if the task is split into multiple collaborating agents. In the context of data secrecy,

this is also referred to as information dispersal for security.










The multi-agent model does not differ from the classical agent model in terms of

the definition of the mission. The difference is due to the definition of the autonomy

property of MAs. So, in the new model, MAs are autonomous as a group but not as an

individual entity. The group of agents carries out a single task by communicating and

cooperating.

Figure 3-2 illustrates the model. In the model, we call one of the agents the master

agent (Alice in the figure), who actually visits the set of hosts that are necessary to

complete the mission. This set of hosts is called the itinerary of the mission. The itinerary

may or may not specify the order of the hosts to be visited. The other agents are called

support agents (Bob in the figure), who visit only the hosts outside of the itinerary of the

master agent. Note that, the model that we describe here is the most generic multi-agent

model.

Host Host

1 Alice -- I Alice


Host

I Bob





Agent Owner's Host



S3. ti ob
I *.....* communication G l-

Agent Owner s Host
Figure 3-2. Multiple mobile agents model with two mobile agents









Variations of the model admit more than one master agent, or alternatively, a peer-

to-peer architecture can be employed. In the figure, Alice and Bob, migrate according to

their itineraries and communicate with each other.

As it is clear, the migration of an agent or agents in a group is more complicated in

this model and requires support from an underlying system that is aware of the

underlying network topology. This issue is addressed in Chapters 5 and 6.

3.5 Multi-agent Systems (MAS) vs. Multiple Mobile Agent Systems (MMAS)

In Chapter 2, we have defined multi-agent systems and said that multiple mobile

agent systems differ from those. Following table highlights the differences between the

two.

Table 3-1. Comparison of MAS and MMAS
Multiple Cooperating
Property Multi-agent Systems Mbile Agent
Mobile Agents
Interactions Not pre-defined Pre-defined
Global system goal Not exist Exist
Autonomy w.r.t. goal Yes No
Single owner No Yes
Main goal Easy, efficient, intelligent Combine MAS and MA
and distributed problem Paradigm
solving MA Protection

However, it should be noted that the above properties of multiple cooperating

agents are internal to their group. There is nothing to prevent a group of multiple

cooperating agents from participating in any multi-agent system. So, from a broader point

of view multiple cooperating agents can perfectly become a part of any multi-agent

system.









3.6 Proposed Architecture for MMASs

In this Section we present the proposed system architecture of MMASs. We will

explain the architecture by providing the step-by-step workflow of the system as

illustrated in Figure 3-3.

On the host side we show the components/modules of an MMAS. Note that, the

Mission Planer, Mission Optimizer, Security, and the Context components can be

interpreted and implemented as part of the MMAS. However, we show them as separate

components in the figure for the sake of clarity.

On the network side the double-line boxes represent systems rather than modules.

These systems, except the Directory (a.k.a. Yellow Pages) system are distributed systems.

The network positioning system is a peer-to-peer distributed system, which provides

relative positions of the participating hosts via coordinates in a geometric system. The

proposed architecture for this system is given in Chapter 5. The DNS is the Domain

Name System. The anticipated role of the DNS will be clear in Chapter 5. The Directory

system can be either a centralized or a distributed system. Although it is not addressed in

this dissertation, we believe that it needs to be a distributed system. The primary

responsibility of this system is to maintain and provide the information about the hosts,

which employ a MA System and the services provided. The workflow and the

responsibilities of the components in the architecture are given below.
























HOST
-- --- 0 ------I------ -
S^ NETWORK
Directory [= Network Positioning t N


DNS
Figure 3-3. Multiple mobile agent system architecture

Step 1: The Application receives the information from the user through the User

Interface. Two example applications are provided in the next Section.

Step 2: The Application presents the information to the Multiple Mobile Agent

System (MMAS).

Steps 3 & 4: The MMAS gives the related information to the Security module.

This module is responsible for determining the security level required for this instance of

the Application and deciding the number of agents and the necessary communication

among them. The module returns this information to the MMAS. Note that, apart from

the workflow presented, the MMAS and the Security modules can interact to create the

group of mobile agents necessary for the mission by observing the necessary dispersal of

information, code and data, at the later steps in the workflow.









Step 5: MMAS presents the information provided by the Application and the

Security module to the Mission Planner. This module is responsible for planning the

mission by coordinating the other support modules.

Steps 6 & 7: The Planner module first asks the Context module for information

about where and how this particular instance of the application could take place as a

mission. The context module in turn communicates with the Directory service to obtain

contextual and network/topology information.

Steps 8 & 9: The mission planner receives the contextual information.

Steps 10 & 11: The planner then asks the Mission Optimizer to compute the best

possible itineraries for each agent by taking into account their interactions during the

mission, in terms of the total execution time of the mission.

Step 12: The planner presents the optimized mission information to the MMAS.

Step 13: MMAS using all the information provided by the modules creates the

mobile agents to accomplish the mission and passes the agents to the MA System. Any

existing MA System can be used here, however one might expect some modifications on

the existing system for integration/interoperation of the MMAS and the MA System.

Steps 14 & 15: The MA System, just as in the single mobile agent applications

send out the agents to the network. Mobile agents) return to the MA System with the

result.

Steps 16, 17 & 18: The result of the mission is presented to the user.

Following chapters of this dissertation deals with the research issues of Security,

Mission Optimizer and Context components as well as the Network Positioning System.

More precisely, Chapter 4 is related with the Security component. Chapter 6 addresses









the issues with the Mission Optimizer component and also makes it clear how context-

awareness is an important concept in MMASs and their security. Some issues with the

Context component and a proposed architecture for a network positioning system are

given in Chapter 5.

Due to the lack of the Directory component, which is out of scope of this study, we

assume its existence, however we make no assumptions about the use of contextual

concepts. The TPNP system (Chapter 5) is capable of providing this information as a

peer-to-peer system. A directory system will only need to cooperate with the TPNP to

obtain contextual (including location) information.

3.7 Example Missions

In this Section we present two real-world examples of multiple mobile agent

applications based on the system architecture given in the previous Section.

Example 1. sayingg Agent. The shopping agent is a classical example of mobile

agent applications in e-commerce (See Chapter 2). The job of the agent or the group of

agents is to visit on-line merchants of the product of interest, negotiate and finally

purchase the product by making the payment. We assume that the user would like to

purchase flowers.

The user presents the details of preferences for this purchase (e.g., a dozen red

roses, under $10, with a gift card) to the shopping agent applications using the user-

interface provided by this application. The user either indicates the security requirements

specific for this mission or the application uses a preference file to use default or existing

set of requirements for this kind of missions. The application passes this information to

the MMAS possibly in XML format. MMAS consults the Security module to determine

the mechanisms needed to apply to be able to meet the security requirements of the user.









For example, the purchase may require a digital signature to be generated and presented

to the merchant, which is the subject of Chapter 4. We assume that the Security module

decides to use a master/support model with two agents; Alice and Bob from Section 3.4.

MMAS passes all the information about the mission to the Mission Planner.

The planner needs first the context information, which consists of the potential

merchant hosts to be visited by Alice, the set of hosts of which a subset would form

Bob's itinerary, their trustworthiness and locations. This is the job of the Context module

in the architecture and this module contacts the Directory system for this purpose. The

directory system executes a query given the input as the transaction of purchasing flowers

from potential merchants. The result of the query appears to be a list of merchant hosts on

the Internet. This part is exactly the same as of the classical single mobile agent

applications. The directory service will also provide additional information about these

hosts. This information needs to be the level of security provided by these hosts, the hosts

that Bob will be visiting, the level of security provided by these support hosts and

location information of all the hosts. The network positioning system, TPNP is capable of

providing all these information, which is the subject of Chapter 5.

The directory system returns the information about merchants and potential support

hosts to the Context module. The mission planner at this point has two issues to consider,

which are to find best possible itinerary for Alice to visit merchants and the selection a

subset of hosts returned by the Context module for Bob. The mission planner may consult

the user for choice of possible merchants or may use a file to determine the preferred

merchants. The planner then consult the Mission Optimizer module to provide the order

of hosts to be visited to make the mission as short as possible. In addition, the mission









optimizer is responsible for choosing the closest support agent hosts to a subset of

merchant hosts. The result of this selection is the itinerary of Bob including the order of

hosts. This is the subject of Chapter 6. When the mission planner returns its decisions, the

MMAS is ready to create the agents for the flower mission and then pass them to the MA

system to be forwarded to the network.

Example 2. Software Distribution. Our second example is from a relatively new

application area of mobile agent technology. The scenario is as follows. A software

vendor has a product running on their customer sites around the world. The company

continuously improves its products and provides updated versions to the customers. They

also need to provide their customers with software patches for newly found security flaws

in their products.

The company figures out that mobile agent technology is a viable alternative for

this problem, that is using a push model with mobile agents is rather powerful than the

pull model in client-server computing. They also know that security is still a drawback of

mobile agent technology. But they also are aware that a group of cooperating multiple

agents provide the level of security they need. So, they develop a multiple mobile agent

system following the architecture presented in the previous section and ship the MA

execution environment part of this product to their customer sites along with their

application software.

When a new security patch is ready to be installed for a recently discovered flaw in

their application software, they launch agents to the Internet to update their customer

systems. They organize their software in well-designed small modules so that when they









need to update some module, their agents will only carry that small module as the

payload.

We will not repeat the whole process for this application but we will provide only

the differences from the previous example. In software distribution, the number of sites to

be visited are expected to be much larger than the e-commerce applications. So, several

agents or group of agents may need to be deployed according to their locations. Since the

customers are well known by the company, the directory system's main responsibility of

providing host information is not useful. However, context and network information is

still quite important.

This application may use the master/support agent model as well as the peer-to-

peer model. The former may be preferred for small number of customer sites. The latter

is more suitable when the number of sites is large. In this case, agents need to act both as

a master agent to do the primary job of software distribution and checking the integrity of

peers for security. The alternative is to use the former model with multiple master agents,

and make the support agent responsible for checking all of them.

We assume that the security component decides to use a master/support agent

model with two agents, Alice and Bob. The software module to be installed is split up by

the MMAS with the help from security and mission optimizer components. Security

component makes sure that the payload of either agent would not reveal essential

information about the module. Mission optimizer's responsibility is to balance the load of

agents so that the cost of the mission will be minimized in terms of agent migration and

communication.









Both Alice and Bob have the credentials to check the integrity of the payload of

each other. On every host Alice visits, she contacts Bob and sends the payload integrity

check to Bob. Bob verifies the code as well as the identification of host on which Alice is

running. If all checks are successful, Bob sends Alice the part of patch he is carrying.

Alice after checking the Bob's information installs the new module in the customer

system and migrates to the new site in her itinerary. Bob, if necessary also migrates to the

next host in his itinerary. Neither agent in this application needs to return home after the

mission completes.

3.8 Related Work

Multiple agents have first been used by Minsky et al. (1996) for fault-tolerant

distributed computing with MAs. The proposed scheme is deploying clones of an MA to

identical servers at each stage of the computation and then comparing the results. In this

scheme MAs do not communicate or cooperate. The assumptions that the identical

servers would be available and that they would be under different administration

domains, so that they would behave independently, are not realistic.

Yee (1999) proposed a fault-tolerant approach, where replicated agents are sent to

the same set of hosts to figure out airfare prices for a flight ticket purchase. Agents

traverse the hosts in the reverse order and at the end the minimum prices they come up

with are checked. In the one malicious server case it is possible to find out the actual best

price. This is one of the earliest proposals using multiple mobile agents which is

application and case specific.

Ng (2000) used multiple agents for security purposes. In this scheme, again the

agents do not cooperate; instead the task is split into multiple agents so that any agent

alone would not reveal any useful information. In contrast to the multiple agent model we






53


use, agents in this scheme visits the same hosts, therefore they need to be completely

anonymous to be able to defeat attacks.

Cooperating multiple agents have been first used by Roth (1998). It is shown that

two cooperating agents, under certain assumptions, can verify the path each agent takes

and whether the migration patterns adhere to the itinerary of the agents.














CHAPTER 4
REMOTE DIGITAL SIGNING WITH MOBILE AGENTS

4.1 Introduction

Although the MA paradigm opens many interesting applications, to validate it as an

alternative to traditional client/server computing, one must address its security issues. In

particular, it should demonstrate the ability to compute with secrets in remote public

domains. A good example of the need for this is digitally signing a contract for m-

commerce (and in general e-commerce) applications with MAs as shown by Sander and

Tschudin (1998). We call this problem remote digital signing. In this chapter, a multi-

agent architecture is used and a solution to this problem is presented. The techniques we

explore and analyze are based on information dispersal in distributed system security

terms as well as multisignatures and secret splitting in cryptographic terms. The idea is to

devise a secure way of sharing secret keys among members of a multi-agent group and

signing with shares.

4.2 Electronic Commerce and Mobile Agents

Among many application areas of MAs (such as information retrieval, e-commerce,

network management, network/site security, distance education, and software

distribution) e-commerce draws the most attention from both academic and industrial

researchers, for example see Busch et al. (1998) and Klusch (1999). This is mostly due to

the fact that, MAs and in general agent systems have the capability of representing users

(i.e., customers) in the cyberspace. Agents can effectively profile user preferences, act on

behalf their owners, participate in e-auctions, watch stock prices, search for commodities









and find the best offer from competing vendors, purchase goods by paying and

committing to transactions, communicate and cooperate with other agents of relevant

goals. Although it is now agreed that MAs are not a new enabling technology, they offer

many technical capabilities together (i.e., all-in-one) over the traditional client/server

computing (Chess et al. 1995a; Chess et al. 1995b; Lange & Oshima 1998). Mobile

commerce (m-commerce), which is a rapidly growing field in e-commerce, is especially a

suitable application area of MAs.

4.3 Mobile Commerce and Mobile Agents

Mobility of agents brings unique advantages to m-commerce. Mobile devices such

as PDAs and laptop computers have limited battery life, intermittent and low-bandwidth

connections to the fixed network. Traditional client/server computing which was

originally designed for and very well fit into the fixed wireline networks is not suitable

for m-commerce due to these limitations. MA paradigm enables disconnected operation

(Chess et al., 1995a; Gray et al., 1996), where a brief connection to the fixed network

from a mobile device through the wireless network is sufficient to launch an MA (or

MAs) to engage in a mobile commerce activity. For example, a laptop owner, which has

a wireless connection to the Internet, through a cell phone, may launch an agent to search

for the best offer for an airline ticket and make a purchase. While the agent working

towards the goal of purchase, the owner can (or may be forced to) disconnect from the

network. When the MA accomplishes the goal, it takes another brief connection to

receive the agent with the results.

4.4 Mobile Agent Security in Mobile Commerce

There are two aspects of the security issues in MA technology which are known as

the malicious agents problem and the malicious hosts problem. In the former case, the









hosts that are to accept and execute the agents should be protected against any possible

hostile behavior of agents. There are known mechanisms such as sandboxes proposed and

implemented. The latter case is considered to be much more challenging due to the

remote nature of the platforms where the MAs are to be run. Since these platforms are

owned and operated by other parties, it is difficult to establish trust. Classical security

mechanisms designed for distributed systems, including the cryptographic ones come

short for threats against the MAs due to the assumptions, which do not hold for MAs

(Chess, 1998). So, protection mechanisms are needed to make MAs safe in possibly

hostile environments.

E-commerce is the most security demanding application of the MA paradigm. This

is not different for m-commerce, which is a special case of the broader topic of e-

commerce. In fact, it can be argued that if all the security requirements of e-commerce

applications are met, then the general MA security problem is solved altogether. The

shopping agent application where a MA is deployed to find the best possible price for

some good such as an airline ticket, flowers or CDs, and make a purchase, has become

the classical problem for discussing the requirements of MA security and proposing

solutions to certain aspects of the requirements (see for example, Berkowitz et al. (1998),

Hohl (1998), and (Yee 1999)). Hohl (1998) provides an extensive list of attacks using a

shopping agent application example that could be launched against an agent.

The focus of this chapter is the remote digital signing problem for shopping agents.

In any trade, principals engaged in the activity need to authenticate each other. A

merchant would like to know whether the credit card presented by the buyer really does

belong to the party or whether a check provided is legitimate and authentic. Customers









would like to make sure they present their confidential information such as a credit card

to the merchant of their choice, but not anybody else. Similarly, merchants need to

authenticate the MAs and their owners. This is necessary to prevent repudiation, which

could be a very simple attack to devise using MAs. Even honest users may change their

minds well after the transaction took place and deny that they didn't send any MAs to

buy any such product. On the other hand, a hostile MA could masquerade a legitimate

MA and hence its owner, to engage in fake trading to harm either or both of the principals

of the transaction. Therefore a MA should be capable of digitally signing a contract

agreed on by both parties to authenticate themselves and their owners, remotely and

publicly, meaning that on the hosts they execute.

4.5 Objectives

Our objective in general, is to meet the requirements of solutions proposed for any

aspect of MA security problem. These requirements were identified in Chapter 1.

Our specific goals in this chapter are to achieve a solution to the remote digital

signing problem which should be as simple, realistic, flexible and ubiquitous as possible.

With simplicity, we mean that the solution will be easy to understand and implement. By

the use of already established and standardized digital signature schemes, such as RSA

and El Gamal algorithms, if the original signing and verification functions can be used

then specific implementation may not even be needed for our problem. To be realistic, it

is meant that a proposed solution should fit into the real world environments, where they

are to be used. For example, in theory, threshold signature schemes seem to fit very well

in the MA paradigm when a multi-agent model is used. However, in practice it is

necessary to identify the hosts where these MAs are going to be executed. The number

and location of these hosts are to be restrictive as explained in detail later. Flexibility is









related to the autonomy of MAs from another perspective. Unlike some other solutions

proposed, it is important to distinguish what can be done (i.e., signed) by a MA and what

actually has been accomplished. Ubiquity is again related with the cryptographic

functions used. Widely implemented cryptographic signature schemes improve the

scalability in terms of number of hosts where MAs may need to find and use these

schemes.

4.6 Background

Multiple agents have first been used by Minsky et al. (1996) for fault-tolerant

distributed computing with MAs. The proposed scheme is deploying clones of an MA to

identical servers at each stage of the computation and then comparing the results. In this

scheme MAs do not communicate or cooperate. The assumptions that the identical

servers would be available and that they would be under different administration

domains, so that they would behave independently, are not realistic. Ng (2000) used

multiple agents for security purposes. In this scheme, again the agents do not cooperate;

instead the task is split into multiple agents so that any agent alone would not reveal any

useful information. In contrast to the multiple agent model we use, agents in this scheme

visit the same hosts, therefore they need to be completely anonymous to be able to defeat

attacks. Cooperating multiple agents have been first used by Roth (1998). It is shown that

two cooperating agents, under certain assumptions, can verify the path each agent takes

and whether the migration patterns adhere to the itinerary of the agents.

Sander and Tschudin (1998) introduced the concept of Mobile Cryptography. The

idea is to encrypt agents as a whole and apply computing with encrypted functions and

data. Although it is limited to polynomial and rational functions, this is a good example

of a software solution to the MA security problem that is based solely on cryptography.









In the same paper they also introduced the concept of "undetachable digital signatures,"

which is based on the concept of computing with encrypted functions. They point out that

this is a possible realization of "... an agent would like to use the secret in public e.g., to

compute the digital signature of an order form but without disclosing the secret needed to

do so." In this approach, user constraints are "glued" together with the general purpose

signature function to enforce them to be a part of the signed contract; hence the term

"undetachable signatures." Nevertheless, they also point out that the scheme on which

their proposal is based has been successfully attacked.

Kotzanikolaou et al. (2000) proposed a solution to the problem introduced by

Sander and Tschudin (1998). They use RSA (Rivest et al., 1978), which is based on

exponential functions rather than rational functions. However, as the term "undetachable

digital signatures" implies, the solution given by Kotzanikolaou et al. (2000) requires that

the signature be generated by the user (i.e., owner of the agent) and given to the agent

before the mission takes place. This contradicts MA autonomy. This is due to the fact that

the purchase decision has to be made strictly before negotiation with the sellers. User

constraints, which have to be signed before these negotiations, therefore need to be pure

data. However, it is desirable that a decision function be executed after or during the

negotiation or bargaining process. This means that agents should be capable of deciding

what to buy, where to buy, under what conditions, price, type of payment, delivery

options, etc. For example, the user demand should be able to be stated as flexibly as

possible with "I would like to purchase as many blank rewritable CDs as possible and

I've got $100." The result of the decision function will have a direct effect of the contract

to be signed. Therefore what we need is to make the agents capable of computing with









secrets in public as the quoted sentence in the previous paragraph implies. Without this

capability, either the user must have a perfect knowledge of market conditions that might

change rapidly, or user interaction during the mission is necessary. In the former case it is

highly possible that the mission may fail, in the latter, autonomy is sacrificed. The

problem arises from the fact that a malicious host should not be able to manipulate or

directly use the agent in order to sign "arbitrary" documents. On the other hand, agents

should also be capable of preparing the documents to be signed. The challenge is to

resolve this contradiction.

A threshold signature scheme in conjunction with the use of multiple agents and an

undetachable threshold signature scheme, which combines undetachable signatures with

threshold signature schemes, have been proposed (see Borselius et al. (2001) and further

references). While the former is vulnerable to attacks when used alone the latter still

carries the concerns with threshold signatures.

First concern is that threshold signature schemes come in great variety. They are

neither standardized nor widely accepted. This means that MAs may face problems in

finding the hosts to execute, which would have standardized implementations of these

schemes. The second concern is threshold signature schemes tacitly assume that there

would be sufficient number of shareholders to sign a document. Even small values of this

"sufficient number" may not be feasible for MAs since in practice, existence of hosts for

MAs to execute on, finding those hosts and location of them in the underlying network

are problems as will be explained later. So, threshold schemes are reduced to

multisignature schemes by these restrictions. Nevertheless, their complexity remains.









4.7 Multiple Cryptography

Multiple cryptography, as the name implies, covers the cryptosystems that deal

with more than two parties as opposed to the classical cryptography where there are only

two parties: the one who encrypts or signs and the other who decrypts or verifies. In fact,

there are many real-world applications that have multiple parties involved. For example,

in a banking application, electronic fund transfers require approvals of bank officials of

different ranks. Usually, at least two people are involved for a single transaction.

Ironically, this is such an application that, in the digital world, a more realistic abstraction

of the real world than the real world itself may be possible. Using the same example, a

bank cannot have a signature. Only people who work for the bank have signatures, and

they sign on behalf of the bank. But with multiple cryptography, it is possible to assign a

key to the bank, and shares of this key with the individuals who work for the bank. When

these officials sign a document like a check, the signature they generate perfectly

represents the bank itself, but not the individuals who really signed the document. So as

the example implies, it is possible, with multiple cryptography not only to share the

secrets but also compute with them without regenerating the secrets.

Our focus in this chapter is on multiple digital signatures or multisignatures, which

are a special case of multiple cryptography. The term refers to digital signature schemes,

which enable multiple parties to sign documents or messages cooperatively but

independently of each other using keys or shares of a key generated for this purpose.

Boyd (1988) shows the generalization of RSA and use it as a multisignature scheme. A

brief explanation of Boyd's work, which is related to our application, will be given later.

Multiple cryptography, in general, is intended for classical applications (e.g., a

banking application). In these applications, shareholders are usually individuals who









represent an organization or a company. There is an important distinction between these

applications and the MA applications. MAs are nothing but software entities. They are

neither organizations nor individuals. Moreover, they are owned by individuals or

organizations. In fact, it can be argued that, the MA owner and a bank have some kind of

resemblance. So, the officials of the bank and the MA perform similar operations when

signing a document. While this is not wrong, the actual difference comes from the fact

that, MA owners are active players, while organizations or companies like a bank are not.

A bank is actually an abstraction and cannot for example sign a document. But in the case

of a human MA owner, this individual can equally sign documents him/herself Also, the

shareholders do not always exist. They are created when necessary and after they

complete their work they cease to exist.

In addition to the threshold schemes like Shamir's (1979), techniques which are

known as threshold cryptography for the purpose of not only sharing keys but also being

able to compute with them without a central authority, have been proposed. A survey of

research in this area was provided by Desmedt (1997). A threshold multisignature

scheme has been given by Frankel and Desmedt (1992). In this scheme, authors combine

RSA signature scheme by Rivest et al. (1978) together with Shamir's (1979) threshold

scheme to distribute and to sign documents with shares. It is also possible to generate the

shares of a secret in a distributed fashion, which enables the shareholders to compute

their own shares without the necessity of a central authority. An example using RSA is

given by Boneh and Franklin (1997). The threshold multisignature schemes are in fact the

generalization of the multisignature schemes. While key sharing is k-out-of-k in the latter,









it is t-out-of-k in the former, which means that t of the total of k shares are enough to

generate signatures.

Nevertheless, threshold schemes do not have specific advantages over simple secret

splitting techniques we are using, with MAs. While it is feasible to use these secret

splitting schemes to both share the keys and compute with them, it is also feasible to

come up with very simple techniques to create multiple combinations of keys for

providing fault-tolerance, as demonstrated by Wu et al. (1999). On the other hand, in our

application, secret splitting has two important advantages: simplicity and ubiquity. We

use very simple secret splitting schemes, which use only addition and multiplication. The

secret splitting schemes we use require nothing but the implementations of the standard

public key cryptosystems, namely, de facto industry standard RSA and the official Digital

Signature Standard (DSS), which is based on El Gamal public key scheme. So, these

schemes do not need any new algorithms or an implementation of those algorithms. It

should also be noted that what makes it possible to use these simple secret splitting

schemes with the El Gamal cryptosystem and DSS is the unique property of the

application that the whole secrets and all of the shares are to be computed and known by

the MA owner; therefore it is possible to perform computations in advance to be used

later when the complete signature is computed. Details of these computations are given in

the next section.

4.8 Key Splitting and Signature Generation

Boyd (1988), by using the multiplicative property of RSA, showed that the

classical RSA is actually a specialization of a general multisignature scheme. For an RSA

implementation for sequential signing, we will use this property. Boyd (1989) also

mentions about a similar technique, which enables to perform signature generation in









parallel. This is the RSA part of the techniques we will use in parallel signing. Note that,

both techniques use nothing but original RSA signing and verification algorithms. The

RSA implementations, which are standardized and used in practice, and their

implications on remote digital signing will be discussed later in the chapter. In the

following, we present techniques to do the same with El Gamal Cryptosystem, which

again use original signing and verification procedures, by using a property that is unique

to MAs, as explained.

4.8.1 Using the Multiplicative Property of RSA

Classical public key cyptosystems use two keys, one is the public key and the other

is the private key. It was shown by Boyd (1988) that this is only a specialization of a

general multisignature scheme in the case of RSA. This is possible since RSA has the

multiplicative property, namely, with the same modulus and two decryption keys d, and

d ,

S (S (mh, d,), d) = S (mh, dl d2)

where S is the signing function and mh = h(m). Here, m is the document to be signed, h is

an appropriate cryptographic hash function (i.e., SHA-1) and mh is the message digest.

Note that, for clarity we defer the discussion of recent advances in theory and practice of

computing the message digest mh for better security of RSA signature scheme until

Section 8.

The modulus n is still the product of two large primes p and q. However, unlike

classical RSA, which has two keys e and that are encryption and decryption keys

respectively, in this scheme k -1 keys are chosen randomly and then the kth key is

chosen to satisfy the property









d, d, **dk1 e = 1 mod .

The encryption key is e and when the d,'s multiplied together the result is the

decryption key d.

So, with three partial keys dc, d2, and d3 three agents can sign a document with

X =((m )d2 )d= mh dmod n

which can be verified by

Xe = mh e modn .

4.8.2 Using the Additive Property of RSA

Boyd (1989) mentions an alternative scheme to overcome the difficulties of

multisignatures with more than two signatories (e.g., different users). In the context of

multisignatures it is possible to assign different keys to different users, and signing

process can be done in parallel. Resulting signatures are then combined. Using the same

scheme, it is also possible for our purposes to split up a key by addition instead of

multiplication assuming three signatories as follows

d = d1 + d2 +d3.

Each agent is provided with one of the partial keys dc, d2 and d3. When it is time

to sign a contract, they are either provided a copy of the original contract or they prepare

the same contract depending on the application (see Section 4.9).

Then they sign by

S1 = mdl, modn S2 = mh2 modn S3 = mhd, modn.

Note that, the message digest mh above is computed as mentioned in the previous

section.









Signatures Si, S2, and S3 are sent back to the server where the signatures are

required. The server computes

S S2 3 = mhd d2 mhd3 modn = mh (dd2+d3) modn = hd modn.

Therefore, the server can also verify the signature by

(S S2 S3)e = hde modn.

The scheme can be generalized for n signatories in the obvious way.

4.8.3 Using El Gamal Public Key Cryptosystem

Here we use a variant of the original El Gamal signature scheme as given by

Kaufman et al. (1995). There are two reasons to do this. First is, this scheme is simpler

and it is easy to compute with partial keys. The other reason is that, the scheme is

actually the El Gamal version used in DSS, which in turn is based on the original idea

introduced by El Gamal (1985). So this scheme will enable us an easy transition from El

Gamal to DSS. The El Gamal variant that we use is summarized below (Kaufman et al.,

1995):

* Long term public key: , secret key: S, where gS modp = T

* For a message m choose random number r, compute gr modp = T,, and message
digest d, (digest of m I T,)

* Sign with X= r + dm S mod (p 1)

* Verify by gx = T, Tdm modp


In the following sections, we use Figure 4-1 to illustrate the signature generation

scheme. There are three mobile agents, Alice, Bob and Carol. Alice is the master agent

and the others are support agents. Figure uses the same mission model developed in

Chapter 3, however, for clarity only a snapshot of the mission is shown.




















Host
S.. ............-" ...........' .." Domain C


SHos4 HostC Host
................ -...... "
Figure 4-1. A snapshot of a mission using multiple mobile agents

4.8.3.1 Signing in sequence with El Gamal signature scheme

The El Gamal cryptosystem uses a pair of private keys as opposed to RSA's single

key. The first one is the long term key as in the RSA. The second is a short-term, per

session, private key for each message to be signed with the long-term key. We split up

both of these keys as follows:

Long-term key: S = S -Sb -Sc (1)

Short-term key: r = r + rb + r. (2)

Here we assume again that our MA group consists of three agents, namely, Alice,

Bob and Carol. Alice is the master and the others are support agents.

To sign a message, Alice computes the message digest d, and signs with

X, = r, + d S, mod (p 1) (3)

Note that, the message digest dm here is the result of an appropriate cryptographic

hash function H applied to the contract m concatenated with T,:

dm =H(m Tm) (4)









where Tm = gr modp as given above. In sequential signing, Alice is the only agent,

who needs Tm and it is assumed here that she is provided by this value before the mission

takes place.

Then, she sends her partial signature to Bob. Bob, upon receiving Alice's signature

Xa, further signs it with his portions of partial keys as

Xb=rb + X Sb mod(p -1)
=rb +Sb +d S Sb mod (p-1)

Carol does the same on Xb, which represent the partial signature generated by

Alice and Bob,

X = + Xb S mod(p-l1)
=r +rb +r Sb S +d Sb Smod(p-1)

Unfortunately, this last equation above, unlike the RSA counterpart, is not equal to

the signature X, although the last term of the equation is nothing but the last term of the

original signing equation:

dm S Sb S,= d S. (7)

This leads us to the observation that the difference between the target signature X

and the signature generated by the three agents Xc is

X,-X= (S- 1)rb +(Sb S,- )r, mod (p-) (8)

Since the right hand side of the equation consists only of constants and partial

private keys, it can easily be computed and given to agents before they are sent out to the

network. This ability is unique to the application that we consider in this chapter. In the

classical applications of digital multisignatures and threshold signatures, it is not possible

to perform the same computation since the signatories are distinct parties and the secrets









they share cannot exist in a single site as a whole. So the last agent in the row, Carol,

sends the partial signature Xc to Alice. Alice computes X, the target complete signature by

using the equation above. The general difference equation for n signatories is

n-1 n
X -X = rt Sk -1 mod(p -1) (9)
t=1 k=-t+1

4.8.3.2 Signing in parallel with El Gamal signature scheme

Signing in parallel with the same variant of El Gamal cryptosystem is also possible

and even easier. For this purpose we split up the keys as follows:

Long-term key: S = S b +S, +Sc (10)

Short-term key: r = r + rb + r (11)

Then, each agent is given the partial keys as well as T, = gr modp since all of the

agents will need it to compute the message digest d, = H(m T,) where m is the contract

to be signed and H is an appropriate cryptographic hash function. They sign

independently of each other as

X, = r +dm S, mod ( -),
Xb =rb +d Sbmod (p-l), (12)
X, =r + d S mod(p 1)

and the support agents send their partial signatures to the master agent. Together

with the master agent's signature, the server combines the partial signatures and obtains

the complete signature as follows

X = X +Xb + X
= r +rb + +d S +dm Sb +dm Sc (13)
=r+d (S, +Sb +SC) =r+d S

The scheme can be generalized to n signatories in the obvious way.









4.8.3.3 Transition from El Gamal cryptosystem to digital signature algorithm

While RSA is the defacto industry standard of public key cryptography, the Digital

Signature Algorithm has been proposed as the official standard as Digital Signature

Standard (DSS) by US National Institute of Standards and Technology. It is based on the

original idea of the El Gamal public key scheme and is very similar to the variant of the

El Gamal cryptosystem.

We will neither provide the details of DSS nor the details of the signature

generation by partial keys. However, we will give the differences between the El Gamal

scheme presented in previous sections and DSS.

The signing equation in DSS is given by

X =r' (d, + S T) modq (14)

where r 1 is the multiplicative inverse of r mod q. Therefore it can be calculated in

advance and instead of splitting up r we can just as easily split up r 1

Signing in sequence with DSS. The key splitting is performed as follows:

Long-term key: S = S Sb +S +S (15)

Short-term key (inverse): r 1 = ra r rb r. (16)

The signing process is very similar to El Gamal scheme. However the difference in

this case is given by

X-X = ((r -1) rb Sb +(rb r-1) ) Sc)T (17)

For n signatories (i.e., agents), the general difference equation is


X X = T rk in S (18)
t=l k=l w=t+l









Signing in parallel with DSS. The key splitting, signing and signature

combination calculations here are very similar to the El Gamal scheme. However, the

combined value is not equal to the target complete signature X. Therefore we call this

value X' and the difference is given by

X-X'= T (rO(Sb +S,)+rb(SO +S,)+r,(S0 +Sb)) (19)

For n signatories (i.e., agents), the general difference equation is

n n
X x, = T_ ,, rtSk (20)
t=l k=1
kzt

4.9 The Overall System for Remote Digital Signing

As presented in the previous section, there are two major multi-signature schemes:

sequential and parallel. Figures 4-2 and 4-3 provide the overall system of signing and

verification processes as part of an MA mission, for sequential and parallel signature

generation schemes, respectively. In this section, we discuss these protocols, compare

them with respect to assumptions made and the analysis of attacks possible against each

scheme.

Please note that, in this chapter we do not address fully the overall security issues

necessary for a whole MA mission. Signature generation is actually an integral part of the

whole mission. However we provide the protection mechanisms when necessary in

addition to the signature generation process to make this process more meaningful.




















Host C
1. Alice asks the Server for a bid for her demand
2. Server provides Alice with its offer along with its signature for the contract
3. Alice sends the server's bid along with its signature to Bob and Carol
4. Bob and Carol verify the server's signature
5. Bob prepares the contract and signs it with his part of private key
6. Bob sends the partially signed contract C, to Carol
7. Carol signs the contract, partially signed by Bob, further with her partial key
8. Carol sends the partially signed contract C, to Alice
9. Alice, with her partial key, further signs the contract and obtains the fully
signed contract CAc
10. Alice delivers the signed contract CAc to the server
11. Server verifies the contract using the public key of the user
Figure 4-2. Protocol for sequential signing with multi-agent model

In both of the protocols, the first part is to obtain the bid of the server along with

the signature for this offer and then verify this signature in steps 1 through 4. After Alice

obtains server's signature, she sends it to both Bob and Carol. Signature verification is

carried out by both Bob and Carol independently on different hosts in different domains.

It would not make sense to let Alice verify the signature since Alice is under complete

control of the very same host that made the offer. Step 5 in Figure 4-2 contains the

contract preparation process performed by Bob. The protocol assumes that Host B does

not have any interest in forging the computation as does Host A. Although the chances

are low, this assumption is not enough for a convincing level of security, since a denial-

of-service attack by Host B is possible. This is due to the drawback of this protocol that

there is no way to check whether the contract signed by the first agent in the row is

correct. This is true regardless of the fact that the decision function is executed in

cooperation with all the members of the group. However, this drawback does not make









the protocol totally inappropriate because even an attack cannot be prevented, it would be

detected in Step 11 when the host attempts to verify the signature. Nevertheless, it is not

possible to tell which host is cheating. The parallel signature generation scheme does not

have this drawback as we see next.

Host B
Host A 4 ) (5
25 Bob

Server Alice r

(9) 7


Host C
1-4. Same as Figure 4-2
5. Alice, Bob, and Carol prepare the contract and sign it with their part of
private key and each obtain CA, CB, and Cc respectively
6. Bob sends the partially signed contract CB to Alice, Carol does the same
with Cc
7. Alice, combines CA, CB, and Cc, and obtains the fully signed contract CAB
8. Alice delivers the signed contract CABC to the server
9. Server verifies the contract using the public key of the user
Figure 4-3. Protocol for parallel signing with multi-agent model

In Figure 4-3, Step 5 states that all agents prepare the contract to be signed. This is

possible since Bob and Carol receive the server's offer from Alice. Furthermore, any

decision function that needs to be executed to reach the decision for actual purchase is

shared by three agents and executed in cooperation. However, it is also possible for any

one agent to prepare the contract and communicate it to the others. Once the contract is

obtained either way, agents sign it with their shares of the private key for the chosen

algorithm as described previously. Step 6 says that Bob and Carol send their signatures

back to Alice, and in Step 7, Alice combines them to obtain the fully signed contract.

This means that combining the partial signatures takes place in the host where Alice

resides. This is because there is no trusted authority to ask for this computation. But for









the application under consideration, there is no need for it either, since there is no known

attack possible.

4.10 Using Limited-liability Keys and Public Key Certificates

Our multi-agent model provides a high level of security by making it difficult to

compromise all the agents, which together form an autonomous group. However, the

secret, which is a private key of the agent owner, is an extremely sensitive piece of

information. Revealing user's shopping preferences or losing electronic cash is certainly

undesirable, but in essence a part of our daily lives since we have just enough security to

protect these valuables. But a forged signature under a document may mean "anything"

and may not be tolerable or acceptable. So even a very small chance of the whole group

of agents being compromised may not be acceptable since the consequence of this

malicious action is revealing the private key of the user. Therefore we define two types of

public/private key pairs as follows.

Long-term public/private key pairs: These are the long-term keys, which are

created, registered and assigned to the user (who becomes the owner of the keys) by a

Certificate Authority (CA). The lifetime of these keys are again decided by the same

authority.

Limited-liability public/private key pairs: These are the short-term keys, which are

created by the very same user (owner of the keys). Since the creators of the keys are the

users themselves they also are the authority to decide the lifetime of the keys.

There are two limitations that can be imposed on the limited-liability keys. The first

one is the lifetime of the key and the second one is what can be done (i.e., signed) with

these keys. Both of these limitations can be flexible or restrictive and is up to the owner

of the keys. For example, the lifetime of a key may vary from a single MA mission,









which may be limited to a couple of minutes, to a total of a couple of days that spans

several different missions. Liability definition says what exactly can be signed with these

keys. For example, a typical definition may say that these keys can only be used in an m-

commerce transaction and the amount that could be involved in such a transaction cannot

exceed $500. The other type of limitation that can be imposed is the type of the

transaction. For example, it can be stated that, with these keys only one mobile phone,

one color printer or one DVD player purchase contract can be signed.

The problem with this scheme is the authenticity of this new pair of keys. One

possible solution would be to register this pair of new keys with a CA and obtain a

certificate, or ask the CA directly for a pair of new keys. Nevertheless, this solution does

not make much sense, since this introduces an overhead of obtaining a new key for every

single transaction from a CA, which could easily become unmanageable. Instead, the user

creates this key and a certificate for this key by using his/her long-term key. The idea is

that the user obtains only a single public key and a certificate for it from a CA. Using this

certificate and public key, it is possible for the very same user to create and use unlimited

number of other public keys. The key point here is that these new keys are certified by

their owners. That is, the user in essence becomes a CA for the agents he/she sends on

missions.

It may seem at first that the scheme explained in this section provides enough

security for the limited-liability private key. This is due to the fact that what can be

signed by this key is restricted by the certificate provided for it. However, it is not so for

two reasons. First problem is the same problem that the undetachable signature schemes

have as explained previously, which is the difference between the limitation of what can









be signed and what actually is signed. A certificate can only enforce what can be signed

with the key, for which it is issued. But in fact, it is necessary for agents to be able to

engage in transactions with the most favorable choices. For example, a certificate may

allow for a purchase of up to $500. However, this should not mean that the agent would

accept an offer of this amount. If the server's original bid is $300, then the server should

not be able to enforce the agent to involve in an agreement for the allowed full amount of

$500. The second problem is that an attack is possible by any host visited. Any such host

for example might learn the complete limited-liability private key from agent Alice, and

then can sign a contract to sell something. Also, even if the support agents are involved in

the decision function to be executed, this is not enough since a single agent who

possesses the complete key could be manipulated. In short, this scheme when used alone

could open a can of worms. Therefore, the limited-liability keys are protected by splitting

them up and giving them to members of a group of MAs. Their usage, on the other hand,

is protected by the certificate created by the user using the long-term key.

The complete protocol for using the certificates and limited-liability keys for agents

is given in Figure 4-4. In the protocol, P and S represent the long-term public and private

keys respectively andp and s represent the limited-liability keys. The protocol assumes

that user already has P and S. Note that P, S, p and s, are symbols for the private and

public keys, for example in the case of RSA, P andp indicate (E, N) and (e, n)

respectively. The certificate contains p and the description of the liability. Any document,

which is signed with s and therefore can be verified byp, should conform to this

description to be valid.









Note that a certificate chain that would also include CA's certificate for (P, S) rules

out the necessity for the server to connect the CA and ask for verification.

1. User creates (p, s) or uses a pre-computed pair of keys
2. User splits up s, using one of the techniques mentioned
3. User prepares a certificate and signs with S
4. Server uses P to verify the certificate and obtains the identity of the user and p
5. Agents sign the contract with their shares of s
6. Server verifies this signature using p
Figure 4-4. Limited-liability key protocol

Now let's look at what can and cannot be accomplished with these limited time and

liability keys and what can go wrong. The analysis involves three parties that can act

maliciously; agent owner, the host to which a signature is provided, and third parties,

which could presumably acquire the limited-liability private key. Since the private/public

key pair is arbitrary, meaning that they are neither created nor registered by a CA, the

host on which the transaction took place may sign a contract that states that the agent

purchased 500 mobile phones for the price of $100 each. Since the host also knows the

credit card information of the user, it can perform a transaction and bill the user's credit

card for this transaction. The solution to the dispute requires the proof of the user's

demand for this kind of purchase. But the certificate which is signed by user's long-term

private key pair states that the transaction amount may not exceed $500 and it is only

valid for a purchase of a single mobile phone. Therefore there is no way for the host to

prove such claim.

Now, suppose that a third party was able to compromise all the agents in a group

and therefore acquire the limited-liability key. Then this party could sign an arbitrary

contract on behalf of the user by masquerading as the user. In this case, however, it is not

possible to bind the user to this contract since there is no certificate signed by the user









using the long-term private key. So, such signed document is invalid because the user can

deny it rightfully.

Third attack involves a malicious user, and is known as non-repudiation problem.

The user cannot deny a contract that states a purchase demand that conforms what is

stated in the certificate signed by the user's long-term private key. This is what we expect

since this is the aim of the certificate and is completely legitimate. Also, the user cannot

deny the legitimacy of a contract by claiming that the contract was signed after the

limited-liability key had been expired. That is because agents are supposed to check

whether the expiration date and time has passed. On the other hand, as explained in the

previous paragraph, the user can deny any illegitimate contract signed by the limited-

liability key that does not conform to the certificate. Another similar attack might be

possible, if an attacker creates and uses a limited-liability key by also creating a fake

long-term key without registering this long-term key by any CA. Then the attacker

prepares a certificate for the limited-liability key using this fake long-term key. The last

step for the attacker is to let the agents engage in transactions and then deny their

existence. These transactions may or may not conform to the certificate prepared. So, the

merchants/sellers should always check the legitimacy of the short-term keys by checking

the certificates prepared for them, as well as the legitimacy of the certificates by checking

the long-term keys used to prepare them possibly consulting the CA, if not provided.

4.11 Practical Issues of Remote Digital Signing

In this section we examine the issues related with using the Remote Digital Signing

in practice. First we look at the issues related with the security level and robustness of the

multisignature schemes by discussing the recent theoretical advances in digital

signatures, their impact on implementations in practice and particularly on remote digital









signing. Then, we look at the broader picture of multiple MAs paradigm and discuss the

performance issues that might arise in practice and how to address them.

4.11.1 Probabilistic Signature Scheme and its Impact on Practice

Probabilistic Signature Scheme (PSS) has been proposed by Bellare and Rogaway

(1996). It is applied to the hashing but the signature generation is the same. The idea is to

mix the document to be signed with a random salt in a specific way and the result is a

better security proof. This is due to the fact that security of PSS can be tightly related to

the difficulty of inverting RSA. We refer the interested reader to Bellare and Rogaway

(1996) for details. As the name implies, PSS is probabilistic rather than deterministic,

which is the case for classical RSA commonly in use today. The scheme has practical

importance and has been adopted by the RSA Corporation as a standard (PKCS#1, 2002).

Unfortunately, the scheme is not applicable in environments where deterministic

signature generation is necessary. In our case, it is applicable to sequential signature

generation using RSA since signature generation is initiated by a single agent and

appropriate hashing is only performed by the same agent. The other agents (i.e., support

agents) therefore need not know the random salt value used and can apply their keys to

the signature function. However, parallel signature generation with RSA requires a

deterministic scheme since all the agents need to know or be able to generate the same

random salt. The issue is important since our main concern is to use standardized and

widely implemented and used schemes like RSA. The random salt value in PSS enhances

the security by providing a tighter security proof. However, in practice, randomness is not

critical to security (PKCS#1, 2002). In our case, parallel RSA signature generation is still

feasible by providing a fixed value to the agents or have them compute the same value

and use it when it is time to generate the underlying message digest to be signed.









Furthermore in our scheme, the lifetime of the keys and their applicability can be

extremely restricted due to the use of certificates issued for them. So, the probability of

forging the signatures is extremely low and it is difficult to justify the efforts to do so.

Some theoretical research results however lead us to question the probabilistic

schemes like PSS. Recently, Katz and Wang (2003) showed that an equally tight security

proof of PSS could be constructed in a deterministic way. The idea is to use a single bit

(0 or 1) instead of a random salt value when generating the hash value. This variant of

PSS may render the current proposed standardization of the original PSS obsolete, which

is not convenient in environments where random generation is not possible or is not

preferred as in the case with parallel signature generation presented.

4.11.2 Performance Considerations and the Big Picture

Remote digital signing is in fact a part a new computation paradigm of multiple

MA systems. Among many issues of this big picture, performance considerations deserve

specific attention since multiple agents introduces additional communication to the

classical single agent model. The immediate result follows as more communication

overhead to the underlying network and degraded performance observed by the user.

Network-awareness in general and specifically network distance estimation are hot

research topics and aims at assisting applications, which would benefit from being aware

of the underlying network characteristics and conditions. Multiple MAs are such an

application area where network-awareness as well as context-awareness, which also

addresses security considerations, is important. For example, choosing hosts to send the

agents randomly increases the security risk of conspiracies against them. So, hosts to be

chosen need to be in different administrative domains and should not have common

interests to alleviate this risk. The goal, therefore, is to find the best possible combination









of available hosts under the restrictions mentioned above, which are (in terms of network

distances) close to each other. This not only addresses the performance but also the

security since vulnerability of the agent communications over the network reduces. These

issues are the subject of following chapters.

One last remark on performance issue is the subtle difference between the

client/server paradigm and the MA paradigm in general, regarding user expectations. The

applications of the MA paradigm, which is in fact a special case of the multiple MAs

paradigm are not user-interactive as is the case for client/server systems. Users do not

expect immediate results from their MAs and it is in that aspect that constitutes the

foundation for enabling disconnected operation. Therefore, performance penalties should

be observed in a more relaxed fashion than it should be in the traditional client/server

computing.

4.12 Conclusion

Mobile commerce is a rapidly developing field of electronic commerce. Mobile devices

and wireless networks, which make the mobile commerce a reality, however are not

developing at the same pace. It can be expected that the limitations of these technologies

will be with us several decades from now. MAs are distinguished candidates to tackle this

problem. Although benefits offered by this technology are well understood by now,

especially in the mobile commerce field, security and interoperability are two main

concerns of this technology. It is also well understood that without proper security

mechanisms in place, MAs will not be accepted. So, advances in MA security area will

directly affect the future of mobile commerce applications.









This chapter carefully examines the implementation of remote digital signing,

which is a special case of computing with secrets in the public domain, within a larger

picture of supporting multi-agent computing. The solution approach is based on secret

sharing and the concept of protection as a whole. In addition to well-known

multiplicative and additive properties of the RSA, similar techniques with El Gamal

public-key cryptosystem are demonstrated to show their applicability in the MA systems.

Although threshold multisignature schemes fit well into the application, it may not be

feasible and even reasonable to provide the implementations of these schemes to the

MAs. Moreover, the advantage of the techniques we presented in this chapter is that they

use nothing but original signing and verification algorithms of RSA and DSS, which are

well known and widely used. In this sense, these simple schemes address the ubiquity in

a large scale MA execution environment like the Internet.

The MA security problem is not limited to signature generation, however. In fact,

signing a document is supposed to be a part of an MA mission. A complete solution to

the problem of protection against malicious hosts is still to be addressed in our future

work. However, as we have presented in this chapter, even the most challenging part of

the problem, computing with secrets by MAs, is feasible using the multi-agent model.

It is shown that both parallel and sequential signature generation schemes are

possible. There are important properties of each scheme. The former one provides data

integrity since each agent in the group signs the original document, therefore can check

its integrity. However, in this scheme there is no confidentiality for the document to be

signed. The latter scheme provides data confidentiality only if signing process begins at

the server, where the master agent is being executed. The other hosts, where the support









agents are running, can not see the document in clear, assuming the partially signed

documents have enough strength against cryptanalysis. The schemes presented in this

chapter therefore address authenticity rather than data confidentiality.

In this chapter, while applying information dispersal to mobile agents to

accomplish digitally signing contracts in the public, our tacit assumption was that we

could position these agents in the hosts over the network; this positioning as well as the

mission as a result of it would be feasible. In the next chapter we examine this

positioning problem to show that it is feasible to identify the best host locations to realize

the information dispersal with multiple mobile agents.














CHAPTER 5
A NETWORK POSITIONING ARCHITECTURE FOR MOBILE AGENTS

5.1 Introduction

Applications that can benefit from being aware of the underlying topology and the

network distance information are numerous. For example, in a web caching system,

clients of the system may choose the best location among the alternatives to obtain the

cache copies. Similarly, the location information is obviously useful in placing

WWW/FTP mirror sites in different areas on the network. In such a replica system,

clients may need an automated mechanism to choose the best mirror site based on

topology information. The problem of addressing this requirement for such applications

is known as the server selection problem. Another important application area is in the

design of content addressable networks (Ratnasamy et al., 2001) and overlay networks

(Stoica et al., 2001). These systems require transformation of logical network topologies

from an underlying physical network. In general, any content provider orpeer-to-peer

(p2p) file sharing facility (i.e., Napster and Gnutella) requires topology information for

the best performance, which otherwise may not be observed. Many other topology-aware

applications have been explored in literature (Ratnasamy et al., 2002).

Different from the applications described above, our interest in developing a

network positioning model came from the need for supporting a multiple mobile agent

system.









The proposed positioning model is a p2p coordinate-based system, which maps a

physical host location to logical coordinates for efficient on-the-fly logical distance (e.g.,

communication delay) estimation between any two hosts in the system.

5.2 Related Work

Much like time services in distributed systems, distance services can be provided

by some servers or obtained collaboratively by some participating hosts. The IDMaps

(Francis et al., 2002) is an example of the former case. This approach uses triangulation

heuristics combined with a centralized, client/server architecture.

Examples of the latter case are the coordinate-based Global Network Positioning

(GNP) (Ng & Zhang, 2002), the Lighthouse (Pias et al., 2003) and the inning

(Ratnasamy et al., 2002) approaches. The GNP and inning strategies use the concept of

landmarks, which are introduced by Hotz (1994). In GNP, coordinates are computed by

modeling the Internet as a geometric space. Some hosts in the system are identified as

landmarks. These landmarks first measure their distances to each other and then compute

their coordinates by minimizing the error between the measured and the computed

distances (see Step 4 in Section 5.3.1 for details).

This results in approximate distances as represented by the coordinates among

landmarks. An ordinary host can measure its distance to these landmarks and use the

landmarks' coordinates to compute its own with the same minimization technique. Figure

5-1 illustrates two hosts A and B, which compute their coordinates using the global

landmarks L1, L2 and L3. From there on, A only needs to ask B for B's coordinates to

obtain the distance to B. The GNP is a p2p architecture as oppose to the IDMaps' central

servers approach.









L2




Li
B








L3
Figure 5-1. Global network positioning model (GNP)

In the inning strategy, rather than utilizing coordinates, hosts measure their actual

distances to the landmarks and place themselves in a bin based on the sequence of sorted

distances to the landmarks. The idea is that hosts, which are close to each other relative to

the other hosts, will have similar sequences and therefore will be placed in the same bin

or in a similar one. The inning strategy assumes that fine-grained reduced errors

between measured and predicted distances do not have a considerable effect on the

application performance. As a result it is possible to make distance comparisons by using

less information namely, only a sequence of estimated distances to a set of landmarks.

However, the approach is not as flexible as the coordinate-based approaches. This is due

to the fact that in the inning strategy bins are tightly bound to the landmarks, whereas in

coordinate-based approaches the coordinates and the landmarks are relatively loosely

coupled.

The Lighthouse approach (Pias et al., 2003) shares the same idea of eliminating the

landmarks to achieve scalability, as the proposed approach in this chapter. The scheme

uses a transformation matrix maintained by the hosts for making conversions between the









global and the local bases. However, the approach does not address the practical

implications, namely, it is not clear how the global basis is formed and the definition of

the local basis is not consistent with the positions of the hosts since the hosts are picked

arbitrarily. Moreover, every host that wants to participate needs to create a local basis.

While it is also not clear how to find a host that is currently participating in the system, it

does not bring any advantage over GNP in terms of accuracy of the distances.

The results of GNP study (Ng & Zhang, 2002) show that, the coordinate-based

approach provides better estimation of distances than the IDMaps. It is also more

accurate and robust due to its p2p architecture when compared to IDMaps. However, this

approach has its own drawbacks. First, the landmarks must be globally distributed to the

entire Internet to accurately measure the distances between two arbitrary distant hosts.

But the distance estimation between two local hosts is biased with the coordinates of the

widespread landmarks, which are not local to the given two hosts. Second, these

landmarks are central points of failure and may become target of attacks. Third, where to

locate the landmarks, how many landmarks there should be and how/where to move the

landmarks or add new ones as the Internet topology changes and grows are important

open scalablity problems. Finally, there is a security concern of the system. The authors

point out that (Ng & Zhang, 2002) this system may not be suitable in an uncooperative

environment since there is nothing to prevent a host from lying about its coordinates for

being chosen or not chosen depending on the application. To address these shortcomings

we propose the coordinate-based Pure Peer-to-Peer Network Positioning (Triple-P NP or

TPNP) architecture, which completely eliminates the landmarks and the problems they

introduce.








5.3 TPNP Approach

The idea of TPNP is similar to the basic principle of dynamic distance vector

routing, except that hosts do not need a global picture (i.e., a routing table) of the

network. A host that is interested in participating the TPNP system first discovers the

nearby hosts that are already in the system to use them as reference hosts, which replace

the landmarks for the host in question. Then, the host contacts these references to

compute its own coordinates (see Section 5.3.1). Figure 5-2 illustrates the same hosts A

and B's (from Figure 5-1) coordinate computation process. A uses three other ordinary

hosts C, D, and E already in the system, and B uses F, G, and H locally. These hosts,

which are already in the system, are not shown in Figure 5.1 for clarity. As shown host C

may have used three other locally positioned ordinary hosts for computing its own

coordinates.

(L2)

0 0
F
(L 1)




D G H




(L3)
E
Figure 5-2. Local network positioning model (TPNP)

Unlike GNP or any other global positioning system local measurements as of

TPNP are likely to give more accurate results between local hosts. There are two