Ситуирани агенти

"Ситуиран агент" е контролер, разположен в динамична, сложна и относително неструктурирана среда. Ситуирани агенти могат да бъдат хардуер или софтуер( или и двете). Софтуерът се включва почти винаги, а хардуер е необходим , ако средата е физична. В такива случаи хардуерът има ролята на интерфейс, въпреки че може и да участва в изчисленията. Типичните хардуерни ситуирани агенти включват подвижни роботи , автономни подводници, интелигентни стаи и други подобни.

Чисто софтуерни ситуирани агенти се намират във виртуалните светове. Средата на софтуерно базираните ситуирани агенти е логическа, а не физическа. Интерфейсът се състои от комуникациоони интерфейси на логическата среда, кочто е динамична, непредвидима, голяма и сложна. Ситуираните софтуерни агенти включват балансьори на натоварването в телефонните мрежи и витруалните характери в игрите.

По принцип агентите се опитват да постигнат няколко цели чрез взаимодействие с околната среда чрез техните сензори и манипулатори. Често целите са конкурентни една на друга и агентът трябва сам да решава конфликтите. Това е трудна задача. Сложната и динамична природа на средата определя ,че агентът:

• Няма пълен контрол върху средата.
• Няма капацитет за изграждане на пълен модел на средата.

• Не притежава пълна информация за средата.

• Не може напълно да вярва на информацията , която има, защото тя е неопределена, неточна, стара или съдържа шум .

Агентът трябва да действа последователно за постигане на целта си, неговите действия трябва го водят постепенно до целта ( например мобилен робот да достигне определено положение в средата). От друга страна агентът трябва да реагира адекватно на неочаквани събития, които се случват в средата( например ако се появи неочаквано препятствие по пътя на робота). Но обикновенно е невъзможно да се изградят правила за противоречиви цели като тези ако няма идеални познания и планиране. За разрешаване на този проблем дизайнерите на ситуирани системи трябва да имат инструменти за представяне на реактивни правила като последователни действия в тяхните планове.

Обикновенно ситуираните агенти нямат цялата информация, от която се нуждаят, затова те трябва да действат за събиране на информация( като противоположност на действия за достигане на първоначалните цели).

И на последно място използването на инструкции в зависимост от ситуацията включва проверяване дали прилагането на тези инструкции има смисъл ( заюитена интерпретация) и как те се вписват в текущата ситуация( контекстно зависима интерпретация).

Тези проблеми получиха необходимата доза интерес след изместването на фокуса от създаването на нетелесни мозъци( например шахматни програми) към създаването на по-предметни форми на интелект. Ефектът от тази промяна е, че някои области от ИИ се препокриват с апекти от програмирането на embed системи.

В много области се прилагат и тестват техники от дизайна на ситуираните агенти. Вероятно най- познатата област е тази на подвижните роботи. Марсоходът на NASA е най- обсъжданият (полуавтономен) ситуиран агент. Но има и много по-земни приложения- балансиране на натоварване на мрежа, интелигентни стаи, интелигентни изкуствени създания за виртуални светове и много други.

В тази статия ще покажа подход за програмиране на реактивни ситуирани агенти, който е азирана на паралелни функционални дървета с решения. В процеса на работа ще представя библиотеката на C++ "InSitu" и система за ситуирани агенти , които се справят с изложените по-горе проблеми и изисквания.

В моя подход при проблема за програмиране на реактивни ситуирани агенти първо създадох реактивна система на C++ и след това създадох C++ класове за добавяне на функционалност за последователност, активни възприятия и използване на ситуирани инструкции. Резултатът беше InSitu. Повечето среди за embed системи са проектирани по друг начин - те изпозват последователен програмен език ( като C++) и добавят нишки, прекъсвания и обработка на събития за достигане на реактивност .


Рене е доктор по компютърни науки в лабораторията по Изкуствен Интелект в Цюрихския университет, Швейцария.

HMAC алгоритъм

Установяването на съобщенията е процедура, която позволява комуникиращите страни да проверят дали получените съобщения са автентични. Трябва да се провери дали не е променяно съдържаниео на съпбщението и дали източникът е автентичният. за извършване на проверка на съобщенията широко се използва техниката Message Authentication Code (MAC). Разновидност на MAC алгоритъма се използва като Интернет стандарт при голямо разнообразие от приложения - HMAC, съкратено от "Keyed-Hashing for Message Authentication."(хеширан ключ за достоверност на съобщенията). HMAC беше представен в "Keying Hash Functions for Message Authentication," от M. Bellare, R. Canetti и H. Krawczyk през 1996 година.

MAC

MAC алгоритмите включват използването на таен ключ за генериране на малък блок данни, познат като "message authentication code," , който се добавя към съобщението. Тази техника предполага, че двете комуникиращи страни, да ги наречем A и B, споделят таен ключ K. Когато A има съобщение за изпращане до B, пресмята кода за удостоверяване като функция от съобщението и ключа. Съобщението и кода се изпращат на получателя. Получателят прави същото изчисление за полученото съобщение, използвайки същият таен ключ и получава някакъв код. Полученият код се сравнява с пресметнатият.

Като предполагаме, че само изпращачът и получателят знаят тайния ключ, еднаквост на получения и изчисления код тогава:

1. Получателят е сигурен, че съобщението не е променяно. Ако някой злонамерено промени съобщението, но не промени кода изчисленият от получателя код ще се различава от получения. Но тъй като предполагаме, че никой атакуващ комуникацията не знае тайния ключ, той не може да промени кода, така че да отговаря на промененото съобщение.

2. Получателят е сигурен, че съобщението е от очаквания източник. Тъй като никой друг не знае тайния ключ никой друг не може да състави съобщение с правилен код.

3. Ако съобщението съдържа последователно число (каквито се използват при X.25, HDLC и TCP) получателят е сигурен че последователността е правилна, защити не може злонамерено да се промени числото за последоватесност.

Могат да се използват различни алгоритми за генериране на кода. Националното Бюро по Стандартите (NBS) в публикацията DES Mode of Operation (http://www.nist.gov/itl/div897/pubs/fip113.htm) препоръчва използването на DES алгоритъм. Алгоритъмът DES се използва за генериране на криптирана версия на съобщението и последните битове на криптирания текст се използват за код. Нормално се използват 16 или 32 бита за код. HMAC е по-ефективен и с нарастваща популярност алтернатива.

Описаният по-горе процес е подобен на криптиране. Има разлика е това, че алгоритъма за удостоверяване може да е необратим, както е необходимо при декриптиране. Това е така, защото поради математическите свойства на удостоверяващата функция, тя е по-трудно да бъде разбита от криптираща функция.

HMAC

В последните години се увеличи интереса в разработването на производни на MAC с криптографски хеш код като MD5, SHA-1 или RIPEMD-160. Мотивацията за това е:

• Криптографските хеш функции по принцип се изпълняват по-бързо отколкото симетричните шифри като DES.
• Библиотеките с код за криптографските хеш функции са широко разпространени.

• Няма рестрикции за криптографските хеш функции, докато симетричните шифри са забранени да се ползват дори и за MAC.

Хеш функции като MD5 не са създадени за използването им като MAC и не могат да се използват пряко за тази цел, защото те не използват таен ключ. Имаше различни предложения за вмъкване на таен ключ в съществуващите хеш алгоритми. Най- голяма подкрепа получи HMAC. HMAC беше избран като задължителен за IP Security и се използва в други Интернет протоколи, като Transport Layer Security (TLS, скоро заменен от Secure Sockets Layer) и Secure Electronic Transaction (SET).

HMAC- Цел при Дизайн

Целите на дизайна, които RFC 2104 задава за HMAC съдържат:

• Да се използват без промяна съществуващите хеш функции. В частност това са хеш функции, които са добре представени в софтуера, чиито код е свободен и широко разпространен.
• Да позволява лесна замяна на вградената хеш функция в случай на откриване или налагане на по-бърза или по-сигурна хеш функция.

• Да запази първоначалната производителност на хеш функцията, без да я намалява забележително.

• Да използва и обработва по прост начин ключовете.

• Да има добре разбран криптографски анализ на здравината на удостоверителния механизъм, базиран на обосновани предположения за вградената хеш функция.

Първите две изисквания са важни за приемливостта на HMAC. За HMAC хеш функцията е черна кутия. Това има две ползи. Първата е , че съществуваща реализация на хеш функция може да се използва като модул при реализиране на HMAC. Основата на HMAC кода е предварително пакетирана и готова за употреба без изменения. Втората е , че замяната на дадена хеш функция в реализация на HMAC е просто премахване на текущия модул и слагане на новия. Това може да се направи ако се изисква по-бърза функция. Важно е , че ако сигурността на вградената хеш функция е разбита, сигурността на HMAC моеже да се възстанови чрез проста замяна на вградената хеш функция с по-сигурна(например замяна на MD5 с SHA-1).

Последната цел в по-горния списък е всъщност главното предимство на HMAC спрямо останалите предложени хеш-базирани схеми. HMAC може да се докаже като сигурен, ако вградената хеш функция има обоснована криптографска здравина.

Алгоритъмът HMAC

Където

H- вградена хеш функция;M- съобщението( включително отместването, заради хеш функцията) ; Y_i- i-тия блок от M ; К+- допълнен с нули отляво до достигане на дължината на b; ipad- 00110110( 36 шестнадесетично) повторено b/8 пъти; opad- 01011100( 5C шестнадесетично ) повторено b/8 пъти.

HMAC може да се представи чрез израз

С други думи:

1. Добавяме нули отляво на K до достигането на низ с дължина b K⁺ (например ако K е с дължина 160 бита и b = 512 K ще се допълни с 44 нулеви байта 0x00).

2. XOR (побитово зключващо или OR) K⁺ с ipad за генериране на b битов блок S_i.

3. Добавяме M към S_i.

4. Прилагаме H върху потока, генериран в стъпка 3.

5. XOR K⁺ с opad за генериране на b битов блок S_o.

6. Добавяме хеш резултатът от Стъпка 4 към S_o.

7. Прилагае H върху потока, генериран в стъпка 6 и извеждаме резулатът.

Забележете , че XOR с ipad дава като резултат промяната на половината битове на K. По същата логика XOR с opad дава като резултат промяна на половината от битовете на K,но на различни битове. В крайна сметка с преминаването на S_i и S_o през компресиращата функция на хеш алгоритъма ще имаме два псевдослучайни ключа от K. При дълги съобщения HMAC трябва да се изпълни за приблизително същото време като вградената хеш функция.

Уйлям е консултант, лектор и автор на книги за комуникации и компютърни мрежи.