ATM Security
Начало
Вверх

 

Реферат

по курсу

"Системы и сети связи"

"Обзор служб безопасности сегмента пользователя ATM"

 

Реферат подготовлен на основе ATM Security Specification Version 1.0. В нем дается обзор служб безопасности сегмента пользователя ATM, используемых алгоритмов и протоколов, а также дается общая схема организации безопасной связи.

Составил: Слушатель 4 курса

Реферат закончен: 26.12.2000

 

1.Введение

2. Службы безопасности сегмента Пользователя

2.1. Аутентификация Объекта

2.1.1. Обобщенная Модель Аутентификации

2.1.2. Алгоритмы аутентификации

2.1.2.1. Асимметричные Алгоритмы Цифровой подписи

2.1.2.2. Симметричные Алгоритмы Цифровой подписи

2.1.2.3. Хэш-функция

2.1.3. Обработка Ошибок

2.2. Конфиденциальность

2.2.1. Обобщенная Модель Конфиденциальности

2.2.2. Инфраструктура и Механизмы Конфиденциальности

2.2.3. Обзор Специальных Сетевых Ячеек

2.3. Аутентификация и Целостность Данных

2.3.1. Обобщенная Модель Целостности

2.3.2. Инфраструктура и Механизмы Целостности

2.3.2.1. Подпись

2.4. Управление доступом

2.4.1. Обобщенная модель Управления доступом

2.4.2. Инфраструктура и Механизмы Управления доступом

2.4.3. Обработка Ошибок

3. Глоссарий

4. Литература по данной теме

5. Источники

Назад на страницу Кунегина С.В.


Скопировать работу полностью (архив)

 

 

 

 

 

 

 

1. Введение

 

Данные Технические требования определяют процедуры, которые обеспечивают ряд служб безопасности АТМ. Эти службы безопасности делятся на три широких категории - службы безопасности для виртуальных каналов сегмента пользователя, службы безопасности для сообщений сегмента контроля, и службы поддержки (управление всем сегментом служб безопасности не рассматриваются в данных Технических требованиях). Службы безопасности сегмента пользователя выполнены на основе виртуальных соединений, где "виртуальное соединение" может быть или виртуальным соединением каналом или виртуальным соединением пути. Службы безопасности обеспечивающие поддержку включают службы обмена сообщениями защиты и согласования (параметров защиты), которые выполняются при установлении подключения через сигнализацию, и/или в пределах виртуального канала уровня пользователя (после того, как подключение установлено, но перед передачей данных). Как только виртуальный канал установлен, дальнейшая передача сообщений в полосе {данных пользователя} обеспечивается OAM ячейками безопасности, в соответствии с согласованными криптографическими алгоритмами.

 

2. Службы безопасности сегмента Пользователя

2.1. Аутентификация Объекта

2.1.1. Обобщенная Модель Аутентификации

Аутентификация обеспечивается через обмен информацией между агентами безопасности(SA), обеспечивающими обмен сообщениями безопасности(Security Message Exchange) (SAsme). Аутентификация позволяет подтвердить аутентифицирующему агенту службы безопасности (SAservice), что аутентифицируемый агент службы безопасности (SAservice) обладает секретной информацией, которая известна исключительно заверенному объекту (или его полномочному представителю (proxy)), или исключительно этим двум объектам (или их полномочным представителям (proxies)). Аутентификация может быть двунаправленной (вызывающий абонент к вызываемому абоненту или абонентам и наоборот) или однонаправленой. Аутентифицируемые объекты во всех случаях - Агенты Безопасности (SA), связанные с объектами сегмента пользователя, которые завершают виртуальный путь или канал ATM. В случае использования, аутентификация ATM должна быть на базе виртуального канала. Это означает что:

· Решение подтверждать подлинность или нет принимается на основе согласования виртуальных каналов.

· Аутентификация для подключения выполняется в начале этого подключения.

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

Существует два варианта процедур согласования, определенных для ведущих переговоры служб безопасности: первый - основанный на сигнализации (сообщения безопасности передаются посредством сигнализации) и второй – полосовой (работающий непосредственно в полосе данных ). Имеются различия в обобщенных моделях в том, как служба аутентификации реализует эти два способа.

Рисунок 1 показывает объектную и уровневую обобщенные модели службы аутентификации в случае, когда передача сообщений защиты основана на сигнализации. В этом случае агент защиты, обеспечивающий обмен сообщениями безопасности(Security Message Exchange (SAsme) вызывается сигнализацией. Этот агент (SAsme) сотрудничает с объектом управления так, чтобы аутентификация обеспечивалась для объектов сегмента пользователя, требующих этого.

Объектная и уровневая обобщенные модели для случая, когда передача сообщений защиты происходит непосредственно в полосе данных показаны на Рисунке2.

Эта модель подобна модели основанной на сигнализации за исключением того, что агент безопасности, обеспечивающий обмен сообщениями безопасности(Security Message Exchange (SAsme) совершает свой обмен, пропуская сообщения в поток данных пользователя, как показано на Рисунке 2. Все остальные объектные взаимодействия происходят аналогично случаю модели основанной на сигнализации.

Рисунок 1 Объектная и Уровневая обобщенные модели аутентификации. Передача сообщений основанная на сигнализации

Рисунок 2 Объектная и Уровневая обобщенные модели аутентификации. Полосовая передача сообщений

2.1.2. Алгоритмы аутентификации

Аутентификация обеспечивается с помощью протокола Обмена Сообщениями Защиты. Аутентификация выполняется, используя возможности симметричных алгоритмов шифрования (таких, как DES) или асимметричных (например, RSA). Если двум узлам требуется провести процесс аутентификации в случае симметричных алгоритмов, прежде всего эти два узла должны иметь общий секретный ключ. В случае асимметричных алгоритмов , узлы должны знать только открытые ключи друг друга.

Прежде, чем начать процесс аутентификации между двумя агентами защиты (SAservice), они должны получить ключи для криптографических методов.

В случае симметричных алгоритмов, два агента защиты (SAservice) должны иметь пару общих секретных ключей. Эти ключи зависят от конкретных методов шифрования и в Технических Требованиях не рассматриваются.

В случае асимметричных алгоритмов, агенты защиты (SAservice) должны знать открытые ключи друг друга. Эти открытые ключи могут быть получены тремя способами:

1. С помощью отыскания общего ключевого сертификата агентов защиты (SAservice) из таблицы общедоступного ключевого каталога,

2. Обменивая общедоступные ключи непосредственно в течение согласования параметров защиты, или

3. Распределяя общедоступные ключи, используя другие методы определяемые пользователем.

Выработка, распределение, и хранение секретных, и-или общедоступных ключей - не описываются в Технических требованиях.

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

Пример кодпойнта для алгоритмов аутентификации :

Последовательность битов 0 0 0 0 0 0 1 1

Название AUTH-3

Алгоритм цифровой подписи EC/DSA

Алгоритм хеширования SHA-1

2.1.2.1. Асимметричные Алгоритмы Цифровой подписи (ЦП)

В Технических требованиях определены следующие асимметричные алгоритмы цифровой подписи для аутентификации сегмента пользователя: RSA, DSA, ECDSA, ESIGN. Кроме того могут использоваться алгоритмы определяемые пользователем.

2.1.2.2. Симметричные Алгоритмы Цифровой подписи

В Технических требованиях определены следующие симметричные алгоритмы цифровой подписи для аутентификации сегмента пользователя: DES в режиме CBC, DES40 в режиме CBC, Triple-DES в режиме CBC, FEAL (в режиме CBC). Кроме того могут использоваться алгоритмы определяемые пользователем.

 

2.1.2.3. Хэш-функция

Следующие хэш-функции определены в Технических требованиях для использования, как с асимметричными, так и симметричными алгоритмами цифровой подписи: MD5, SHA-1, RIPEMD-160. Кроме того могут использоваться алгоритмы определяемые пользователем.

 

2.1.3. Обработка Ошибок

Процедуры обработки ошибок зависят от реализации. Общая концепция состоит в том , что когда инициатор или ответчик обнаруживают ошибку, он посылает сообщение ОШИБКА партнеру, чтобы сообщить об ошибке, фиксирует состояние сбоя, и прекращает работу. Для описания причины возникновения ошибки используется Информационный элемент причины ошибки, который передается с сообщением ОШИБКА.

2.2. Конфиденциальность

2.2.1. Обобщенная Модель Конфиденциальности

Конфиденциальность обеспечивается с помощью шифрования. В случае использования, шифрование ATM должно быть основано на базе виртуального канала(VC) (напоминаем что "VC" может быть либо Виртуальным Соединением Канала [VCC] либо Виртуальным Соединением Пути [VPC]). Это означает, что:

· Шифрование применяется к последовательности ячеек данных в пределах одного виртуального канала (VC).

· Решение зашифровать или нет принимается на основе согласования виртуальных каналов.

· Для зашифрованных виртуальных каналов (VC), параметры кодирования определены (и могут измениться) на базе согласования виртуальных каналов (VC).

Во всех случаях, шифрование применяется ко всем или к части 48-байтовых нагрузок ячеек ATM. Таким образом, в терминах архитектуры и иерархического представления ATM шифрование имеет место на уровне ATM. Другие подходы к конфиденциальности (например, шифрование каналов с большим объемом информации, кодирование AAL уровня) - не входит в Технические требования. Как поясняют разделы требований , имеются два пути для согласования параметров служб безопасности: основанный на сигнализации и " полосовой". Имеются различия в обо,щенных моделях в том, как служба обеспечения конфиденциальности реализована для этих двух случаях. Рисунок 3 показывает объектную и уровневую обобщенные модели службы обеспечения конфиденциальности в случае когда SME основана на сигнализации. В этом случае, SASME(обмен сообщениями защиты агента защиты) вызывается объектом сегмента контроля. Как объяснено выше, функция шифрования / расшифрования службы SA(агента защиты) - логически часть объекта уровня ATM, потому что все шифрование применяется на базе виртуального канала(VC) . Если того требует выбранный криптографический режим, функция шифрования / расшифрования службы SA защищает состояние через ячейки OAM(ячейки Операции администрации и защиты – эти ячейки используются для передачи параметров при установлении защищенного соединения) передаваемые по сквозным потокам(потоки между оконечными агентами защиты) F4 или F5 ( Для VPC и VCC соответственно).

Рисунок 3. Объектная и Уровневая Обобщенные Модели Обеспечения Конфиденциальности. Передача сообщений основанная на сигнализации.

Объектная и Уровневая Обобщенные Модели в случае, когда передача сообщений защиты - "полосовая" (Рисунок 4) похожа на основанную на сигнализации за исключением размещения SASME. Для полосового случая , SASME выходит за пределы объекта сегмента контроля, как показано в Рисунке 4. Во всем остальном объектные взаимодействия - как для случая с сигнализацией.

Рисунок 4. Объектная и Уровневая Обобщенные Модели Обеспечения Конфиденциальности. Полосовая Передача сообщений Защиты .

2.2.2. Инфраструктура и Механизмы Конфиденциальности

В этих Технических требованиях, симметричные алгоритмы обеспечивают конфиденциальность сегмента пользователя. Кроме того, алгоритмы, перечисленные ниже должны использоваться в определенном режиме работы. Ключи для этих алгоритмов могут быть или заранее определенными (заданными вручную), или заданы с помощью Методов Обмена Ключами. Для аутентификации во время согласования параметров защиты используется кодпойнт связанный с определенным алгоритмом и режимом работы. Следующие алгоритмы определены в этих технических требованиях для конфиденциальности сегмента пользователя: DES (56-битный ключ), DES40 (40-битный ключ), Triple DES (112-битный ключ), FEAL (64-битный ключ, без равенства ключевых блоков, N=32).

Следующие режимы работы определены в этих технических требованиях для конфиденциальности сегмента пользователя: С зацеплением блоков (CBC), Встречный режим (Counter Mode), Электронная кодовая книга (ECB).

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

Эти технические требования также обеспечивают механизм для меняющихся сеансовых ключей для службы обеспечения конфиденциальности.

2.2.3. Обзор Специальных Сетевых Ячеек

Поскольку служба обеспечения конфиденциальности данных определена в уровне ATM, необходимо разъяснить ее действия по отношению к специальным сетевым ячейкам (не ячейкам данных пользователя). Поскольку эти специальные ячейки, то есть OAM ячейки или RM ячейки, интерпретируются промежуточными узлами в сети, они должны быть исключены из процесса шифрования. Т.к. иначе они будут бессмысленными для промежуточных узлов, поскольку не возможно или не желательно включение промежуточных узлов в процесс шифрования. С этой целью должно применятся следующее:

· Для Виртуальных Соединений Канала (VCC), 1xx (бинарные) ячейки с полем (PTI) Индикатора Типа Нагрузки не будут шифроваться, и будут передаваться в открытом виде. Кроме того, если дополнительно не определено , эти ячейки не должны изменять криптографическое состояние агента защиты.

· Для Виртуальных Соединений Пути (VPC), ячейки с полем (VCI)Виртуального Идентификатора Канала со следующими значениями: 3, 4, и 6-15 не будут шифроваться и будут передаваться в открытом виде. Кроме того, если при этом дополнительно не определено, эти ячейки не должны изменять криптографическое состояние агента защиты.

2.3. Аутентификация и Целостность Данных

2.3.1. Обобщенная Модель Целостности

Целостность данных обеспечивается посредством криптографических контрольных сумм (также известных как хеш-коды или опознавательные коды сообщения [MAC]) добавленных в конец к " Служебной Части(Common Part) " служебных модулей данных (SDU) AAL 3/4 и AAL 5 . Служба целостности данных доступна только для виртуальных каналов, но не для виртуальных путей.

В случае использования, целостность данных ATM должна базироваться на виртуальном соединении канала (VCC) . Это означает, что :

· Защиты целостности не применяется к виртуальному соединению пути (VPC).

· Контрольные суммы применяются к последовательности Служебных Частей модулей SDU в виртуальном соединении канала (VCC).

· Решение обеспечивать целостность или нет определяется на базе согласования виртуальных соединений канала (VCC).

· Для виртуальных соединений канала (VCC) с контрольными суммами, ключи целостности определяются (и могут измениться) на базе согласования виртуальных соединений канала (VCC).

В терминах архитектуры и иерархического представления ATM, функция целостности данных имеет место в AAL. Другие подходы к целостности данных - вне рассмотрения технических требований. Имеются два метода, определенных для согласования параметров служб безопасности: основанный на сигнализации и " полосовой ". Имеются различия в обобщенных моделях в том, как служба обеспечения целостности данных реализуется в этих двух случаях. Рисунок 5 показывает объектную и уровневую обобщенные модели для службы обеспечения целостности данных в случае, когда передача сообщений защиты основана на сигнализации. В этом случае, SASME вызывается объектом сегмента контроля по получении, или до посылки, всех сообщений. Как объяснено выше, функция целостности данных SASERVICE логически часть объекта AAL, потому что MAC применяются на базе передачи внутри виртуального соединения канала (VCC).

Объектная и уровневая обобщенные модели для случая, когда передача сообщений защиты - " полосовая" (Рисунок 6) такая же как и модель основанная на сигнализации за исключением размещения SASME. Для полосовогоо случая, SASME находится вне объекта сегмента контроля, как показано на Рисунке 6. Во всем остальном объектные взаимодействия - такие же как для случая основанного на сигнализации.

Рисунок 5. Объектная и уровневая обобщенные модели целостности данных.

Передача сообщений защиты основанная на сигнализации.

Рисунок 6. Объектная и уровневая обобщенные модели целостности данных.

Полосовая передача сообщений защиты.

2.3.2. Инфраструктура и Механизмы Целостности

Механизм целостности данных поддерживает целостность данных для " Служебной Части " AAL SDU в AAL типа ѕ и AAL типа 5 для данных пользователя на базе виртуального соединения канала (VCC) . Виртуальное соединение канала (VCC) может выступать в качестве переключаемого виртуального соединения канала (VCC) (то есть, SVC) или постоянного виртуального соединения канала (VCC) (то есть, PVC).

Рисунок 7. Целостность Данных Уровня AAL-SDU.

Служба целостности данных обеспечивается двумя параметрами: 1) целостность данных без защиты от повторной передачи / переупорядочения (ячеек) и 2) целостность данных с защитой от повторной передачи / переупорядочения. Параметр, используемый в соединении может быть согласован во время установления соединения. Когда целостность данных обеспечивается без защиты от повторной передачи / переупорядочения, источник добавляет криптогафическую подпись , обычно называемую опознавательный код сообщения (MAC), в конец каждой Служебной Части AAL-SDU перед ее передачей , как показано на рисунке 7. Подпись вычисляется по Служебной Части AAL-SDU.

Когда Служебная Часть AAL-SDU достигает адресата, агент защиты проверяет подпись. Если подпись не правильная, он просто отказывается от AAL-SDU.

Когда целостность данных обеспечивается с защитой повторной передачи / переупорядочения, служба целостности данных обеспечивает защиту против атак типа повторная передача и переупорядочивание (изменения порядка следования ячеек) , так, чтобы "старый" или "переупорядоченный" AAL-SDU были обнаружены и отвергнутый. В отправителе, это достигнуто добавлением порядкового номера в конец каждой Служебной Части AAL-SDU и затем вычислением подписи на всем длине Служебной Части AAL-SDU, включая порядковый номер. Эта подпись, которая защищает, и AAL-SDU и порядковый номер, добавляется в конец к полной Служебной Части AAL-SDU (которая включает порядковый номер), как показано на рисунке 7.

Порядковый номер устанавливается на нулевое значение, когда устанавливается подключение и каждый раз сеансовый ключ для целостности данных обновляется (то есть, меняется). Порядковый номер увеличивается с каждым AAL-SDU который посылает источник. Порядковый номер - 6-байтовое число. Порядковый номер не должен повторятся в течение действия сеансового ключа целостности.

Когда Служебная Часть AAL-SDU получена адресатом, агент защиты проверяет является ли подпись правильной. Если подпись не правильная, он отказывается от AAL-SDU. Если подпись правильная, он проверяет порядковый номер, чтобы гарантировать, что он правильный.

Агент защиты на приеме проверяет порядковый номер следующим образом. Когда имеется предварительно полученная правильная Служебная Часть AAL-SDU, тогда порядковый номер, связанный с текущей Служебной Частью AAL-SDU является правильным только, если он большее чем порядковый номер, связанный с последней правильной Служебной Частью AAL-SDU. Когда не имеется предварительно полученной правильной Служебной Части AAL-SDU, порядковый номер, связанный с текущей Служебной Частью AAL-SDU полагается правильным. Если порядковый номер не проходит эти тесты, агент защиты отказывается от AAL-SDU.

Агент защиты приема сохраняет порядковый номер, связанный с последней правильной Служебной Частью AAL-SDU , чтобы проверить правильность следующей Служебной Части AAL-SDU, которую он может принять.

2.3.2.1. Подпись

Алгоритм подписи (или MAC) используемый для службы целостности соединения согласовывается во время установления соединения.

С каждым алгоритмом связан кодпойнт, который используется для идентификации при согласовании параметров защиты .

Следующие алгоритмы определены в этих технических требованиях для целостности сегмента пользователя:HMAC-MD5, HMAC-SHA-1, HMAC-RIPEMD-160, DES/CBC MAC, DES40/CBC MAC, Triple DES/CBC MAC, FEAL/CBC MAC.

Как и со службой обеспечения конфиденциальности, эти технические требования обеспечивают механизм для изменяющихся сеансовых ключей для службы целостности. Обратите внимание, однако, что т.к. SKC (secure key service-служба сохранности ключей) OAM ячейки могут не прибывать во временные границы SDU, ключевое переключение для целостности данных, которое не учитывает временные границы SDU может приводить к потере данных.

2.4. Управление доступом

2.4.1. Обобщенная модель Управления доступом

Управление доступом обеспечивается на базе виртуального канала VC . Вообще, управление доступом выполняется во время установления соединения, основанного на информации, содержащейся в обмене сообщениями защиты и параметрах конфигурации сети.

Имеются два метода, определенных для согласования параметров службами безопасности: основанный на сигнализации и "полосовой". Для обоих из этих методов, имеются различия в обобщенных моделях в том, как описано управление доступом описано.

Рисунок 8 показывает уровневую обобщенную модель управления доступом для службы управления доступом в случае когда при передаче сообщений защиты используется основанный на сигнализации метод согласования параметров служб безопасности. В этом случае, SASME является логически частью объекта сегмента контроля.

 


Рисунок 8. Уровневая Обобщенная модель Управления доступом для основанной на Сигнализации Передачи сообщений.

Уровневая Обобщенная модель управления доступом для "полосового" метода для согласования параметров служб безопасности (Рисунок 9) похожа на основанную на сигнализации если бы не размещение SASME. Для "полосового" случая , SAsme находится вне объекта сегмента контроля, как показано в Рисунке 9. Во всем остальном, взаимодействия - такие же как в основанном на сигнализации случае.


Рисунок 9. Уровневая Обобщенная модель Управления доступом для полосовой Передачи сообщений.

2.4.2. Инфраструктура и Механизмы Управления доступом

C каждым механизмом cвязан кодпойнт, который используется для выбора механизма при согласовании параметров защиты.

Данные Управления доступом посылаются в начальном обмене между агентами защиты с тем, чтобы можно было принять решения по управлению доступом , по мере необходимости, в каждом компоненте ATM на пути (соединения) подключения в течение установления соединения. Следующие алгоритмы определены в этих технических требованиях для управления доступом сегмента пользователя: Стандартная Метка Защиты

2.4.3. Обработка Ошибок

Если ошибка мешает установлению подключения, сообщение об ошибках должно быть передано вызывающему абоненту для разрыва соединения во время установки соединения в соответствии с процедурами обработки ошибок. Количество диагностической информации, предоставляемой в Информационном Элементе Причины Ошибки(Cause Infomation Element), должно конфигурироваться.