Модель безопасности на основе мультиагентной системы

Архитектура МБМА.

Предлагается мультиагентная архитектура под названием модель безопасности на основе мультиагента (МБМА) для обслуживания процессов безопасности со стороны отправителя и получателя. Агенты интегрированы в модель и добавлены еще два агента: (1) Агент сервера (Server Agent, SvA): находятся на стороне сервера для управления процессом аутентификации и другими запросами от агентов, и (2) Агент расшифровки (Decrypt Agent, DA): выполняет процесс дешифрования со стороны получателя.

На рисунке 1 показана предлагаемая модель МБМА. Со стороны отправителя Интерфейсный агент (IA) отправляет идентификатор пользователя ID, пароль и IP-адрес отправителя в SvA для аутентификации. При этом предполагается, что сертификаты всех пользователей были обменены заранее. Администратор безопасности в организации может отвечать за управление сертификационными обменами. Агент сервера (SvA) аутентифицирует пользователя, и если отправитель авторизован, он отправляет результат аутентификации (действительный / недействительный), а также список IP-адресов других пользователей, которые обменялись сертификатами с отправителем.

Затем агент IA получает данные и адрес получателя (ей) от отправителя и передаёт его Агенту организатора данных (DOA). DOA организует данные в файл или открытый текст (данные пользователя в дальнейшем будут называться открытым текстом) и предоставляет как открытый текст, так и адрес для Многозадачного агента (MTA). Уровень безопасной коммуникации представляет место, где выполняются процессы защиты. На этом уровне MTA отправляет запрос на отправку сообщения предполагаемому получателю (ям). Крипто-агент (cA) готовит всю необходимую информацию для процессов безопасности и определяет соответствующий уровень для связи, как описано в спецификации ММК (см. ниже). Агент установки (SUA) создается крипто-агентом cA для применения криптографических протоколов. Мобильный агент (MA) создаётся образцом SUA для отправки данных получателю перемещением на узел получателя.

{Рисунок 1}

Рисунок 1. – Архитектура модели безопасности на основе МАС

Со стороны получателя Агент приёмник коммуникаций (CLA) ожидает любой входящий запрос, чтобы отправить сообщение от MTA. Если есть запрос, CLA создаёт Агента получателя (RA), чтобы принять входящего MA. MA создаёт образец Агента организатора данных (DA) со стороны получателя для выполнения процессов дешифрования. На стороне сервера SvA сравнивает идентификатор и пароль с тем, который содержится в базе данных. Если они совпадают, SvA сохраняет IP-адрес пользователя.

Модель МБМА поддерживает реализацию ММК и обеспечивает довольно общую архитектуру, которая может использоваться в доменах любого типа. Агенты используют автономные, расширяемые, интерактивные и мобильные характеристики и способны координировать и взаимодействовать друг с другом для достижения общей системной цели.

Каждый агент способен выполнять определённые конкретные задачи. Агент может быть расширен или смоделирован с использованием характеристики расширяемости, когда его навык необходим для достижения общей цели системой. Например, для каждого контакта получателя создается экземпляр SUA для применения необходимых криптографических протоколов. DA создаётся только тогда, когда выполняется условие для дешифрования зашифрованного сообщения.

Агенты в МБМА обслуживают и автоматизируют процессы безопасности с минимальным вмешательством пользователя. Модель МБМА использует подход мобильного агента. Он используется для передачи защищённых данных получателю. Мобильный агент подходит для ситуации, когда агент имеет только частичные ресурсы на домашней платформе, а остальные ресурсы расположены на стороне получателя. В нашем случае для мобильного агента требуется закрытый ключ получателя, который доступен только на узле получателя для дешифрования защищенных данных. Мобильный агент надёжен, в том смысле, что если платформа назначения завершена, пока агент ещё здесь, агент может предпринять необходимые действия, такие как перенастройка или прекращение его действий ^[1]. Он может отправить уведомление на домашнюю платформу о своей ситуации и прекратить, если потребуется.

Уровни коммуникаций.

Для связи между двумя пользователями, например, “Доктор” и “Медсестра”, идентифицируется уровень связи или com_layer. Com_layer относится к пяти уровням связи в модели ММК, которая определяет механизмы безопасности и длины симметричных ключей, которые будут применяться к информации в конкретном сеансе связи. Com_layer может быть определён с использованием значения уровня использования по умолчанию или L0, назначенного каждому пользователю, например:

• Пациент, доктор, и медсестра: L0 = Уровень 1

• Медработник и система координатор: L0 = Уровень 2

• Социальный работник: L0 = Уровень 3

• Системный администратор: L0 = Уровень 4.

Присваивание L0 основано на чувствительности данных, которые может иметь каждый пользователь. Меньшее значение L0 присваивается пользователям, которые передают чрезвычайно важную информацию, в то время как большее значение L0 присваивается пользователям, которые передают информацию с низким уровнем секретности. L0 получается с использованием сертификата пользователя. Каждый сертификат на сервере имеет имя с именем пользователя и уровнем по умолчанию. Следовательно, уровень по умолчанию для пользователя может быть получен путём извлечения значения из сертификата.

Ниже описаны правила определения com_layer для связи между отправителем и получателем:

1. Если L0 для отправителя и получателя одинаковы, тогда com_layer для этой коммуникации будет L0 получателя.

2. Если L0 для отправителя больше, чем у получателя, тогда com_layer для этой связи является L0 отправителя.

3. Если L0 для отправителя меньше, чем у получателя, тогда com_layer для этой связи является L0 получателя.

Таким образом, com_layer можно идентифицировать, сравнивая оба L0 отправителя и получателя. Один с большим значением будет выбран как com_layer. Например, в связи социальный работник (SW) (L0 = 3)Доктор (L0 = 1) com_layer будет Уровень 3. Если оба L0 одинаковы, этот L0 будет использоваться как значение com_layer. После идентификации com_layer можно определить механизмы безопасности для связи, то есть, нужна ли коммуникация для защиты данных или безопасности канала, или как безопасность данных, так и канал. Com_layer ассоциируется с длиной алгоритмов шифрования с симметричным ключом:

Уровень 1: длина ключа = 193-битный ключ и больше.

Уровень 2: длина ключа = 129 – 192-битный ключ (беспроводной: ключ 80- 192-бит).

Уровень 3: длина ключа = 112 – 128-битный ключ.

Уровень 4: длина ключа = 80 то менее, чем 111-битный ключ.

Спецификация ММК.

Спецификация ММК хранит спецификации безопасности, которые описывают информацию о шифровании симметричного ключа. Спецификация ММК хранится в виде кортежа, содержащего четыре параметра:

<Алгоритм, длины, режим, заполнитель>

Алгоритм, длины, режим и заполнитель описывают типы алгоритмов симметричного ключа, длины ключа, режимы шифрования и заполнение шифрованием соответственно.

На рисунке 2 приведен пример набора спецификаций ММК. Примерами алгоритмов, которые в настоящее время можно использовать, являются AES ^[2], 256-битный и 192-битный, представляющие Уровень 1, Triple-DES 168-бит ^[3] для Уровня 2, 128-битный AES, Twofish 128 бит ^[4], 128-битный TEA ^[5] и Blowfish 112-бит ^[6] представляют Уровень 3, а Blowfish 80-бит представляет Уровень 4. Режим шифрования – (CBC) и дополняется заполнением PKCS7. Алгоритм шифрования выбирается случайным образом агентом, после того как com_layer был рассчитан как часть процесса коммуникации.

{Рисунок 2}

Рисунок 2. - Пример спецификации ММК

Любой алгоритм безопасности может быть добавлен в МБМА до тех пор, пока он соответствует спецификации безопасности в модели ММК. Метод выбора представленных здесь алгоритмов более гибок по сравнению с методом в существующих технологиях ^[7]. МБМА пытается обеспечить различные уровни безопасности для различных типов связи через ММК, что является противоположностью статической реализации механизмов безопасности в существующих технологиях.

Контроль над данными отправителем.

МБМА фокусируется на механизме управления тем, как отправитель может безопасно передавать данные получателю, сохраняя при этом контроль над данными. “Сохранение контроля” над данными может быть описано как:

1.Если сообщение, переданное мобильным агентом отправителя, захвачено злоумышленником, злоумышленник всё еще не может восстановить открытый текст.

2. Получатель или любая другая третья сторона не должна знать детали процессов дешифрования для восстановления открытого текста.

Один из способов, с помощью которого отправитель может получить контроль над данными, состоит в том, чтобы сохранить часть требований к процессам дешифрования в секрете, например, часть кода агента или параметры, используемые для дешифрования. Симметричный ключ K используется для шифрования открытого текста. Этот ключ и информация о ключе (который хранится в спецификации ММК) хранятся у отправителя до тех пор, пока он не узнает, что мобильный агент, который перешел на узел получателя, нуждается в этом.

Маркер, который является зашифрованным случайным числом, переносится мобильным агентом на хост получателя. Он используется как механизм “домашнего телефона” ^[8], где агент отправляет маркер обратно отправителю. (Согласно авторам ^[7], механизм домашнего телефона может использоваться мобильным агентом для связи с отправителем либо для передачи данных отправителю, либо просто использоваться как метод для отправки отправителю состояния агента.) Это позволяет агенту указать отправителю, что ему нужна информация, хранящаяся на стороне отправителя, для процессов дешифрования.

МБМА реализует механизм управления, используя мобильность и расширяемость агентов. В механизме 1 ММК (безопасность данных) и изменяем основные этапы криптографических протоколов, чтобы адаптироваться с помощью МБМА. Два симметричных ключа (K1 и K2) используются (вместо одного ключа) в процессах безопасности. Рисунок 3 описывает пошаговые процессы для механизма управления.

Рисунок 3. - Управление контролем над данными

(1) Отправитель представлен агентом отправителя. Он шифрует открытый текст с помощью K1, чтобы получить зашифрованный текст. Код агента, который имеет возможность расшифровать зашифрованный текст, зашифровывается с помощью K2. Генерируется маркер T, который переносится мобильным агентом (MA). MA отправляется при передаче защищенных данных, содержащих зашифрованный текст, код зашифрованного агента, K2 и T. K1 хранится в секрете на стороне отправителя.

(2) На стороне получателя K2 совместно используется агентом получателя, так что агент может использовать его для дешифрования кода, а затем использовать код для дешифрования зашифрованного текста. Однако ключ для дешифрования (K1) и информация о ключе (длина ключа, режим и отступы) хранятся в секрете на стороне отправителя. В этом случае маркер отправляется обратно агенту отправителя, чтобы получить необходимую информацию.

(3) После получения T агент отправителя отправляет секретную информацию относительно K1 в MA, а затем выполняется процесс дешифрования для извлечения открытого текста.

K1 и K2 могут быть привязаны к любым типам алгоритмов с длиной ключа в соответствии с ММК. Эти шаги будут подробно описаны в следующем подразделе.

Механизм безопасности в МБМА

Первоначально используется связь между агентом отправителя и агентом получателя, который использует мобильный агент для переноса сообщения со стороны отправителя на сторону получателя (рисунок 3). Затем модифицируется Механизм 1 (Безопасность данных), чтобы адаптироваться к парадигме мобильного агента и реализовать предлагаемый механизм управления в МБМА. Код агента, который имеет функцию расшифровки зашифрованного текста, обозначается как Cd. Для объяснения процессов безопасности будут использоваться следующие обозначения:

- открытые и закрытые ключи получателя: (pubKr, privKr);

- открытые и закрытые ключи отправителя: (pubKs, privKs);

- симметричные ключи: K1, K2;

- одноразовый секретный и открытый ключ: (Ks, Kp);

- простой текст: P;

- хеш-функция Р: Н(Р);

- зашифрованный текст: C;

- сигнатура: S;

- код агента: Cd;

- хеш-функция Cd: H(Cd);

- случайное число: Rand;

- маркер: T;

- информация, извлеченная из спецификации ММК: mlc.

Шаги, предпринятые агентом отправителя

1. Принимает сертификат получателя и извлекает pubKr.

2. Вычисляет com_layer для сообщения отправителя и получателя, чтобы получить mlc.

3. Создаёт два симметричных ключа (K1, K2) согласно mlc.

4. Шифрует P с K1 для создания зашифрованного текста

C = E(P)K1.

5. Генерирует Rand и шифрует его с помощью K1 для получения T, который будет переноситься MA.

Агент отправителя будет сохранять K1 до тех пор, пока T не будет получено.

T = E(Rand)K1.

6. Формирует одноразовый секретный и открытый ключ (Ks, Kp). После того, как Т получен, Кp используется для шифрования информации, которая хранится для дешифрования процессов. Соответствующий Kp будет вложен в Cd и отправлен к узлу получателя, чтобы использоваться для дешифрования. При этом Генерация (Kp, Ks) выполняется один раз за сеанс связи. Эти ключи будут удалены после завершения сеанса связи. Это делается для того, чтобы избежать использования третьими лицами Kp (которые могут быть получены с узла получателя) в следующих сеансах связи.

7. Принимает Cd и создаёт .jar файл. (Архив файлов Java на http://java.sun.com/javase/6/docs/technotes/tools/windows/jar.html)

8. Записывает файл .jar (Cd) с privKs для создания сигнатуры S, который используется для проверки того, что Cd принадлежит отправителю.

S = E (Cd) privKs

9. Шифрует Cd, S и Т с К2 для получения кода шифра.

Шифр-код = E(Cd, S, T)K2.

Подпись должна быть зашифрована, поскольку самозванец, которому также доверяет получатель, может удалить S, добавить свою собственную подпись, взять данные агента и добавить его к своему агенту. Затем этот агент будет отправлен получателю без отправителя или получателя, зная, что агент на самом деле происходит от самозванца. Это описано как атака в ^[9].

10. Чтобы только агент получателя мог получить K2, он шифруется с pubKr вместе с H(Cd) для получения ключа шифрования.

Шифр-ключ = E (K2, H (Cd)) pubKr.

Со стороны получателя новый H(Cd) может быть позже вычислен из Cd на шаге (9), и сравните его со значением в Шифр-ключ, чтобы проверить, является ли Cd действительным и не нарушен.

11. Сохраняет C, Шифр-код и Шифр-ключ в файле. Устанавливает соединение SSL, если это необходимо для безопасности канала.

12. Закончив подготовку сообщения, агент отправителя создает экземпляр MA для переноса сообщения на узел получателя.

13. Ожидает Т от МА. Как только он будет получен, формируется ключ хэша, являющийся информацией, которая должна быть передана MA и содержит H(P), K1 и mlc.

Хэш-ключ = E (K1, MLC, H (P))Ks.

Шаги, предпринятые мобильным агентом

Мобильный агент переносит сообщение на узел получателя, и там он общается с агентом получателя. Ниже описываются связи между MA и агентом получателя:

1. МА делает запрос на обработку сообщения.

2. Получает результат от Агента получателя, указывающего, что оба Cd и S являются “Действительными” / “Недействительными”. Если получено сообщение “Недействительными”, отправляет отчёт агенту отправителя и завершает работу.

3. Если оба действительны, МА делает запрос на подпись Т.

4. Отправляет подписанное Т обратно агенту отправителя.

5. Получает Хэш-ключ от агента отправителя и неповрежденный Cd.

6. Выполняет запрос на выполнение Cd.

7. Хэш-ключ и Шифр-текст передаются в Cd для процессов дешифрования.

Шаги, предпринятые агентом получателя

Агент получателя будет выполнять коммуникации с MA и Cd в процессе дешифрования сообщения.

1. Ждёт любого запроса на обработку сообщений из МА.

2. После приёма сообщение разделяется на Шифр-текст, Шифр-код и Шифр-ключ.

3. Получает privKr, чтобы расшифровать Шифр-ключ и получить K2 и H(Cd).

D (Шифр-ключ) privKr = K2, H(Cd).

4. Использует K2 для дешифрования Шифр-код для получения T, S и Cd.

D (Шифр-код) K2 = T, S, Cd.

5. Проверяются S, и Cd:

а. Проверить S против Cd, используя pubKs отправителя.

б. Пересчитать H(Cd) из Cd в 4 и сравнить его с H(Cd) в 3.

6. Если S и H(Cd) действительны, отправляет отчёт в МА.

Если один или оба показателя недействительны, отправить отчёт в МА и прервать текущий процесс.

7. Подписать Т, когда запрос сделан из МА.

8. Когда принимаются открытый текст P и H(P), пересчитать H(P) и проверить, не искажён ли P.

9. Отправляет и сообщает Cd, является ли P “Действительным” / “Недействительным”.

10. Если P действителен, сообщает получателю.

Шаги, предпринимаемые Cd

1. После выполнения Cd расшифровывает Хэш-ключ, используя Kp, чтобы получить H(P), симметричный ключ K1 и mlc.

D (Хэш-ключ) Kp = Н (Р), К1, MLC.

2. Загружает и воссоздает K1 с mlc для дешифрирования зашифрованного текста, C.

3. Расшифровывает C, чтобы получить P.

D(С) К1 = Р.

4. Отправляет RA сообщение о P и H(P), чтобы RA мог пересчитать хэш и проверить текст.

5. Прекращает работу.

Преимущества контрольного механизма.

Сохраняя K1 в секрете, отправитель имеет преимущества получения контроля над данными, переносимыми MA. Это связано с тем, что получателю или любой третьей стороне не нужно знать о деталях ключа шифрования. Несмотря на то, что злоумышленник мог перехватить Хэш-ключ, пришедший от агента отправителя, злоумышленник всё равно не может восстановить открытый текст, поскольку ключ к расшифровке Хэш-ключ, который является Kp, находится на узле получателя. Кроме того, Kp является одноразовым, который создаётся только один раз при общении. Kp и соответствующие Ks будут удалены после завершения сеанса связи.

Ещё одним преимуществом для отправителя является то, что при получении и проверке маркера агент отправителя знает, что МА был правильно выполнен на узле получателя, потому что правильный маркер, который был восстановлен, означает, что МА получил правильные ресурсы на стороне платформы получателя (которая в данном случае является личным ключом получателя). Таким образом, доступ к ресурсам на узле получателя не запрещается. В этом случае агент получателя должен предоставить свой закрытый ключ для дешифрования ключа шифрования и подписи T.

Для агента получателя, с другой стороны, он не должен быть отягощен деталями процесса расшифровки открытого текста. Требуется только предоставить его закрытый ключ и аутентифицировать MA. Он может проверить, что MA действительно происходит от узла отправителя, проверяя подпись и целостность кода агента (путем проверки как S, так и H(Cd)). Если оба значения действительны, то сообщение и агент действительно поступают от доверенного отправителя. Кроме того, он может проверить, не нарушен ли открытый текст, вычисляя новый хэш-код и сравнивая его с полученным от агента.