Административная реакция на инцидент
Когда инцидент с безопасностью затрагивает пользователей, политика безопасности должна описывать, какие действия следует предпринять. Злоупотребления должны рассматриваться как серьезные проступки, но очень важно быть уверенным в роли, которую в инциденте играл пользователь. Был ли пользователь наивным? Возможна ли ошибка в обвинении пользователя? Принятие административных мер, исходя из предположения преднамеренных действий, к пользователю, который совершил лишь ошибку, нельзя признать адекватным. Может быть более адекватным включение в вашу политику других более приемлемых санкций (например, обучение или замечание) в дополнение к более строгим мерам для преднамеренных действий по вторжению и недопустимому использованию системы.
Алгоритм DES
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Стандарт шифрования DES (Data Encryption Standard) был разработан в 1970-х годах, он базируется на алгоритме DEA.
Исходные идеи алгоритма шифрования данных DEA (data encryption algorithm) были предложены компанией IBM еще в 1960-х годах и базировались на идеях, описанных Клодом Шенноном в 1940-х годах. Первоначально эта методика шифрования называлась lucifer (разработчик Хорст Фейштель, название dea (см. ) она получила лишь в 1976 году. Lucifer был первым блочным алгоритмом шифрования, он использовал блоки размером 128 бит и 128-битовый ключ. По существу этот алгоритм являлся прототипом DEA. В 1986 в Японии (NIT) разработан алгоритм FEAL(Fast data Encipherment ALgorithm), предназначенный для использования в факсах, модемах и телефонах (длина ключа до 128 бит). Существует и ряд других разработок.
DEA (ANSI x3.92-1981; ) оперирует с блоками данных размером 64 бита и использует ключ длиной 56 бит. Такая длина ключа соответствует 1017 комбинаций, что обеспечивало до недавнего времени достаточный уровень безопасности. В дальнейшем можно ожидать расширения ключа до 64 бит (например, LOKI) или вообще замены DES другим стандартом.
Входной блок данных, состоящий из 64 бит, преобразуется в выходной блок идентичной длины. Ключ шифрования должен быть известен, как отправляющей так и принимающей сторонам. В алгоритме широко используются перестановки битов текста.
Вводится функция f, которая работает с 32-разрядными словами исходного текста (А) и использует в качестве параметра 48-разрядный ключ (J). Схеме работы функции f показана на рис. 6.4.1.1. Сначала 32 входные разряда расширяются до 48, при этом некоторые разряды повторяются. Схема этого расширения показана ниже (номера соответствуют номерам бит исходного 32-разрядного кода).
32 1 2 3 4 5
4 5 6 7 8 9
8 9 10 11 12 13
12 13 14 15 16 17
16 17 18 19 20 21
20 21 22 23 24 25
24 25 26 27 28 29
28 29 30 31 32 1
Для полученного 48-разрядного кода и ключа выполняется операция исключающее ИЛИ (XOR).
Результирующий 48-разрядный код преобразуется в 32-разрядный с помощью S-матриц. На выходе S- матриц осуществляется перестановка согласно схеме показанной ниже (числа представляют собой порядковые номера бит).
16 7 20 21
29 12 28 17
1 15 23 26
5 18 31 10
2 8 24 14
32 27 3 9
19 13 30 6
22 11 4 25
Рис. 6.4.1.1. Алгоритм работы функции f
Преобразование начинается с перестановки бит (IP – Initial Permutation) в 64-разрядном блоке исходных данных. 58-ой бит становится первым, 50-ый – вторым и т.д. Схема перестановки битов показана ниже.
58 50 42 34 26 18 10 2
60 52 44 36 28 20 12 4
62 54 46 38 30 22 14 6
64 56 48 40 32 24 16 8
57 49 41 33 25 17 9 1
59 51 43 35 27 19 11 3
61 53 45 37 29 21 13 5
63 55 47 39 31 23 15 7
Полученный блок делится на две 32-разрядные части L0 и R0. Далее 16 раз повторяются следующие 4 процедуры:
Преобразование ключа с учетом номера итерации i (перестановки разрядов с удалением 8 бит, в результате получается 48-разрядный ключ)
Пусть A=Li, а J – преобразованный ключ. С помощью функции f(A,J) генерируется 32-разрядный выходной код.
Выполняется операция XOR для Ri f(A,J), результат обозначается Ri+1.
Выполняется операция присвоения Li+1=Ri.
Структурная схема реализации алгоритма dea показана на рис. 6.4.1.2.
Рис. 6.4.1.2. Структурная схема реализации алгоритма DEA
Инверсная перестановка разрядов предполагает следующее размещение 64 бит зашифрованных данных (первым битом становится 40-ой, вторым 8-ой и т.д.).
40 8 48 16 56 24 64 32
39 7 47 15 55 23 63 31
38 6 46 14 54 22 62 30
37 5 45 13 53 21 61 29
36 4 44 12 52 20 60 28
35 3 43 11 51 19 59 27
34 2 42 10 50 18 58 26
33 1 41 9 49 17 57 25
S-матрицы представляют собой таблицы содержащие 4-ряда и 16 столбцов. Матрица S(1) представлена ниже (эта матрица, также как и те, что приведены в ссылке 2, являются рекомендуемыми).
No. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
1 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
2 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
3 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
Исходный 48-разрядный код делится на 8 групп по 6 разрядов. Первый и последний разряд в группе используется в качестве адреса строки, а средние 4 разряда – в качестве адреса столбца. В результате каждые 6 бит кода преобразуются в 4 бита, а весь 48-разрядный код в 32-разрядный (для этого нужно 8 S-матриц). Существуют разработки, позволяющие выполнять шифрование в рамках стандарта DES аппаратным образом, что обеспечивает довольно высокое быстродействие.
Преобразования ключей Kn (n=1,…,16; Kn = KS(n,key), где n – номер итерации) осуществляются согласно алгоритму, показанному на рис. 6.4.1.3.
Рис. 6.4.1.3. Алгоритм вычисления последовательности ключей Kn
Для описания алгоритма вычисления ключей Kn (функция KS) достаточно определить структуру “Выбора 1” и “Выбора 2”, а также задать схему сдвигов влево (табл. 6.4.1.2). “Выбора 1” и “Выбора 2” представляют собой перестановки битов ключа (PC-1 и PC-2; табл. 6.4.1.1). При необходимости биты 8, 16,…, 64 могут использоваться для контроля четности.
Для вычисления очередного значения ключа таблица делится на две части С0 и D0. В С0 войдут биты 57, 49, 41,…, 44 и 36, а в D0 – 63, 55, 47,…, 12 и 4. Так как схема сдвигов задана (табл. 6.4.1.2) C1,D1; Cn, Dn и так далее могут быть легко получены из C0 и D0. Так, например, C3 и D3 получаются из C2 и D2 циклическим сдвигом влево на 2 разряда
Таблица 6.4.1.1
| PC-1 (Выбор 1) | PC-2 (Выбор 2) |
| 57 49 41 33 25 17 9 | 14 17 11 24 1 5 |
| 1 58 50 42 34 26 18 | 3 28 15 6 21 10 |
| 10 2 59 51 43 35 27 | 23 19 12 4 26 8 |
| 19 11 3 60 52 44 36 | 16 7 27 20 13 2 |
| 63 55 47 39 31 23 15 | 41 52 31 37 47 55 |
| 7 62 54 46 38 30 22 | 30 40 51 45 33 48 |
| 14 6 61 53 45 37 29 | 44 49 39 56 34 53 |
| 21 13 5 28 20 12 4 | 46 42 50 36 29 32 |
| Номер итерации | Число сдвигов влево |
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
| 5 | 2 |
| 6 | 2 |
| 7 | 2 |
| 8 | 2 |
| 9 | 1 |
| 10 | 2 |
| 11 | 2 |
| 12 | 2 |
| 13 | 2 |
| 14 | 2 |
| 15 | 2 |
| 16 | 1 |
Алгоритм Диффи-Хелмана
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Алгоритм Диффи-Хелмана (1976 год) использует функцию дискретного возведения в степень и похож на метод Эль-Гамаля.
Сначала генерируются два больших простых числа n и q. Эти два числа не обязательно хранить в секрете. Далее один из партнеров P1 генерирует случайное число x и посылает другому участнику будущих обменов P2 значение
A = qx mod n
По получении А партнер P2 генерирует случайное число у и посылает P2 вычисленное значение
B = qy mod n
Партнер P1, получив В, вычисляет Kx = Bx mod n, а партнер P2 вычисляет Ky = Ay mod n. Алгоритм гарантирует, что числа Ky и Kx равны и могут быть использованы в качестве секретного ключа для шифрования. Ведь даже перехватив числа А и В, трудно вычислить Kx или Ky.
Алгоритм Диффи-Хелмана, обеспечивая конфиденциальность передачи ключа, не может гарантировать того, что он прислан именно тем партнером, который предполагается. Для решения этой проблемы был предложен протокол STS (station-to-station). Этот протокол для идентификации отправителя использует технику электронной подписи. Подпись шифруется общим секретным ключом, после того как он сформирован. Подпись включает в себя идентификаторы как P1, так и P2. (см. также RFC-2786 "Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000".)
Алгоритм Эль Гамаля
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Алгоритм Эль-Гамаля может использоваться для формирования электронной подписи или для шифрования данных. Он базируется на трудности вычисления дискретного логарифма. Для генерации пары ключей сначала берется простое число p и два случайных числа g и x, каждое из которых меньше p. Затем вычисляется:
y = gx mod p
Общедоступными ключами являются y, g и p, а секретным ключом является х. Для подписи сообщения M выбирается случайное число k, которое является простым по отношению к p-1. После этого вычисляется a = gk mod p. Далее из уравнения M = (xa + kb) mod (p-1) находим b. Электронной подписью для сообщения M будет служить пара a и b. Случайное число k следует хранить в секрете. Для верификации подписи необходимо проверить равенство:
yaab mod p = gM mod p.
Пара a и b представляют собой зашифрованный текст. Следует заметить, что зашифрованный текст имеет размер в два раза больше исходного. Для дешифрования производится вычисление:
M = b/ax mod p
Алгоритм шифрования RSA
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Алгоритм RSA предполагает, что посланное закодированное сообщение может быть прочитано адресатом и только им. В этом алгоритме используется два ключа – открытый и секретный. Данный алгоритм привлекателен также в случае, когда большое число субъектов (N) должно общаться по схеме все-со-всеми. В случае симметричной схемы шифрования каждый из субъектов каким-то образом должен доставить свои ключи всем остальным участникам обмена, при этом суммарное число используемых ключей будет достаточно велико при большом значении N. Применение асимметричного алгоритма требует лишь рассылки открытых ключей всеми участниками, суммарное число ключей равно N.
Сообщение представляется в виде числа M. Шифрование осуществляется с помощью общедоступной функции f(M), и только адресату известно, как выполнить операцию f-1. Адресат выбирает два больших простых (prime) числа p и q, которые делает секретными. Он объявляет n=pq и число d, c (d,p-1)=(d,q-1)=1 (один из возможных способов выполнить это условие, выбрать d больше чем p/2 и q/2). Шифрование производится по формуле:
f(M) є Md mod n,
где M и f(M) оба Ј n-1. Как было показано, может быть вычислено за разумное время, даже если M, d и n содержит весьма большое число знаков. Адресат вычисляет M на основе Md, используя свое знание p и q. В соответствие со следствием 6, если
dc є(p-1)1, тогда (Md)eє p1.
Исходный текст M получается адресатом из зашифрованного F(M) путем преобразования: M = (F(M))e (mod pq). Здесь как исходный текст, так и зашифрованный рассматриваются как длинные двоичные числа.
Аналогично (Md)e є qM, если dc є (q-1)1. e удовлетворяет этим двум условиям, если cd є (p-1) (q-1)1. Теорема 1 гласит, что мы можем позволить e=x, когда x является решением уравнения dx + (p-1)(q-1)y = 1.
Так как (Md)e – M делимо на p и q, оно делимо и на pq, следовательно, мы можем определить M, зная Md, вычислив его значение в степени e и определив остаток от деления на pq. Для соблюдения секретности важно, чтобы, зная n, было нельзя вычислить p и q.
Если n содержит 100 цифр, подбор шифра связан с перебором ~1050 комбинаций. Данная проблема изучается уже около 100 лет. RSA-алгоритм запатентован (20 сентября 1983, действует до 2000 года).
Теоретически можно предположить, что возможно выполнение операции f-1, не вычисляя p и q. Но в любом случае задача эта не проста и разработчики считают ее трудно факторизуемой.
Предположим, что мы имеем зашифрованный текст f(M) и исходный текст M, и мы хотим найти значения p и q. Нетрудно показать, что таких исходных данных для решения задачи недостаточно – надо знать все возможные значения Mi.
Проясним использование алгоритма RSA на конкретном примере. Выбираем два простые числа p=7; q=17 (на практике эти числа во много раз длиннее). В этом случае n = p*q будет равно 119. Теперь необходимо выбрать e, выбираем e=5. Следующий шаг связан с формированием числа d так, чтобы d*e=1 mod [(p-1)(q-1)]. d=77 (использован расширенный алгоритм Эвклида). d – секретный ключ, а e и n характеризуют открытый ключ. Пусть текст, который нам нужно зашифровать представляется M=19. С = Memod n. Получаем зашифрованный текст C=66. Этот “текст” может быть послан соответствующему адресату. Получатель дешифрует полученное сообщение, используя М= Cdmod n и C=66. В результате получается M=19.
На практике общедоступные ключи могут помещаться в специальную базу данных. При необходимости послать партнеру зашифрованное сообщение можно сделать сначала запрос его открытого ключа. Получив его, можно запустить программу шифрации, а результат ее работы послать адресату. На использовании общедоступных ключей базируется и так называемая электронная подпись, которая позволяет однозначно идентифицировать отправителя. Сходные средства могут применяться для предотвращения внесения каких-либо корректив в сообщение на пути от отправителя к получателю. Быстродействующие аппаратные 512-битовые модули могут обеспечить скорость шифрования на уровне 64 кбит в сек. Готовятся ИС, способные выполнять такие операции со скоростью 1 Мбайт/сек.Разумный выбор параметра e позволяет заметно ускорить реализацию алгоритма.
Алгоритм шифрования SAFER
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Алгоритм шифрования SAFER (Secure And Fast Encryption Routine; http://fn2.freenet.edmonton.ab.ca/~jsavard/co0403.html) не использует разбивку исходного текста на блоки (как это делается в DES или IDEA). Здесь исходный текст пропускается через S-матрицы, которые заменяются на обратные версии при дешифровании. В SAFER используется 8 циклов. Первый шаг цикла заключается в использовании первого субключа для преобразования 8 байт исходного текста. То, как используется субключ, зависит от номера байта в группе. Так для 1-го, 4-го, 5-го и 8-го для этого служит операция XOR, а для 2-го, 3-го, 6-го и 7-го байтов применяется операция сложения.
Затем при обработке текста в S-матрице байты, для которых было применено исключающее ИЛИ, поступают на обычную матрицу, для остальных применяется инвертированная. s-матрицы представляют собой таблицы байтов, которые получаются по формуле 45N mod 257, где N –номер кода в таблице (после чего выделяются 8 младших разрядов).
1 45 226 147 190 69 21 174
120 3 135 164 184 56 207 63
8 103 9 148 235 38 168 107
189 24 52 27 187 191 114 247
64 53 72 156 81 47 59 85
227 192 159 216 211 243 141 177
255 167 62 220 134 119 215 166
17 251 244 186 146 145 100 131
241 51 239 218 44 181 178 43
136 209 153 203 140 132 29 20
129 151 113 202 95 163 139 87
60 130 196 82 92 28 232 160
4 180 133 74 246 19 84 182
223 12 26 142 222 224 57 252
32 155 36 78 169 152 158 171
242 96 208 108 234 250 199 217
0 212 31 110 67 188 236 83
137 254 122 93 73 201 50 194
249 154 248 109 22 219 89 150
68 233 205 230 70 66 143 10
193 204 185 101 176 210 198 172
30 65 98 41 46 14 116 80
2 90 195 37 123 138 42 91
240 6 13 71 111 112 157 126
16 206 18 39 213 76 79 214
121 48 104 54 117 125 228 237
128 106 144 55 162 94 118 170
197 127 61 175 165 229 25 97
253 77 124 183 11 238 173 75
34 245 231 115 35 33 200 5
225 102 221 179 88 105 99 86
15 161 49 149 23 7 58 40
Обратная матрица при этом имеет вид.
128 0 176 9 96 239 185 253
16 18 159 228 105 186 173 248
192 56 194 101 79 6 148 252
25 222 106 27 93 78 168 130
112 237 232 236 114 179 21 195
255 171 182 71 68 1 172 37
201 250 142 65 26 33 203 211
13 110 254 38 88 218 50 15
32 169 157 132 152 5 156 187
34 140 99 231 197 225 115 198
175 36 91 135 102 39 247 87
244 150 177 183 92 139 213 84
121 223 170 246 62 163 241 17
202 245 209 23 123 147 131 188
189 82 30 235 174 204 214 53
8 200 138 180 226 205 191 217
208 80 89 63 77 98 52 10
72 136 181 86 76 46 107 158
210 61 60 3 19 251 151 81
117 74 145 113 35 190 118 42
95 249 212 85 11 220 55 49
22 116 215 119 167 230 7 219
164 47 70 243 97 69 103 227
12 162 59 28 133 24 4 29
41 160 143 178 90 216 166 126
238 141 83 75 161 154 193 14
122 73 165 44 129 196 199 54
43 127 67 149 51 242 108 104
109 240 2 40 206 221 155 234
94 153 124 20 134 207 229 66
184 64 120 45 58 233 100 31
146 144 125 57 111 224 137 48
После обработки с помощью S-матрицы используется второй субключ, который воздействует на блок преобразуемых данных. В этом случае используется другая последовательность операций: ADD, XOR, XOR, ADD, ADD, XOR, XOR, ADD (сравните с порядком операций, указанным в первом абзаце главы). Далее байты группируются: второй байт заменяется суммой первого байта и второго, первый – суммой нового значения второго байта и первого, четвертый – суммой третьего и четвертого, третий – суммой нового значения четвертого и третьего и т.д. вплоть до 8 байта включительно (см. рис. 6.4.8.1). При суммировании в результате операции учитываются только младшие 8 бит. По завершении этой процедуры байты выкладываются в следующем порядке (цифры означают старое положений байтов): 3 5 7 2 4 6 8
Рис. 6.4.8.1. Блок-схема реализации цикла алгоритма SAFER
После этого процедуры группирования и суммирования и перемешивания байтов повторяются.
Дешифровка в рамках алгоритма SAFER реализуется для каждой из процедур (путем замены их на обратные), примененной при шифровании независимо.
В качестве первого 64-битного субключа используется основной ключ шифрования.Для генерации последующих ключей используется циклический сдвиг влево на 3 бита. Полученные результаты объединяются с определенной константой (специфичной для каждого цикла) с помощью операции исключающее ИЛИ (XOR). Для первого субключа эта константа равна нулю. Далее используются константы, приведенные ниже:
16733B1E8E70BD86
477E2456F1778846
B1BAA3B7100AC537
C95A28AC64A5ECAB
C66795580DF89AF6
66DC053DD38AC3D8
6AE9364943BFEBD4
9B68A0655D57921F
715CBB22C1BE7BBC
63945F2A61B83432
FDFB1740E6511D41
8F29DD0480DEE731
7F01A2F739DA6F23
FE3AD01CD1303E12
CD0FE0A8AF82592C
7DADB2EFC287CE75
1302904F2E723385
8DCFA981E2C4272F
7A9F52E115382BFC
42C708E409555E8C
Анализ вторжений с помощью журнальных файлов
К средствам мониторинга сетевых атак относятся такие программные продукты, как SNORT (IDS), для предотвращения атак используются различные системы типа Firewall. Хорошего результата можно достичь, грамотно конфигурируя программное обеспечение ЭВМ и контролируя качество паролей. Пример фрагмента журнального файла ZoneAlarm (разновидность FireWall) представлен ниже:
FWIN,2005/08/19,14:25:04 +4:00 GMT,61.235.154.103:44666,194.85.70.31:1027,UDP FWIN,2005/08/19,14:39:36 +4:00 GMT,220.168.156.70:37740,194.85.70.31:1026,UDP FWIN,2005/08/19,14:39:36 +4:00 GMT,220.168.156.70:37740,194.85.70.31:1027,UDP FWIN,2005/08/19,14:44:34 +4:00 GMT,222.241.95.69:32875,194.85.70.31:1027,UDP
Эта распечатка демонстрирует попытки прощупывания ЭВМ с IP-адресом 194.85.70.31 на предмет откликов со стороны портов 1026 и 1027 (протоколы cap и exosee). Зондирование производится с нескольких разных адресов (61.235.154.103, 220.168.156.70 и 222.241.95.69). Объектом атаки в данном случае является рабочая станция, которая не поддерживает эти протоколы.
Существует достаточно много стандартных диагностических средств, в частности в ОС UNIX. Среди этих средств, программы ведения журнальных файлов ОС и некоторых приложений, например, Apache (файлы access_log, error_log и ssl_access_log), Samba, Squid и др..
Для отслеживания работы ОС и приложений обычно предусматривается система журнальных файлов, которая фиксирует все события (приход запросов, соответствие запросов определенным критериям и т.д.)
Рассмотрим использование журнальных файлов на примере анализа успешной атаки вторжение через приложение SSH.
Если возникло подозрение относительно возможного вторжения, надо начинать с просмотра файлов secure и messages (каталог /var/log/ ОС LINUX). В нашем случае атака началась в пятницу вечером (8-го июля 2005 года). Ниже представлены фрагменты журнальных файлов, иллюстрирующие характер атаки.
Jul 8 18:23:18 fender sshd[15017]:Illegal user anonymous from 207.232.63.45 Jul 8 18:23:20 fender sshd[15019]: Illegal user bruce from 207.232.63.45 (Нью-Йорк, США)
Jul 8 18:23:22 fender sshd[15021]: Illegal user chuck from 207.232.63.45 Jul 8 18:23:23 fender sshd[15023]: Illegal user darkman from 207.232.63.45 … Jul 9 13:15:13 fender sshd[16764]: Illegal user bruce from 129.237.101.171 Jul 9 13:15:14 fender sshd[16766]: Illegal user chuck from 129.237.101.171 Jul 9 13:15:16 fender sshd[16768]: Illegal user darkman from 129.237.101.171 Jul 9 13:15:17 fender sshd[16770]: Illegal user hostmaster from 129.237.101.171 …. Jul 10 15:25:34 fender sshd[28450]: Did not receive identification string from 80.18.87.243\par
Jul 10 16:56:16 fender sshd[28457]: Illegal user lynx from 80.18.87.243\par Jul 10 16:56:17 fender sshd[28459]: Illegal user monkey from 80.18.87.243\par Jul 10 16:56:18 fender sshd[28461]: Illegal user lion from 80.18.87.243\par …. Jul 10 02:42:02 fender sshd[18064]: Did not receive identification string from 166.70.74.35 Jul 10 03:09:13 fender sshd[18067]: Illegal user admin from 166.70.74.35 (Солт Лейк Сити, США) Jul 10 03:09:14 fender sshd[18069]: Illegal user admin from 166.70.74.35 Jul 10 03:09:16 fender sshd[18071]: Illegal user admin from 166.70.74.35 ….
Jul 10 16:56:16 fender sshd[28457]: Illegal user lynx from 80.18.87.243 (Венеция, Италия) Jul 10 16:56:17 fender sshd[28459]: Illegal user monkey from 80.18.87.243 Jul 10 16:56:18 fender sshd[28461]: Illegal user lion from 80.18.87.243 …. Jul 10 16:56:40 fender sshd[28509]: Failed password for root from 80.18.87.243 port 45208 ssh2 Jul 10 16:56:41 fender sshd[28511]: Accepted password for root from 80.18.87.243 port 45298 ssh2 …. Jul 10 19:13:49 fender sshd[31152]: Accepted password for root from 81.181.128.181 port 4943 ssh2
Из записей видно, что машина была атакована из 7 точек. Четыре расположены в США (IP=166.70.74.35; 207.232.63.45; 129.79.240.86 и 129.237.101.171), по одной в Италии, Румынии и Венгрии (IP=80.98.194.185). Производится подбор параметров доступа имя-пароль. Подбор продолжался около двух суток.
Успешный вариант был найден машиной из Италии (IP-адрес=80.18.87.243 Венеция).
Практически сразу атака со стороны всех ЭВМ была прервана и хакер вошел на атакуемую ЭВМ (имя_ЭВМ=fender) из машины с IP=81.181.128.181 (Румыния).
Для дальнейшего анализа событий нами были использованы данные из файла .bash_history, куда записываются все команды исполняемые пользователем в терминальном режиме. Записи этого файла и результаты работы демона syslogd говорят о том, что через 3 минуты после успешного вторжения хакер заблокировал работу syslog.
Далее хакер заблокировал доступ к системе других пользователей, загрузил туда файл pass_file (объем 696057 байт), содержащий комбинации имя-пароль (небольшие фрагменты содержимого файла представлены ниже).
lynx lynx monkey monkey lion lion heart heart michel michel alibaba alibaba ….. root 123456
root 1234567 …. root 1234567890 root rootroot root rootrootroot root 123root123 root 987654321 …. root 4321
root 321 root root! root root!@ root root!@# ….
Хакер рассчитывает на то, что пользователь ЭВМ ленив, и выбирает простой пароль (легче запомнить - легче подобрать). Кроме того, хакер скопировал на взломанную ЭВМ несколько скриптов и файл со списком адресов - кандидатов на взлом. После этого машина включилась в работу по подбору паролей на других ЭВМ.
К сожалению, факт атаки был установлен лишь утром в понедельник. Сначала была проведена частичная блокировка. Хакер почувствовал неладное и выдал команды last и ps, пытаясь понять, что происходит, дальнейшая его работа была полностью блокирована.
Какие выводы из этой истории можно сделать? На атакованной рабочей станции была установлена SSH устаревшей версии (имевшей уязвимость) и использован достаточно простой пароль. По этой причине нужно своевременно обновлять ОС и версии приложений. Про выбор паролей смотри RFC-2196. Особо опасными с точки зрения атак является ночь и выходные дни. Если нет насущной необходимости, лучше на это время блокировать доступ к ЭВМ или даже выключать ее.
Помимо журнальных файлов ОС надо просматривать и соответствующие файлы приложений, например, Firewall (BlackIce Defender, ZoneAlarm и т.д.), Apache, баз данных и пр.
Если даже в вашей зоне ответственности только один компьютер, просмотр всех важных файлов достаточно трудоемок. По этой причине следует рассмотреть возможность использования специализированных скриптов, которые возьмут эту работу на себя, информируя вас в случае выявления тревожных событий. Результаты работы скриптов должны накапливаться в базе данных. Эти данные могут использоваться для получения данных об атакерах и формирования ACL (списков управления доступом).
Хакер может попытаться уничтожить следы своего пребывания, стерев или очистив определенные журнальные файлы. Вполне возможно, в нашем случае хакер так бы и поступил, восстановив перед уходом и доступ по SSH. По этой причине следует заранее побеспокоиться о периодическом копировании журнальных файлов на недоступное для хакера устройство или сохранении их в зашифрованном виде. Но хакер может поступить и более жестоко, например, разметив системный диск. Хорошая схема защиты должна предотвращать такого рода действия или позволять хотя бы быстро восстанавливать разрушенную конфигурацию системы.
Следует учитывать, что сами журнальные файлы могут стать объектом атаки типа DoS. Большой поток запросов, поступающих с нескольких ЭВМ, и обращенных к одному или нескольким ресурсам машины, могут привести к быстрому росту журнальных файлов, переполнить дисковое запоминающее устройство и блокировать работу.
Асимметричная криптография
В конце 1970, главным прорывом в криптографии стала разработка асимметричной криптографии. Здесь для шифрования и дешифрования используются разные ключи, которые генерируются совместно. Наилучшая асимметричная система базируется на алгоритме, предложенном Rivest, Shamir и Adleman, и называется по инициалам авторов RSA [RSA78].
SPX представляет собой экспериментальную систему, которая преодолевает ограничения системы Kerberos путем применения криптографии с общедоступным ключом RSA [TA91]. SPX предполагает глобальную иерархию сертифицирующих узлов по одному или более для каждого из партнеров. Она использует цифровую подпись, которая состоит из строки кодов, зашифрованных секретным ключом отправителя, и которая может быть проверена с помощью соответствующего общедоступного ключа. Общедоступные ключи предполагаются правильными, так как получены с сертифицирующей подписью. Критические секции аутентификационного обмена шифруются посредством общедоступных ключей получателя, что препятствует атаке воспроизведения.
Аудитория
Аудиторией этого документа являются системные и сетевые администраторы, а также лица, принимающие решения в сетевых узлах (обычно "средний уровень менеджмента"). Короче, мы будем использовать термин "администратор" в рамках данного документа, подразумевая системного и сетевого администратора.
Данный документ не ориентирован на программистов или тех, кто пытается писать программы для безопасности или строит такие системы. Основное внимание здесь уделяется политике и процедурам, которые необходимы для поддержания параметров технической безопасности узла.
В первую очередь аудиторией документа являются узлы, подключенные к Интернет. Однако этот документ может быть полезен для любого узла, который допускает соединения с другими узлами.
Аутентификация
В течение многих лет в качестве стандарта применялся метод аутентификации пользователей с помощью многократно используемых паролей. Первоначально, эти пароли использовались клиентами на терминалах для идентификации на центральной ЭВМ. В то время не было сетей (внутри или вне), так что риск раскрытия пароля с открытым текстом был минимальным. Сегодня системы соединяются друг с другом через локальные сети, а эти локальные сети соединяются между собой и с Интернет. Пользователи входят в систему со всего мира; их многократно используемые пароли часто передаются через одни и те же сети открытым текстом, удобным для перехвата по пути кем угодно. И действительно, координационный центр CERT и другие группы реагирования регистрируют огромное число инцидентов, связанных с использование программ типа sniffer, которые перехватывают пароли с открытым текстом.
С появлением новых технологий, типа однократных паролей (например, S/Key), PGP, и устройств символьной аутентификации, базирующейся на признаках (token), люди стали использовать паролеподобные строки в качестве секретных признаков.
Аутентификация Dial-out
Пользователи, работающие через коммутируемую сеть, также должны быть аутентифицированы, в частности, так как ваш узел должен будет оплатить телефонный вызов.
Никогда не позволяйте осуществлять обратный дозвон для неаутентифицированного вызова через коммутируемую сеть, проверьте, допускаете ли вы аналогичную процедуру для аутентифицированного вызова. Целью здесь является помешать клиенту использовать ваш модемный пул для авторизации. Это может быть трудно детектировать, в частности, если хакер формирует проход через несколько ЭВМ вашего узла.
Как минимум, не позволяйте использовать те же модемы и линии для прямого вызова и обратного дозвона. Это может быть легко реализовано, если вы используете разные модемные пулы для прямого вызова и дозвона.
Аутентификация пользователя на ЭВМ
Существует много различных подходов к проблеме аутентификации пользователя в удаленных ЭВМ. Имеется две угрозы при доступе к удаленной ЭВМ. Во-первых, злоумышленник может перехватить идентификатор и пароль пользователя и позднее воспользоваться ими при атаке "воспроизведения". Во-вторых, сама форма пароля позволяет хакеру попытаться его угадать.
В настоящее время большинство систем используют открытый текст для передачи паролей по сетевым каналам, что сильно упрощает их перехват [Anderson84, Kantor91]. Такая система не обеспечивает адекватной защиты от атак воспроизведения, когда злоумышленник сумел заполучить идентификатор и пароль удаленного пользователя.
Аутентификация сетевых услуг
Кроме необходимости аутентификации пользователей и ЭВМ друг другу, многие сетевые услуги сами нуждаются в аутентификации.
Наиболее общий случай в настоящее время - это отсутствие поддержки в протоколе какой-либо аутентификации. Bellovin и другие документировали многие случаи, когда существующие протоколы могут использоваться для атаки удаленной ЭВМ, так как там не существует встроенной процедуры аутентификации [Bellovin89].
Некоторые протоколы предоставляют возможность передачи незащищенных паролей совместно с протокольной информацией. Исходные протоколы SNMP использовали этот метод, многие маршрутные протоколы продолжают его использовать и сейчас [Moy91, LR91, CFSD88]. Этот метод полезен, так как несколько повышает безопасность передачи.
Существует много протоколов, которые нуждаются в поддержке более строгих аутентификационных механизмов. Например, известно, что протокол SNMP нуждается в существенном усилении аутентификации. Это вызвало разработку протоколов Secure SNMP, которые поддерживают опционную аутентификацию, используя цифровую подпись и опционное шифрование с привлечением алгоритма DES. Цифровые подписи, используемые в Secure SNMP, базируются на добавлении криптографической контрольной суммы к SNMP-информации. Криптографическая контрольная сумма вычисляется с использованием алгоритма MD5 и секретного кода, используемого совместно обоими партнерами обмена.
Технология цифровой подписи должна рассматриваться как необходимое средство при разработке новых технологий аутентификации (но не конфиденциальности). Цифровые подписи могут использовать ключи и методы как симметричной, так и асимметричной криптографии. Если доступна централизованная система распределения ключей, опционная поддержка цифровой подписи может быть обеспечена для большинства протоколов с минимальными издержками. Каждый протокол может столкнуться проблемой пересылки ключей и установки параметров обмена, и это приведет к усложнению использования техники цифровой подписи.
Для случаев, когда требуется аутентификация и конфиденциальность для схемы коммуникации ЭВМ-ЭВМ, может быть применено шифрование, базирующееся на симметричной или асимметричной схеме, или даже на их комбинации. Использование асимметричной криптографии упрощает управление раздачей ключей. Каждая ЭВМ шифрует свою информацию перед отправкой, безопасность же внутри машины обеспечивается средствами операционной системы ЭВМ.
В некоторых случаях, возможно включающих электронную почту, может оказаться желательным обеспечить безопасность в пределах приложения на уровне пользователь-пользователь, а не ЭВМ-ЭВМ. Безопасная почта PEM использует именно этот подход [Linn93, Kent93, Balenson93, Kaliski93].
Аутентификационные механизмы, не уязвимые для пассивных атак
По мере расширения применения сетей растет необходимость более жесткой аутентификации. В открытых сетях большое число пользователей могут получить доступ к информации, переносимой по сети. При желании пользователь может сымитировать ситуацию, при которой посланная им информация будет восприниматься, как посланная другим сетевым объектом.
Более мощные аутентификационные системы используют вычислительные возможности партнеров, участвующих в процессе аутентификации. Аутентификация может быть однонаправленной, например аутентификация пользователей в вычислительной системе, или она может быть взаимной, когда оба партнера должны идентифицировать друг друга. Некоторые системы аутентификации используют криптографические методы и формируют общий секретный код (например, ключ сессии), который может быть использован при последующем обмене. Например, пользователю после завершения процесса аутентификации может быть предоставлен аутентификационный билет, который может быть использован для получения других услуг без дополнительной аутентификации. Эти системы аутентификации могут также обеспечить, когда требуется, конфиденциальность (используя шифрование) при передаче данных по незащищенным сетям.
Аутентификационные механизмы, уязвимые для пассивных атак
Простая проверка пароля является наиболее общей формой аутентификации. Простые аутентификационные проверки имеют различные формы: ключ может быть паролем, запомненным пользователем, он может быть физическим или электронным объектом, принадлежащим пользователю, он может быть уникальной биологической характеристикой. Простые аутентификационные системы считаются "раскрывающими", так как, если ключ передается по сети, он может быть перехвачен злоумышленником. Имеются сообщения об успешных пассивных атаках в Интернет с помощью “расколотых” уже ЭВМ [CERT94]. Механизмы раскрывающей аутентификации уязвимы для атак “воспроизведения”. Ключи доступа могут быть запомнены в атакуемой машине и при наличии бреши в системе безопасности можно получить доступ ко всем паролям. Обычно форма хранения паролей допускает их сверку, но не чтение.
Не раскрывающие парольные системы созданы для предотвращения атак воспроизведения. Разработано несколько систем для генерации не раскрываемых паролей. Система аутентификации S/Key (TM), разработанная в Bellcore генерирует много одноразовых паролей из одного секретного ключа [Haller94]. Она не использует физических объектов (token), поэтому удобна для аутентификации машина-машина. Аутентификация S/Key не требует запоминания секретного ключа пользователя, что является преимуществом при работе с ненадежными вычислительными системами. В ее сегодняшнем виде система S/Key уязвима для переборных атак со словарем в случае неудачного выбора пароля. Система CHAP протокола PPP не является раскрывающей, но применима только локально [LS92, Simpson93].
Авторизация
Авторизация относится к процессу предоставления привилегий процессам и в конечном итоге пользователям. Это отличается от аутентификации, которая осуществляет идентификацию пользователя. После надежной идентификации привилегии, права, принадлежности и разрешения определенных действий определяются авторизацией.
Явное перечисление авторизованных действий для каждого пользователя (и процесса пользователя) с учетом всех ресурсов (объектов) в разумной системе невозможно. В реальной системе используются определенные методики для упрощения процесса предоставления и проверки авторизации.
Один подход, популяризованный системами UNIX, заключается в присвоении каждому объекту трех классов пользователей: владелец, группа и прочий мир. Владельцем является либо создатель объекта, либо пользователь, назначенный администратором. Разрешения пользователя (чтение, запись и исполнение) предоставляются только ему. Группой является объединение пользователей, которые совместно владеют объектом. Групповыми разрешениями могут быть чтение, запись и исполнение. К остальному миру относятся все, кроме перечисленных выше. Для них может быть разрешено (или запрещено) чтение, запись и исполнение.
Другим подходом является привязка к объекту списка, в котором перечислены идентификаторы всех разрешенных пользователей (или групп). Это ACL (Access Control List – список управления доступом). Преимущества ACL заключаются в том, что они легко создаются и обслуживаются (один список на объект) и очень легко визуально проверить, кто имеет доступ и к чему. Недостатком является необходимость дополнительных ресурсов, необходимых для запоминания таких списков, для больших систем нужно огромное число списков.
Базовый подход
Это руководство написано, чтобы создать базовое руководство для разработки системы безопасности для вашего узла. Одним из общих подходов сформулирован Файтесом и др. [Fites 1989] и включает в себя следующие шаги:
(1) Определение того, что вы пытаетесь защитить.
(2) Выявление того, от чего вы пытаетесь защититься.
(3) Выявление того, откуда и какие исходят угрозы.
(4) Осуществление мер, которые должны защитить ваши данные и систему эффективным образом.
(5) Постоянное отслеживание процесса и внесение улучшений всякий раз, когда обнаруживаются слабости.
Большая часть данного документа концентрируется на пункте 4, но и другие пункты не могут игнорироваться, если в вашем узле необходимо реализовать эффективный план безопасности. Общеизвестно, что цена обеспечения безопасности должна быть ниже, чем стоимость восстановления после разрушения системы. Стоимость в данном контексте должна включать в себя денежные издержки, потери доверия и репутации и, возможно, какие-то менее очевидные моменты. Без разумного осознания того, что вы должны защитить и откуда и какие исходят угрозы, следование этому правилу может быть затруднительным.
Базовый размер блока
Базовым блоком данных считается один байт (т.e. 8 бит). Многобайтовые информационные элементы представляют собой объединение последовательности байтов слева направо и сверху вниз. Многобайтовые элементы извлекаются из байтового потока (используя нотацию Си) следующим образом:
value = (байт[0] << 8*(n-1)) | (байт[1] << 8*(n-2)) | ... | байт[n-1];
Этот порядок байтов для многобайтовых последовательностей является стандартным для сетей (big endian).
Беспроводные (радио) каналы и сети
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Применение электромагнитных волн для телекоммуникаций имеет уже столетнюю историю. Спектр используемых волн делится на ряд диапазонов, приведенных в таблице 3.3.1.
Таблица 3.3.1.
| Номер | Название диапазона | Частота | Длина волны |
| 1 | Высокочастотный | 3 – 30 МГц | 100 – 10 м |
| 2 | VHF | 50 - 100 Мгц | 6 - 3 м |
| 3 | УВЧ (UHF) | 400-1000 МГц | 75-30 см |
| 4 | Микроволновый |
3 109 – 1011 Гц |
10 см – 3 мм |
| 5 | Миллиметровый | 1011 – 1013Гц | 3 мм – 0,3 мм |
| 6 | Инфракрасный | 1012 – 6 1014 | 0,3 мм – 0,5 m |
Далее следуют диапазоны видимого света, ультрафиолета, рентгеновских и гамма-лучей. Диапазоны часто, используемые различными каналами связи показаны на рис. 3.3.1.
Рис. 3.3.1. Диапазоны частот различных телекоммуникационных каналов.
Если не используется направленная антенна и на пути нет препятствий, радиоволны распространяются по всем направлениям равномерно и сигнал падает пропорционально квадрату расстояния между передатчиком и приемником (удвоение расстояния приводит к потерям 6дБ). Радио каналы для целей передачи информации используют частотные диапазоны 902-928 МГц (расстояния до 10 км, пропускная способность до 64кбит/с), 2,4 ГГц и 12 ГГц (до 50 км, до 8 Мбит/с). Они используются там, где не существует кабельных или оптоволоконных каналов или их создание по каким-то причинам невозможно или слишком дорого. Более низкие частоты (например, 300 МГц) мало привлекательны из-за ограничений пропускной способности, а большие частоты (>30 ГГц) работоспособны для расстояний не более или порядка 5км из-за поглощения радиоволн в атмосфере. При использовании диапазонов 4, 5 и 6 следует иметь в виду, что любые препятствия на пути волн приведут к их практически полному поглощению. Для этих диапазонов заметное влияние оказывает и поглощение в атмосфере. Зависимость поглощения от длины волны радиоволн показана на рис. 3.3.1а.
Рис. 3.3.1а. Зависимость поглощающей способности земной атмосферы от длины волны
Из рисунка видно, что заметную роль в поглощении радиоволн играет вода.
По этой причине сильный дождь, град или снег могут привести к прерыванию связи. Поглощение в атмосфере ограничивает использование частот более 30 ГГц. Атмосферные шумы, связанные в основном с грозовыми разрядами, доминируют при низких частотах вплоть до 2 МГц. Галактический шум, приходящий из-за пределов солнечной системы дает существенный вклад вплоть до 200 ГГц. Зависимость поглощения радиоволн в тумане и дожде от частоты показана на рис. 3.3.2.
Рис. 3.3.2. Зависимость поглощения радиоволн в тумане и дожде от частоты
Мощность передатчика обычно лежит в диапазоне 50 мВт - 2 Вт. Модемы, как правило, используют шумоподобный метод передачи SST (spread spectrum transmission). Для устройств на частоты 2.4 ГГц и выше, как правило, используются направленные антенны и необходима прямая видимость между приемником и передатчиком. Такие каналы чаще работают по схеме точка-точка, но возможна реализация и многоточечного соединения. На аппаратном уровне здесь могут использоваться радиорелейное оборудование радиомодемы или радио-бриджи. Схема этих устройств имеет много общего. Отличаются они лишь сетевым интерфейсом (см. рис. 3.3.3). Антенна служит как для приема, так и для передачи. Трансивер (приемопередатчик) может соединяться с антенной через специальные усилители. Между трансивером и модемом может включаться преобразователь частот. Модемы подключаются к локальной сети через последовательные интерфейсы типа RS-232 или v.35 (RS-249), для многих из них такие интерфейсы являются встроенными. Отечественное радиорелейное оборудование имеет в качестве выходного интерфейс типа G.703 и по этой причине нуждается в адаптере. Радио-бриджи имеют встроенный Ethernet-интерфейс. Длина кабеля от модема до трансивера лежит в пределах 30-70м, а соединительный кабель между модемом и ЭВМ может иметь длину 100-150м. Трансивер располагается обычно рядом с антенной.
Рис. 3.3.3. Схема оборудования радиоканала передачи данных
Схемы соединения радиомодемов и традиционных модемов совершенно идентичны (см.
рис. 3.3.4).
Рис. 3.3.4. Схема подключения радио-модемов
Кроме уже указанных примеров перспективным полем применения радиомодемов могут стать “подвижные ЭВМ”. Сюда следует отнести и ЭВМ бизнесменов, клиентов сотовых телефонных сетей, и все случаи, когда ЭВМ по характеру своего применения подвижна, например, медицинская диагностика на выезде, оперативная диагностика сложного электронного оборудования, когда необходима связь с базовым отделением фирмы, геологические или геофизические исследования и т.д. Радиомодемы позволяют сформировать сеть быстрее (если не считать времени на аттестацию оборудования, получение разрешения на выбранную частоту и лицензии на использование данного направления канала). В этом случае могут стать доступными точки, лишенные телефонной связи (что весьма привлекательно для условий России). Подключение объектов к центральному узлу осуществляется по звездообразной схеме. Заметное влияние на конфигурацию сети оказывает ожидаемое распределение потоков информации. Если все объекты, подключенные к узлу, примерно эквивалентны, а ожидаемые информационные потоки не велики, можно в центральном узле обойтись простым маршрутизатором, имеющим достаточное число последовательных интерфейсов.
Применение радио-бриджей особенно выигрышно для организаций, имеющих здания, отстоящие друг от друга на несколько километров. Возможно использование этих средств связи и для подключения к сервис-провайдеру, когда нужны информационные потоки до 2 Мбит/с (например, для проведения видео конференций). Если расстояния не велики (<5км), можно воспользоваться всенаправленной антенной (см. рис. 3.3.5).
Рис. 3.3.5. Схема подключения объектов через радио-бриджи с помощью всенаправленной антенны
Все соединяемые объекты (А, Б, В, и Г) должны быть оснащены радио-бриджами. Такая схема подключения эквивалентна с одной стороны кабельному сегменту ethernet, так как в любой момент времени возможен обмен лишь между двумя объектами; с другой стороны радио-бриджи А, Б, В и Г логически образуют много портовый бридж (или переключатель), что исключает загрузку локальных сетей объектов “чужими” пакетами.
Модификации таких схем связи позволяют строить телекоммуникационные системы по схеме сотовых телефонных сетей.
При построении каналов на основе радиорелейных систем или радио-бриджей следует учитывать возможность их взаимного влияния (см. рис. 3.3.6). Проектируя такие каналы в городе и используя направленные параболические антенны, нужно учитывать возможные помехи от зданий и профиля местности. Направленная антенна с площадью А обеспечивает усиление сигнала:
Угол излучения q такой антенны с радиусом R равен 0,61 l/R. Отсюда видно, что чем больше радиус, тем больше усиления и уже угол излучения и чувствительности.
Предельные расстояния для радио каналов приводятся поставщиками в предположении, что в пределах первой зоны Френеля каких-либо физических помех нет. При звездообразной схеме каналов (как на рис. 3.6.) нужно по возможности выполнить требования на минимальное расстояние между принимающими антеннами d (оно должно быть больше определенного значения, зависящего от апертуры антенны и расстояния между передатчиком и приемником).
Рис. 3.3.6.
Это расстояние определяется расходимостью (a) радиолуча и используемой длиной волны. Если это требование не выполнимо, следует в смежных каналах использовать разные длины волн. Диаграмма излучения направленной антенны показана на рис. 3.3.7 (стрелкой отмечено основное направление излучения). Эту диаграмму следует учитывать при выборе места установки антенны, особенно при использовании большой мощности излучения. Иначе один из лепестков излучения может прийтись на места постоянного пребывания людей (например, жилье). Учитывая эти обстоятельства, проектирование такого рода каналов целесообразно поручить профессионалам.
Рис. 3.3.7. Диаграмма излучения параболической антенны
Стоимость антенного комплекса обычно пропорциональна кубу диаметра антенны. Стандартная антенна intelsat имеет диаметр 30 м и угол излучения 0,010.
Спутниковые каналы используют диапазоны перечисленные в таблице 3.3.2.
Таблица 3.3.2.
Частотные диапазоны, используемые для спутниковых телекоммуникаций
| Диапазон | Канал снижения (downlink)[ГГц] | Канал подъема (uplink)[ГГц] | Источники помех |
| С | 3,7-4,2 | 5,925-6,425 | Наземные помехи |
| ku | 11,7-12,2 | 14,0-14,5 | Дождь |
| ka | 17,7-21,7 | 27,5-30,5 | Дождь |
Рис. 3.3.8. Схема спутниковой связи VSAT
Терминальные антены vsat имеют диаметр 1-1,5 м и излучаемую мощность 1-4 Вт, обеспечивая широкополосность до 64 кбит/с. Такие небольшие антенны не позволяют таким терминалам общаться непосредственно. На рис. 3.3.8. станции А и Б не могут непосредственно друг с другом. Для передачи данных используется промежуточная станция с большой антенной и мощностью (на рис. антенна В). Для создания постоянных каналов телекоммуникаций служат геостационарные спутники, висящие над экватором на высоте около 36000 км.
Теоретически три таких спутника могли бы обеспечить связью практически всю обитаемую поверхность земли (см. рис. 3.3.9.). Спутники, работающие на одной и той же частоте должны быть разнесены по углу на 2o. Это означет что число таких спутников не может быть больше 180. В противном случае они должны работать в разных частотных диапазонах.
При работе в ku- диапазоне угловое расстояние между спутниками можно сократить до 1o. Влияние дождя можно минимизировать, используя далеко отстоящие наземные станции (размеры урагана конечны!).
Рис. 3.3.9.
Реально геостационарная орбита переполнена спутниками различного назначения и национальной принадлежности. Обычно спутники помечаются географической долготой мест, над которым они висят. На практике геостационарный спутник не стоит на месте, а выполняет движение по траектории, имеющей вид цифры 8. Угловой размер этой восьмерки должен укладываться в рабочую апертуру антенны, в противном случае антенна должна иметь сервопривод, обеспечивающий автоматическое слежение за спутником. Из-за энергетических проблем телекоммуникационный спутник не может обеспечить высокого уровня сигнала. По этой причине наземная антенна должна иметь большой диаметр, а приемное оборудование низкий уровень шума. Это особенно важно для северных областей, для которых угловое положение спутника над горизонтом невысоко (это особенно существенно для широт более 700), а сигнал проходит довольно толстый слой атмосферы и заметно ослабляется. Спутниковые каналы могут быть рентабельны для областей, отстоящих друг от друга более чем на 400-500 км (при условии что других средств не существует). Правильный выбор спутника (его долготы) может заметно снизить стоимость канала.
Число позиций для размещения геостационарных спутников ограничено. В последнее время для телекоммуникаций планируется применение так называемых низколетящих спутников (<1000 км; период обращения ~1 час). Эти спутники движутся по эллиптическим орбитам и каждый из них по отдельности не может гарантировать стационарный канал, но в совокупности эта система обеспечивает весь спектр услуг (каждый из спутников работает в режиме “запомнить и передать”). Из-за малой высоты полета наземные станции в этом случае могут иметь небольшие антенны и малую стоимость. Смотри также .
Типичный спутник имеет 12-20 транспондеров, каждый из которых имеет полосу 36-50 МГц.
Один транспондер может обеспечить информационный поток в 50 Мбит/с или 800 64-килобитных каналов цифровой телефонии. Два транспондера могут использовать разную поляризацию сигнала и по этой причине работать на одной и той жк частоте. Каждый телекоммуникационный спутник снабжен несколькими антеннами. Низходящий луч может быть сфокусирован на достаточно ограниченную область на земле (с диаметром несколько сот км). Что также упрощает осуществление двунаправленного обмена.
Существует несколько способов работы совокупности наземных терминалов со спутником. При этом может использоваться мультиплексирование по частоте (FDM), по времени (TDM), CDMA (Code Division Multiple Access), ALOHA или метод запросов.
Схема запросов предполагает, что наземные станции образуют логическое кольцо, вдоль которого двигается маркер. Наземная станция может начать передачу на спутник, лишь получив этот маркер.
Простая система ALOHA (разработана группой Нормана Абрамсона из Гавайского университета в 70-х годах) позволяет каждой станции начинать передачу тогда, когда она этого захочет. Такая схема с неизбежностью приводит к столкновениям. Связано это отчасти с тем, что передающая сторона узнает о столкновении лишь спустя ~270 мсек. После столкновения станция ожидает некоторое псевдослучайное время и совершает повторную попытку передачи еще раз. Такой алгоритм доступа обеспечивает эффективность использования канала на уровне около 18%, что совершенно недопустимо для таких дорогостоящих каналов, как спутниковые. По этой причине чаще используется доменная версия системы ALOHA, которая удваивает эффективность. Одна наземная станция (эталонная) периодически посылает специальный сигнал, который используется всеми участниками для синхронизации. Если длина временного домена равна DT, тогда домен с номером k начинается в момент времени kDT по отношению к упомянутому выше сигналу. Так как часы разных станций работают немного по разному, необходима периодическая ресинхронизация. Другой проблемой является разброс времени распространения сигнала для разных станций.
Метод мультиплекcирования по частоте (FDM) является старейшим и наиболее часто используемым. Типичный транспондер с полосой 36 Мбит/с может использован для получения 500 64кбит/с ИКМ-каналов, каждый из которых работает со своей уникальной частотой, чтобы исключить интерференцию с другими. Соседние каналы должны отстоять на достаточном расстоянии друг от друга. Кроме того, должен контролироваться уровень передаваемого сигнала, так как при слишком большой выходной мощности могут возникнуть интерференционные помехо в соседнем канале. Если число станций невелико и постоянно, частотные каналы могут быть распределены стационарно. Но при переменном числе терминалов или при заметной флуктуации загрузки приходится переходить на динамическое распределение ресурсов. Одним из механизмов такого распределение имеет название SPADE, он использовался в первых версиях систем связи на базе INTELSAT. Каждый транспондер системы SPADE содержит 794 симплексных ИКМ-каналов по 64-кбит/c и один сигнальный канал с полосой 128 кбит/c. ИКМ-каналы используются попарно для обеспечения полнодуплексной связи. При этом восходящий и ниcходящий каналы имеют полосу по 50 Мбит/с. Сигнальный канал делится на 50 доменов по 1 мсек (128 бит). Каждый домен принадлежит одной из наземной станции, число которых не превышает 50. Когда станция готова к передаче, она произвольным образом выбирает неиспользуемый канал и записывает номер этого канала в очередной свой 128 битный домен. Если один и тот же канал попытаются занять две или более станции происходит столкновение и они вынуждены будут повторить попытку позднее.
Метод мультиплекирования по времени сходен с FDM и довольно широко применяется на практике. Здесь также необходима синхронизация для доменов. Это делается как и в доменной системе ALOHA c помощью эталонной станции. Присвоение доменов наземным станциям может выполняться централизовано или децентрализовано. Рассмотрим систему ACTS (Advanced Communication Technology Satellite). Система имеет 4 независимых канала (TDM) по 110 Мбит/c (два восходящих и два ниcходящих).
Каждый из каналов структурированы в виде 1- милисекундных кадров, каждый из которых имеет по 1728 временных доменов. Каждый из временных доменов имеет 64-битовое поле данных, что позволяет реализовать голосовой канал с полосой в 64 кбит/c. Управление временными доменами с целью минимизации времени на перемещения вектора излучения спутника предполагает знание географического положения наземных станций. Управление временными доменами осуществляется одной из наземных станций (MCS - Master Control Station). Работа системы ACTS представляет собой трехшаговый процесс. Каждый из шагов занимает 1 мсек. На первом шаге спутник получает кадр и запоминает его в 1728-ячеечном буфере. На втором - бортовая ЭВМ копирует каждую входную запись в выходной буфер (возможно для другой антенны). И, наконец, выходная запись передается наземной станции.
В исходный момент каждой наземной станции ставится в соответствие один временной домен. Для получения дополнительного домена, например для организации еще одного телефонного канала, станция посылает запрос MCS. Для этих целей выделяется специальный управляющий канал емкостью 13 запросов в сек. Существуют и динамические методы распределения ресурсов в TDM (методы Кроузера [Crowther], Биндера [Binder] и Робертса [Roberts]).
Метод CDMA (Code Division Multiple Access) не требует синхронизации и является полностью децентрализованным. Как и другие методы он не лишен недостатков. Во-первых, емкость канала CDMA в присутствии шума и отсутствии координации между станциями обычно ниже, чем в случае TDM. Во-вторых, система требует быстродействующего и более дорогого оборудования.
Безопасная почта PGP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
В связи с массовым внедрением электронной почты и, в перспективе, полным вытеснением традиционной, проблема конфиденциальности доставки электронных сообщений становится крайне актуальной. В последние годы разработано несколько почтовых систем, предоставляющих эту конфиденциальность. Примером такой системы может служить PEM - почта с улучшенной защитой от несанкционированного доступа (PEM - Privacy Enhanced Mail, RFC-1421, 1422, 1423 и 1424). Первая разработка в области электронной криптографии относится к 1976 году, когда была создана система Диффи-Хелмана (Diffie-Hellman) с общедоступным шифровальным ключом. Позднее, в 1977 году Ривестом, Шамиром и Адлеманом была предложена двух ключевая система RSA (Rivest-Shamir-Adleman). Эта разработка была выполнена под патронажем Национального научного фонда США (NSF) и в 1983 году запатентована в США.
PEM является стандартом Интернет для улучшения защищенности электронной почты. PEM использует криптографическую технику для обеспечения контроля правильности передачи сообщения, защищенности и идентификации. Стандарт позволяет вам знать, что полученное сообщение не было изменено, быть уверенным, что ваше сообщение будет получено именно тем и только тем, кому было адресовано.
Предусмотрена интеграция MIME (Multipurpose Internet Mail Extensions) и PEM. Существует подписной лист (LISTSERV) для пользователей, интересующихся вопросами развития и использования PEM. Для подписки необходимо послать соответствующее сообщение по адресу pem-dev-request@tis.com.
Для пользователей PEM имеется еще один подписной лист: tispem-users@tis.com. Для подписки следует направлять заявки по адресу: tispem-users-request@tis.com. С вопросами по использованию TIS/PEM следует обращаться в tispem-support@tis.com.
Имеется версия программного обеспечения PEM в свободном доступе, например, TIS/PEM V7.0 (UNIX, только для США и Канады). Эта версия содержит в себе:
поддержку однопользовательского режима с возможностью совместного использования некоторых процедурных модулей;
легко читаемую базу данных для каждого пользователя;
поддержку для большего числа баз данных;
гибкую систему управления доступом;
гибкую систему поверки;
системы верификации, кодирования, декодирования и электронной подписи, совместимые с другими почтовыми серверами;
поддержку интеграции MIME-PEM.
Система TIS/PEM доступна через анонимное FTP в США и Канаде по адресу: ftp.tis.com pub/PEM/README; pub/PEM/LICENSE; pub/PEM/BUGS. Файл README содержит дополнительные инструкции по применению PEM.
Несравненно большей популярностью пользуется конфиденциальная почтовая система PGP (Pretty Good Privacy – замечательная конфиденциальность). История создания PGP довольно драматична (см. http://www.dcs.ex.ac.uk/~aba/timeline/. Создателем PGP является Фил Циммерман (США, 1991 год). PGP базируется на двух ключевой системе шифрования RSA и алгоритме IDEA (International Data Encryption Algorithm, предложен Ксейа Лайем и Джеймсом Массейем, Швейцария). Творение Циммермана было встречено без энтузиазма Агентством Национальной Безопасности США и против него было возбуждено уголовное дело. Хотя АНБ и могущественно, здравый смысл и закон в данном случае восторжествовали. Что же касается патента на RSA, он не является международным и вся ответственность за использование программ, базирующихся на данном алгоритме, лежит на пользователе (юридически ситуация весьма запутана). В России применение любой системы шифрования (формально даже архивирование!) требует лицензирования. Все правительства любят все держать в тайне, но не любят, когда кто-то пытается хранить в тайне что-то от правительства (даже если это любовные письма; если вы интересуетесь юридической стороной проблемы использования PGP, смотрите в http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm. Чему здесь удивляться, ведь история “черных кабинетов” (в том числе и в России) исчисляется столетиями.
PGP версия 2.5 (http://www.ifi.uio.no/~staalesc/PGP ) (и более поздние используют RSAREF 1.0 вместо MPILIB) представляет собой публично доступный (легальный!) пакет электронной почты со встроенной системой шифрования сообщений.
Пакет обеспечивает конфиденциальность переписки и пересылки файлов. Конфиденциальность заключается в том, что только лица, кому адресовано послание или файл, смогут его прочесть. PGP поддерживает технологию электронной подписи, гарантирующей получателю, что сообщение пришло именно от вас. Предусмотрен контроль неизменности сообщения в процессе доставки (принцип сходен с идеей CRC). При этом не требуется каких-либо секретных каналов для пересылки ключей кодирования. Именно эта схема являлась до недавнего времени основной. Главный ее недостаток - необходимость транспортировки секретного ключа. PGP использует технику шифрования с общедоступными ключами, совмещая удобства системы кодирования RSA с быстродействием традиционных методов. Существуют коммерческие версии PGP, встроенные в известные текстовые редакторы WORD и другие. В PGP предусмотрена схема, резко ускоряющая дешифровку. Возможно применение большого набора пар общедоступных и секретных ключей. Имеется система авторизации, контролирующая доступ к ключам и препятствующая использованию краденных секретных ключей. Предусмотрены и другие методы повышения секретности пересылки любых сообщений.
Пакет работает под MS-DOS, UNIX, Windows. Данная версия позволяет посылать сообщение сразу нескольким адресатам. Пакет имеет встроенную справочную систему (Help на английском, французском и испанском языках. Описания, инструкции по постановке и использованию можно найти по адресу: FTP ftp.uu.net/pub/security/pgp.
Безопасное ядро (SSH)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены “посторонние” машины. Для того чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа “безопасное ядро” SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH использует для шифрования как открытого ключа так и симметричной схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы как telnet, rlogin, rsh и rcp. Эта программа для ЭВМ, на которых установлена, шифрует также и сессии X Windows. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или HTTP. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты.
Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата.
Для формирования SSH-прокси на удаленном WEB- сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию –L:
SSH –L5678:www.pod.potol.com:80 www.pod.potol.com
Аргумент, следующий после флага опции -L имеет формат:
<локальный порт>:<удаленная ЭВМ>:<удаленный порт>.
Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду logout на удаленной ЭВМ. Общедоступную версию SSH можно найти по адресу: . Информацию о коммерческих версиях для Windows и Macintosh можно найти на сервере: .
Безопасность WEB-серверов
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
WEB-сервер достаточно сложная и потому уязвимая для атак программа. Причем угрозы могут исходить из самых неожиданных мест. Так в конце июня 1997 года было обнаружено, что Windows-95 (и NT) “повисает” (полный перечень причин повисания этой системы может занять целый том) при приходе на ее вход ICMP-пакета с длиной, которая не соответствует значению, указанному в его поле заголовка Длина.
WEB-сервер, также как любая сеть должен иметь свою, желательно записанную на бумаге политику безопасности. Это должен быть достаточно простой документ типа приведенного ниже.
Доступ к WEB-серверу имеет пять уровней:
Общедоступный с возможностью только чтения всех URL за исключением тех, что помещены в каталогах /private.
Доступ сотрудников фирмы или организации, которой принадлежит сервер. Здесь также допустимо только чтение, но доступны и секции каталога /private.
Разработчики WEB-сервера. Имеют возможность модифицировать содержимое сервера, инсталлировать CGI-скрипты, прерывать работу сервера.
Администраторы узла (сервера). Имеют те же привилегии, что и разработчики, но могут также реконфигурировать сервер и определять категорию доступа.
Системные администраторы. Имеют идентичные привилегии с администраторами сервера.
Для получения доступа на уровне 3-5 необходимо письменное разрешение директора организации или его заместителя по информационным системам. Доступ уровня 2 автоматически получают все сотрудники организации или фирмы при авторизации. Администраторы могут аннулировать авторизацию по решению заместителя директора по информационным системам, а при чрезвычайных обстоятельствах самостоятельно, но с последующим уведомлением руководства. Работа с локальной консоли WEB-сервера разрешается только администраторам. Удаленная работа администраторам запрещена, они должны работать только с локального терминала. CGI-скрипты устанавливаются на сервер после их проверки и одобрения как минимум двумя членами группы администраторов. Скрипты, исходные тексты которых недоступны, устанавливаются только по решению заместителя директора по информационным системам.
Информация из каталогов /private, которая считается конфиденциальной, доступна только с терминала самой ЭВМ.
При работе с WEB-сервером не допускается доступ к базам данных или файлам, если для этого не имеется соответствующего разрешения.
Описание политики безопасности должно включать указание периода формирования резервных копий содержимого сервера, описания допустимых сетевых услуг и время профилактических остановок. Включается сюда перечень видов обязательного мониторинга сервера и просмотра дневника посещений.
Приведенный текст описания политики безопасности может варьироваться в широких пределах, он зависит от используемой ОС и набора сетевых утилит.
Наиболее безопасной сетевой средой считается Macintosh OS. Это связано с тем, что она не включает в себя интерпретатора команд, не поддерживает скрипты и не предоставляет каких-либо дополнительных сетевых услуг, неавторизованный просмотр WEB-страниц на Макинтоше практически не возможен.
Системы Windows NT и UNIX обладают сопоставимыми и достаточно высокими уровнями безопасности. Большое число сообщений о дефектах безопасности UNIX свидетельствует о его массовом использовании.
Теперь рассмотрим, что нужно сделать, чтобы обеспечить максимально возможную безопасность WEB-cервера.
Выбрать наиболее безопасную ОС и сконфигурировать ее с учетом требования безопасности. Использовать все известные корректирующие программы, выпущенные разработчиком ОС.
Организовать мониторирование любой подозрительной активности на сервере (активность в ночное время, многократные попытки авторизации и т.д.).
Контролировать доступ к конфиденциальным документам. Доступ к таким документом должен быть разрешен только ограниченному числу пользователей. Доступ к таким частям сервера должен быть организован с использованием протокола SSL.
Тщательно разрабатывать и проверять используемые CGI-скрипты и аплеты.
Установить жесткие требования к доступу для выполнения различных операций, особенно для модификации содержимого и конфигурации сервера.
Защитить локальную сеть от WEB-сервера. Исключить возможность проникновения к жизненно важным ресурсам сети через WEB-сервер, например, с помощью Firewall.
Отслеживать вновь обнаруженные слабости используемой ОС и программного обеспечения сервера. Делайте это чаще, если вам не безразлична безопасность вашего сервера, не надейтесь, что все хакеры ленивее вас. Ссылки на различные серверы, где публикуется такая информация, можно найти в конце раздела 6.
При работе с ОС Windows NT следует отключить доступ TCP/IP от услуг NETBIOS. Это может быть сделано с помощью Firewall, блокировкой доступа к портам 137 и 138 для UDP и TCP. Можно решить эту проблему отключения NETBIOS от TCP/IP драйвера переконфигурировав Windows NT.
Если WEB-сервер нуждается в контроле доступа, то в настоящее время (в HTTP/1.1) имеется две возможности. Первая (basic) - предполагает традиционный ввод и передачу по сети имени клиента и пароля. Эта схема проста, но допускает перехват параметров доступа (а между клиентом и сервером может быть достаточно много промежуточных узлов). Вторая схема (digest) для пользователя выглядит аналогично, но вводимое имя и пароль не передаются по сети непосредственно. На их базе формируется дайджест MD5, который пересылается по сети и используется для идентификации клиента.
Блочный шифр CBC
Для блочных шифров (таких как RC2 или DES), функции шифрования и MAC преобразуют структуры TLSCompressed.fragment в блоки структур TLSCiphertext.fragment или обратно.
block-ciphered struct {
| opaque content[TLSCompressed.length]; | |
| opaque MAC[CipherSpec.hash_size]; | |
| uint8 padding[GenericBlockCipher.padding_length]; | |
| uint8 padding_length; | |
| } GenericBlockCipher; |
MAC генерируется, как это описано в разделе 6.2.3.1.
| Padding |
Заполнитель, который добавлен, чтобы сделать длину исходного текста целой кратной длине блока блочного шифра. Заполнитель может иметь длину вплоть до 255 байт. Длины больше необходимой могут оказаться желательными, для того чтобы блокировать атаки на протокол, базирующийся на анализе длин сообщений. Каждый uint8 в векторе заполняющих данных должен быть заполнен значением длины. |
| padding_length | Длина заполнения должна быть такой, чтобы общий размер структуры GenericBlockCipher являлся кратным длине блока шифра. Диапазон легальных значений лежит в диапазоне 0-255, включительно. Эта длина специфицирует длину поля заполнителя, исключая само поле padding_length. |
Длина шифрованных данных (TLSCiphertext.length) на единицу больше чем сумма TLSCompressed.length, CipherSpec.hash_size и padding_length.
Пример. Если длина блока равна 8 байт, длина содержимого (TLSCompressed.length) равна 61 байтов, а длина MAC равна 20 байтов, длина до заполнения составляет 82 байта. Таким образом, длина заполнения по модулю 8 должна быть равна 6, для того чтобы сделать полную длину четной, кратной 8 байтам (длина блока). Длина заполнения может быть 6, 14, 22 и т.д. до 254. Если бы длина заполнения была минимально необходимой (6), заполнитель имел бы 6 байтов, каждый из которых содержал число 6. Таким образом, последние 8 октетов GenericBlockCipher до блочного шифрования были бы xx 06 06 06 06 06 06 06, где xx последний октет MAC.
Для блочного шифра в режиме CBC (Cipher Block Chaining) вектор инициализации (IV) для первой записи генерируется с другими ключами и секретными кодами, когда параметры безопасности заданы. IV для последующих записей равен последнему блоку шифрованного текста предыдущей записи.
Будущие направления
Просматривается тенденция внедрения все более строгих механизмов аутентификации. Следует ожидать введения не раскрывающей пароли аутентификации и более широкого использования механизмов с общедоступным ключом. Растет важность аутентификации сессий и процессов, проблема целостности и конфиденциальности сообщений при передаче по сетевым каналам. Так как коммуникации ЭВМ-ЭВМ становятся все более важными, протоколы связи человек-машина становятся менее существенными.
Использование криптосистем с общедоступным ключом для аутентификации пользователь-ЭВМ упрощает многие аспекты, но хранение простых паролей, а также общедоступных и секретных ключей остается актуальной проблемой. Следует учитывать, что размер общедоступного ключа, используемого в настоящее время, по меньшей мере, составляет 500 бит. В будущем, вероятно, будут применяться еще более длинные ключи. Таким образом, пользователи могут хранить свои ключи в виде пригодном для электронного считывания. Использование ROM, такой как флоппи-диск или магнитная карточка может решить эту проблему, но тогда пользователь неизбежно доверяет свои ключи считывающему устройству. Применение смарт-карты, совмещающей память и программу, более предпочтительно. Такие приборы могут обеспечить аутентификацию без риска разглашения секретных кодов, которые они хранят. Они могут также взаимодействовать с пользователем, осуществляя простую аутентификацию при разблокировании карты. Применение криптосистем с общедоступным ключом при аутентификации ЭВМ-ЭВМ лишено проблем запоминания ключей, которые характерны для интерфейсов человек-машина. Многопользовательская ЭВМ может запоминать свои ключи в области памяти, защищенной от доступа пользователей.
Если рассматривать существующие симметричные алгоритмы как одно-ключевые, а асимметричные, такие как RSA в качестве двухключевых систем, можно предположить появление в будущем N-ключевых методик (где N больше 2). Если бы такая N-ключевая технология существовала, она могла бы использоваться для реализации масштабируемых протоколов для рассылки ключей в случае мультикастинга.
В настоящее время ведется разработка технологии CBT (Core Based Tree), предназначенной для решения подобной задачи [BFC93].
Ссылки
[Anderson84] | Anderson, B., "TACACS User Identification Telnet Option", RFC 927, BBN, December 1984. |
[Balenson93] | Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993. |
[BFC93] | Ballardie, A., Francis, P., and J. Crowcroft, "Core Based Trees (CBT) An Architecture for Scalable Inter-Domain Multicast Routing", Proceedings of ACM SIGCOMM93, ACM, San Franciso, CA, September 1993, pp. 85-95. |
[Bellovin89] | Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. |
[Bellovin92] | Bellovin, S., "There Be Dragons", Proceedings of the 3rd Usenix UNIX Security Symposium, Baltimore, MD, September 1992. |
[Bellovin93] | Bellovin, S., "Packets Found on an Internet", ACM Computer Communications Review, Vol. 23, No. 3, July 1993, pp. 26-31. |
[BM91] | Bellovin S., and M. Merritt, "Limitations of the Kerberos Аутентификация System", ACM Computer Communications Review, October 1990. |
[Bishop] | Bishop, M., "A Security Analysis of Version 2 of the Network Time Protocol NTP: A report to the Privacy & Security Research Group", Technical Report PCS-TR91-154, Department of Mathematics & Computer Science, Dartmouth College, Hanover, New Hampshire. |
[CB94] | Cheswick W., and S. Bellovin, "Chapter 10: An Evening with Berferd", Firewalls & Internet Security, Addison-Wesley, Reading, Massachusetts, 1994. ISBN 0-201-63357-4. |
[CERT94] | Computer Emergency Response Team, "Ongoing Network Monitoring Attacks", CERT Advisory CA-94:01, available by anonymous ftp from cert.sei.cmu.edu, 3 February 1994. |
[CFSD88] | Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1067, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, Proteon, Inc., August 1988. |
[DH76] | Diffie W., and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Volume IT-11, November 1976, pp. 644-654. |
[GM93] | Galvin, J., and K. McCloghrie, "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993. |
[Haller94] | Haller, N., "The S/Key One-time Password System", Proceedings of the Symposium on Network & Distributed Systems Security, Internet Society, San Diego, CA, February 1994. |
[Kaufman93] | Kaufman, C., "Distributed Аутентификация Security Service (DASS)", RFC 1507, Digital Equipment Corporation, September 1993. |
[Kaliski93] | Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, RSA Laboratories, February 1993. |
[Kantor91] | Kantor, B., "BSD Rlogin", RFC 1258, Univ. of Calif San Diego, September 1991. |
[Kent93] | Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN, IAB IRTF PSRG, IETF PEM, February 1993. |
[KN93] | Kohl, J., and C. Neuman, "The Kerberos Network Аутентификация Service (V5)", RFC 1510, Digital Equipment Corporation, USC/Information Sciences Institute, September 1993. |
[Linn93] | Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Аутентификация Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993. |
[Linn93a] | Linn, J., "Common Аутентификация Technology Overview", RFC 1511, Geer Zolot Associate, September 1993. |
[LS92] | Lloyd B., and W. Simpson, "PPP Аутентификация Protocols", RFC 1334, L&A, Daydreamer, October 1992. |
[LR91] | Lougheed K., and Y. Rekhter, "A Border Gateway protocol 3 (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991. |
[Mills92] | Mills, D., "Network Time Protocol (Version 3) - Specification, Implementation, and Analysis", RFC 1305, UDEL, March 1992. |
[NBS77] | National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standards Publication 46, Government Printing Office, Washington, DC, 1977. |
[NS78] | Needham, R., and M. Schroeder, "Using Encryption for Аутентификация in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, ёDecember 1978. |
[NS87] | Needham, R., and M. Schroeder, " Аутентификация Revisited", ACM Operating Systems Review, Vol. 21, No. 1, 1987. |
[PR85] | Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. |
[Moy91] | Moy, J., "OSPF Routing Protocol, Version 2", RFC 1247, Proteon, Inc., July 1991. |
[RSA78] | Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public Key Crypto-systems", Communications of the ACM, Vol. 21, No. 2, February 1978. |
[Rivest92] | Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. |
[Simpson93] | Simpson, W., "The Point to Point Protocol", RFC 1548, Daydreamer, December 1993. |
[SNS88] | Steiner, J., Neuman, C., and J. Schiller, "Kerberos: "An Аутентификация Service for Open Network Systems", USENIX Conference Proceedings, Dallas, Texas, February 1988. |
[Stoll90] | Stoll, C., "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage", Pocket Books, New York, NY, 1990. |
[TA91] | Tardo J., and K. Alagappan, "SPX: Global Аутентификация Using Public Key Certificates", Proceedings of the 1991 Symposium on Research in Security & Privacy, IEEE Computer Society, Los Amitos, California, 1991. pp.232-244. |
Цель данной работы
Данный справочник является руководством по определению процедур и политики безопасности для узлов, которые имеют связи с Интернет (однако, предлагаемая информация может оказаться полезной и для узлов, которые пока не соединены с Интернет). Данное руководство перечисляет моменты и факторы, которые следует рассмотреть, при определении своей собственной политики.
Данный справочник предоставляет лишь общие рамки определения политики и процедур безопасности. Для того чтобы достичь эффективности набора процедур и политики, в узле должно быть принято много решений, достигнуто ряд соглашений, после чего это все должно быть успешно внедрено в практику коммуникаций.
Цели
Целями протокола TLS в порядке приоритетности являются:
Криптографическая безопасность. TLS должен использоваться для установления безопасного соединения между двумя партнерами.<
Совместимость. Независимые программисты должны быть способны разрабатывать приложения, использующие TLS, которые будут способны успешно обмениваться криптографическими параметрами без знания особенностей программ друг друга.
Расширяемость. TLS ищет способ, как при необходимости встроить в систему новые ключи и методы шифрования. Здесь имеются две побочные цели: исключить необходимость создания нового протокола (что может быть сопряжено с введением новых слабых мест) и сделать ненужным внедрение новой библиотеки, обеспечивающей безопасность.
Относительная эффективность. Криптографические операции требуют больших мощностей ЦПУ, особенно этим славятся операции с открытыми ключами. По этой причине, протокол TLS имеет опционную схему кэширования сессии, что позволяет уменьшить число соединений, устанавливаемых с использованием новых временных буферов. Были приняты меры, чтобы уменьшить сетевую активность.
Цели данного документа
Этот документ и сам протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape. Различие между этим протоколом и SSL 3.0 не значительны, но они вполне достаточны, чтобы сделать TLS 1.0 и SSL 3.0 не совместимыми (хотя TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0). Этот документ предназначен, прежде всего, для читателей, которые будут создавать протокольные приложения, и осуществлять их криптографический анализ. Спецификация была написана именно с такими намерениями и именно для этих двух групп разработчиков. Для этой цели многие правила и структуры данных, зависимые от алгоритма, включены в текст (а не в приложение), обеспечивая более легкий к ним доступ.
Цели политики безопасности
Главной целью политики безопасности является информирование пользователей, персонал и менеджеров об их обязанностях по защите технологии и информации. Политика должна специфицировать механизмы, через которые могут быть реализованы соответствующие требования. Другой целью является обеспечение базиса при конфигурировании и аудите компьютерных систем и сетей в соответствии с политикой. Следовательно, попытка использовать набор средств безопасности в отсутствии определенной политики безопасности является бессмысленным.
Политика использования AUP (Appropriate Use Policy) может также быть частью политики безопасности. Она должна определять, что можно и чего нельзя делать с различными компонентами системы, включая типы трафика, разрешенные в сетях. AUP должна быть максимально прозрачной (заданной явно), чтобы избежать неопределенности и недоразумений. Например, AUP может перечислить какие-то запрещенные группы новостей USENET. (Заметим: AUP для некоторых узлов является приемлемой политикой использования (Acceptable Use Policy)).
Целостность
Как администратор, вы захотите быть уверены, что информация (например, файлы операционной системы, данные компании и т.д.) не изменялась неавторизованным образом. Это означает, что вы захотите предоставить некоторую гарантию целостности информации в вашей системе. Одним из способов реализации этого является вычисление контрольной суммы исходного файла, запомнив эту контрольную сумму и периодически (или по запросу) проверяя ее, можно убедиться в том, что файл не был модифицирован.
Некоторые операционные системы поставляются с программами контрольного суммирования, например, UNIX-программа суммирования. Однако, они не дают защиты, которая вам на самом деле нужна. Файлы могут быть модифицированы так, что контрольная сумма останется неизменной! Следовательно, мы советуем, чтобы вы использовали криптографически сильную программу, такую как MD5 для вычисления дайджестов, чтобы получить контрольную сумму для контроля целостности.
Существуют другие приложения, где нужно гарантировать целостность, такие как передача почтовых сообщений. Доступны продукты, которые могут предоставить такую возможность.
Числа
Базовый числовой тип данных представляет собой байт без знака (uint8). Все более длинные типы цифровых данных образуются из фиксированной последовательности байт без знака, объединенных вместе, как это описано в разделе 4.1,. Следующие числовые типы являются предопределенными.
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
Все значения здесь и в дальнейшем записываются в 'сетевом порядке' (big-endian); uint32 представленное шестнадцатеричными байтами 01 02 03 04 эквивалентно десятичному значению 16909060.
Что дает хорошая политика безопасности?
Характеристиками хорошей политики безопасности являются:
|
(1) |
Она должна быть реализуема через процедуры системной администрации, публикацию приемлемых руководств по использованию, или другими приемлемыми способами. |
|
(2) |
Она должна быть, где возможно, внедряема посредством специальных устройств и программ и через санкции, где предотвращение угроз технически невозможно. |
|
(3) |
Она должна ясно определять области ответственности пользователей, администраторов и менеджмента. |
Хорошая политика безопасности включает в себя следующие компоненты:
|
(1) |
Инструкции по технологии приобретения компьютерного оборудования, которые разъясняют требования или предпочтения, связанные с безопасностью. Эта инструкция должна прилагаться к существующим рекомендациям по закупкам и закупочной политике. |
|
(2) |
Политику конфиденциальности, которая определяет разумные требования по обеспечению закрытости частной информации, включая мониторинг электронной почты, контроль операций, выполняемых пользователями и доступ к их файлам. |
|
(3) |
Политику доступа, которая определяет права доступа и привилегии с целью защиты определенных объектов от утраты или раскрытия для пользователей оперативного персонала и менеджмента. Она должна предоставить инструкции для внешнего подключения, передачи данных, устройств подключения к сети и для добавления нового программного обеспечения к системе. Она должна также специфицировать любые необходимые сообщения уведомления (например, сообщения подключения должны предоставлять предупреждения об авторизованном использовании и мониторинге канала, а не просто выдавать строку типа "Welcome"). |
|
(4) |
Политику аккаунтинга, которая определяет ответственность пользователей, операционного персонала и менеджмента. Она должна специфицировать возможность аудита и предоставлять инструкции обработки инцидентов (т.e., что делать и с кем связаться, если зарегистрировано вторжение). |
|
(5) |
Политику аутентификации, которая устанавливает эффективную политику паролей и устанавливает инструкции для удаленной аутентификации и использования аутентификационных устройств (например, одноразовых паролей и устройств их генерирующих). |
|
(6) |
Заявление доступности, которое устанавливает пожелания пользователей о доступности определенных ресурсов. Оно должно относиться к избыточности и восстановлению объектов, а также специфицировать часы работы и периоды остановок для обслуживания. Оно должно также включать контактную информацию для информирования о состоянии системы и об отказах. |
|
(7) |
Политику поддержки сети и информационных систем, которая описывает, как персоналу, отвечающему за поддержку внутренней сети и внешних каналов, разрешено использовать технологию доступа. Важный вопрос, который здесь должен быть задан, заключается в том, должен ли быть разрешен внешний доступ и как такой доступ следует контролировать. Другой областью, рассматриваемой здесь, является организация работ с субподрядными фирмами и способ ее управления. |
|
(8) |
Политику сообщений о нарушениях, которая указывает, какой тип нарушений (например, конфиденциальности и безопасности, внутренней или внешней) должен докладываться и кто готовит такие доклады. Доброжелательная атмосфера и возможность анонимного доклада приведет к тому, что вероятность сообщения в случае нарушения будет выше. |
|
(9) |
Поддерживающую информацию, которая предоставляет пользователям, персоналу и менеджменту контактные данные для каждого типа нарушений политики безопасности; инструкции о том, как обрабатывать внешние запросы об инцидентах, сопряженных с нарушением безопасности, или информацию, которая может рассматриваться как конфиденциальная или частная; и перекрестные ссылки на процедуры безопасности и сопряженную с ними данные, такие как политика компании и правительственные законы и постановления. |
Могут существовать регулирующие требования, которые влияют на некоторые аспекты вашей политики безопасности (например, мониторирование линий). Создатели политики безопасности должны рассматривать возможности сотрудничества в ее формировании. Как минимум, политика должна быть рассмотрена юристом.
Раз ваша политика безопасности установлена, она должна быть четко доведена до сведения пользователей, персонала и менеджмента. Важной частью процесса является подписание всем персоналом регулирующего безопасность документа, которое указывает, что люди читали, поняли и согласны с требованиями политики там содержащимися. Наконец, ваша политика должна рассматриваться на регулярной основе с целью выяснения того, поддерживает ли она эффективно требования безопасности.
Что такое политика безопасности и зачем она нужна?
Решения, сопряженные с безопасностью, которые вы принимаете, или не можете принять в качестве администратора, определяют в заметной мере, насколько безопасна ваша сеть, какой уровень функциональности может она предложить, и насколько легко работать в этой сети. Однако вы не можете принять хорошее решение, касающиеся безопасности, без определения того, каковы ваши конечные цели. Пока вы не определите, каковы ваши цели обеспечения безопасности, вы не можете эффективно использовать любую комбинацию средств, так как вы не знаете, что проверять и какие ограничения ввести. Например, ваши цели будут, вероятно, сильно отличаться от целей поставщика продукта. Поставщики пытаются сделать конфигурирование и работу продукта как можно проще, это предполагает, что конфигурация по умолчанию будет максимально открытой (т.e., небезопасной). В то время как это облегчает инсталляцию новых продуктов, такой подход оставляет свободным доступ к этим системам и через них к другим системам. Ваши цели будут в основном определены следующими ключевыми компромиссами:
|
(1) |
предлагаемые услуги против предоставляемой безопасности – каждая услуга, предлагаемая пользователям, несет в себе определенные риски безопасности. Для некоторых услуг риск перевешивает привлекательные их стороны, и администратор может принять решение их запретить, а не защищать. |
|
(2) |
простота использования против безопасности – Простейшая система использования позволит доступ любому пользователю и не потребует пароля; то есть, лишена какой-либо безопасности. Требование пароля делает систему менее удобной, но более безопасной. Требование одноразового пароля, формируемого аппаратно еще менее удобно для использования, но много безопаснее. |
|
(3) |
стоимость безопасности против риска потери – существует много различных издержек безопасности: денежные (т.e., цену покупки оборудования и программ, обеспечивающих безопасность, например, firewall и генератора одноразовых паролей), рабочие характеристики (т.e., время необходимое для шифрования и дешифрования), а также простота использования (как упомянуто выше). Существует также много уровней риска: потеря конфиденциальности (т.e., чтение информации неавторизованными лицами), потеря данных (т.e., искажение или стирание информации), и потеря услуги (например, заполнение памяти, использование вычислительных ресурсов, и отказ в доступе к сети). Каждый тип издержек должен быть оценен и сопоставлен каждым типом потерь. |
Ваши цели следует довести до сведения всех пользователей, оперативного персонала и менеджеров в виде набора правил безопасности, называемых "политикой безопасности". Мы используем этот термин, а не более близкое выражение "политика компьютерной безопасности", так как данная сфера включает в себя все типы информационных технологий и информацию, хранимую и обрабатываемую этой технологией.
Цифровые подписи (сигнатуры)
Цифровая подпись представляет собой криптографический механизм, который является аналогом рукописной подписи. Она служит для аутентификации блока данных и подтверждает то, что она получена от отправителя. Цифровая подпись, использующая асимметричную криптографию (общедоступные ключи) может быть полезной для определения источника сообщения даже в случае, когда отправитель отрицает свое авторство. Цифровая подпись обеспечивает аутентификацию без конфиденциальности, так как текст самого сообщения не шифруется. Цифровая подпись использована в системе конфиденциальной почты PEM (Privacy Enhanced Mail) [Linn93, Kent93, Balenson93, Kaliski93].
Делайте программное обеспечение вашего модема настолько "пуленепробиваемым" насколько возможно
Убедитесь, что модемы не могут быть перепрограммированы в процессе работы. Как минимум, убедитесь в том, что три знака плюс не переводят ваш модем в командный режим!
Запрограммируйте ваши модемы так, чтобы они переходили в вашу стандартную конфигурацию при запуске нового вызова. Если это не получилось, заставляйте их выполнять команду сброс (reset) в конце каждого вызова. Эта предосторожность защитит вас от случайного перепрограммирования ваших модемов. Выполнение сброса в начале и конце вызова будет гарантировать даже более высокий уровень конфиденциальности, чем тот, который новый клиент может получить в наследство от предшествующей сессии.
Проверьте, что ваши модемы завершают вызов корректно. Когда пользователь осуществляет уход из сервера доступа, проверьте, что сервер корректно завершил сессию и положил трубку. Важно также, чтобы сервер завершал сессию соответствующим образом, если пользователь неожиданно положил трубку.
Дерево Штайнера
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Алгоритм дерева Штайнера используется в телекоммуникациях при оптимизации маршрутов передачи мультимедийных данных. Рассмотрим проблему поиска оптимального пути в предположении, что критерием оптимизации является длина этого пути. Задача может быть решена следующим образом:
Сначала находим два ближайших узла. Если соединение их не создаст циклических путей, производим такое объединение.
Повторяем операцию до тех пор, пока не будут объединены все узлы.
Алгоритм может быть упрощен. Сначала пометим все узлы уникальным образом. Затем находим два ближайшие узла с разными метками и соединяем их. После этого оба узла получают идентичные метки. Когда все узлы окажутся соединенными, они все получат идентичные метки. Имеется возможность добавления к графу дополнительных виртуальных точек Штайнера (1В), которые могут позволить сократить суммарную длину соединений. Смотри рис. 1 (; а также D. M. Warm, P. Winter, M. Zachariasen. Exact Algorithms for Plane Steiner Tree Problems: Computational Study, Advances in Steiner Trees, pages 81-116, Kluwer Academic Publishers, 2000; ).
Рис.1. Пример уменьшения суммарной длины дерева путем введения дополнительных точек
Метрика дерева варианта А равна 4 (длина ребра ячейки имеет метрику 1), а варианта В 1+4*sqrt(1/2)=3,83. Вариант В на рисунке 1 не всегда реализуем, так как в некоторых случаях узлы Штайнера могут иметь только целочисленные координаты (х,у), тогда точки Штайнера не могут сократить длину соединений для графа на рис. 1. В этом варианте расстояние между узлами (x1,y1) и (x2,y2) равно abs(x1-x2)+abs(y1-y2). Пример использования точек Штайнера для такого варианта показан на рис. 2.
Рис. 2. Использование точек Штайнера для минимизации длины маршрута по ортогональной сетке
Дерево варианта А на рис. 2 характеризуется метрикой 19, а для Б после добавления двух точек Штайнера (выделены более светлой закраской) метрика равна 17.
Довольно часто (телекоммуникации, а также трассировка печатных плат и микросхем) приходится сталкиваться с проблемами поиска оптимальных деревьев Штайнера в плоскости (Эвклида и прямолинейный).
Проблема сводится к поиску наикратчайшей длины дерева Штайнера SMT (Shortest Minimum Tree). При этом приходится размещать набор из n терминалов на плоскости с учетом эвклидовой L2-метрики и/или прямолинейной (или Манхэттеновской) L1-метрики.
Пусть u=(ux,uy) и v=(vx,vy) являются парой точек на декартовой плоскости В. Расстояние между этими точками в метрике Lp (Lp -расстояние, 1 Ј p Ј Ґ) характеризуется 2uv2p = (|ux - vy|p + |ux - vy|p)1/p.
Эвклидовские SMT ( ESMT) и прямолинейные SMT (RSMT) представляют собой подмножества полных деревьев Штайнера (FST). Эвклидово FST (EFST) и прямолинейное FST (RFST), охватывающие k терминалов, 2Ј k Ј n, имеет k-2 точек Штайнера (за исключением случая k=4; RFST могут тогда иметь одну точку Штайнера с четырьмя исходящими ребрами). Точки Штайнера в EFST имеют три исходящих ребра. Точки Штайнера в RSMT имеют также три исходящих ребра (за исключением выше приведенного случая). Длина EMST (соответственно RMST) превосходит длину ESMT (соответственно RSMT) как минимум в 2/3 раз (соответственно 3/2 раз) [смотри F. K. Hwang, D. S. Richards and P. Winter. The Steiner Tree Problem. Annals of Discrete Mathematics 53. Elsevier Science Publishers, Netherlands, 1992.].
При поиске SMT для эвклидова или прямолинейного варианта субнаборы терминалов рассматриваются один за другим. Для каждого субнабора определяются все его FST один за другим. Кратчайшие из них запоминаются. Узким местом данного подхода является формирование FST.
Diffie-Hellman
Выполняются обычные вычисления по алгоритму Diffie-Hellman. В качестве pre_master_secret используется согласованный ключ (Z), преобразование его в master_secret, описано выше.
Параметры Diffie-Hellman специфицируются сервером и могут быть одноразовыми или взятыми из сертификата сервера.
В отсутствии стандарта на прикладной профайл приложение TLS должно использовать шифровой набор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
Сообщения прикладных данных вырабатываются уровнем записей, фрагментируются, сжимаются и шифруются на основе параметров состояния соединения. Сообщения рассматриваются как прозрачные данные уровня записей.
A. Значения протокольных констант
A.1. Уровень записей
struct { uint8 major, minor; } ProtocolVersion;
ProtocolVersion version = { 3, 1 }; /* TLS v1.0 */
enum { change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255) } ContentType;
struct { ContentType type; ProtocolVersion version; uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct { ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct { ContentType type; ProtocolVersion version; uint16 length;
select (CipherSpec.cipher_type) { case stream: GenericStreamCipher;
case block: GenericBlockCipher; } fragment;
} TLSCiphertext;
stream-ciphered struct { opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size]; } GenericStreamCipher;
block-ciphered struct { opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
A.2. Сообщение об изменении спецификации шифра
struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec;
A.3. Сообщения уведомления (Alert)
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { close_notify(0),
| unexpected_message(10), | |
| bad_record_mac(20), | |
| decryption_failed(21), | |
| record_overflow(22), | |
| decompression_failure(30), | |
| handshake_failure(40), | |
| bad_certificate(42), | |
| unsupported_certificate(43), | |
| certificate_revoked(44), | |
| certificate_expired(45), | |
| certificate_unknown(46), | |
| illegal_parameter(47), | |
| unknown_ca(48), | |
| access_denied(49), | |
| decode_error(50), | |
| decrypt_error(51), | |
| export_restriction(60), | |
| protocol_version(70), | |
| insufficient_security(71), | |
| internal_error(80), | |
| user_canceled(90), | |
| no_renegotiation(100), | |
| (255) } AlertDescription; |
struct { AlertLevel level; AlertDescription description; } Alert;
A.4. Протокол диалога
enum { hello_request(0), client_hello(1), server_hello(2),
| certificate(11), server_key_exchange (12), | |
| certificate_request(13), server_hello_done(14), | |
| certificate_verify(15), client_key_exchange(16), | |
| finished(20), (255) |
struct { HandshakeType msg_type; uint24 length;
| select (HandshakeType) | { | |
| case hello_request: | HelloRequest; | |
| case client_hello: | ClientHello; | |
| case server_hello: | ServerHello; | |
| case certificate: | Certificate; | |
| case server_key_exchange: | ServerKeyExchange; | |
| case certificate_request: | CertificateRequest; | |
| case server_hello_done: | ServerHelloDone; | |
| case certificate_verify: | CertificateVerify; | |
| case client_key_exchange: | ClientKeyExchange; | |
| case finished: | Finished; } body; | |
| } Handshake; |
struct { } HelloRequest;
struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random;
opaque SessionID<0..32>;
uint8 CipherSuite[2];
enum { null(0), (255) } CompressionMethod;
struct { ProtocolVersion client_version; Random random;
SessionID session_id;
CipherSuite cipher_suites<2..216-1>;
CompressionMethod compression_methods<1..28-1>;
} ClientHello;
struct { ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
A.4.2. Аутентификация сервера и сообщения обмена ключами
opaque ASN.1Cert<224-1>;
struct { ASN.1Cert certificate_list<1..224-1>;} Certificate;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct { opaque RSA_modulus<1..216-1>; opaque RSA_exponent<1..216-1>;
} ServerRSAParams;
struct { opaque DH_p<1..216-1>; opaque DH_g<1..216-1>;
opaque DH_Ys<1..216-1>; ServerDHParams;
struct { select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params; };
} ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
select (SignatureAlgorithm)
{ case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20]; };
case dsa:
digitally-signed struct {
opaque sha_hash[20]; };
} Signature;
enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), (255)} ClientCertificateType;
opaque DistinguishedName<1..216-1>;
struct { ClientCertificateType certificate_types<1..28-1>;
DistinguishedName certificate_authorities<3..216-1>;
} CertificateRequest;
struct { } ServerHelloDone;
A.4.3. Аутентификация клиента и сообщения обмена ключами
struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret;
case diffie_hellman: DiffieHellmanClientPublicValue; } exchange_keys;
} ClientKeyExchange;
struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret;
struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
struct { select (PublicValueEncoding) { case implicit: struct {};
case explicit: opaque DH_Yc<1..216-1>; } dh_public;
} ClientDiffieHellmanPublic;
struct { Signature signature; } CertificateVerify;
A.4.4. Завершающее сообщение диалога
struct { opaque verify_data[12]; } Finished;
A.5. Коды CipherSuite
Следующие значения определены кодами CipherSuite, используемыми в сообщениях client hello и server hello. CipherSuite определяет шифровую спецификацию, поддерживаемую в TLS версии 1.0.
TLS_NULL_WITH_NULL_NULL специфицировано и является исходным состоянием TLS-соединения во время начала диалога в канале, эта спецификация не согласуется, так как она предоставляет услуги незащищенного соединения.
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
Следующие определения CipherSuite требуют, чтобы сервер предоставлял RSA-сертификат, который можно использовать для ключевого обмена. Сервер может потребовать присылки сертификата RSA или DSS, пригодного для цифровой подписи.
| CipherSuite TLS_RSA_WITH_NULL_MD5 | = { 0x00,0x01 }; |
| CipherSuite TLS_RSA_WITH_NULL_SHA | = { 0x00,0x02 }; |
| CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 | = { 0x00,0x03 }; |
| CipherSuite TLS_RSA_WITH_RC4_128_MD5 | = { 0x00,0x04 }; |
| CipherSuite TLS_RSA_WITH_RC4_128_SHA | = { 0x00,0x05 }; |
| CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 | = { 0x00,0x06 }; |
| CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA | = { 0x00,0x07 }; |
| CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x08 }; |
| CipherSuite TLS_RSA_WITH_DES_CBC_SHA | = { 0x00,0x09 }; |
| CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x0A }; |
Следующие определения CipherSuite используются для аутентифицированного сервером (и опционно клиентом) алгоритма Diffie-Hellman. DH обозначает шифровой набор, в котором сертификат сервера содержит параметры алгоритма Diffie-Hellman, подписанные провайдером сертификата CA (certificate authority). DHE обозначает временный Diffie-Hellman, где параметры Diffie-Hellman подписаны с помощью DSS- или RSA-сертификата, который подписан посредством CA. Используемый алгоритм подписи специфицирован согласно параметрам DH или DHE. Сервер может запросить от клиента сертификат RSA или DSS, пригодный для подписи, чтобы аутентифицировать клиента. Он может запросить также сертификат Diffie-Hellman. Любой сертификат Diffie-Hellman, предоставленный клиентом должен использовать параметры (группа и генератор), описанные сервером.
| CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x0B }; |
| CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA | = { 0x00,0x0C }; |
| CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x0D }; |
| CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x0E }; |
| CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA | = { 0x00,0x0F }; |
| CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x10 }; |
| CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x11 }; |
| CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA | = { 0x00,0x12 }; |
| CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x13 }; |
| CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x14 }; |
| CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA | = { 0x00,0x15 }; |
| CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x16 }; |
| CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 | = { 0x00,0x17 }; |
| CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 | = { 0x00,0x18 }; |
| CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA | = { 0x00,0x19 }; |
| CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA | = { 0x00,0x1A }; |
| CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA | = { 0x00,0x1B }; |
Все шифровые наборы, чей первый байт равен 0xFF, рассматриваются частными и могут быть использованы для определения локальных/экспериментальных алгоритмов.
Дополнительные шрифтовые наборы могут быть зарегистрированы путем публикации документа RFC, который специфицирует этот набор, включая необходимую протокольную информацию TLS, кодировку сообщений, получение предмастерных секретных кодов, симметричного шифрования, MAC-вычисления и ссылки на описания используемых алгоритмов. Редакционная комиссия RFC по своему разумению может опубликовать и неполное описание шифрового набора, если сочтет, что данное описание представляет определенный интерес.
Коды шифровых наборов { 0x00, 0x1C } и { 0x00, 0x1D } зарезервированы, чтобы избежать конфликта с наборами, базирующимися на Fortezza в SSL 3.
A.6. Параметры безопасности
Эти параметры безопасности определены протоколом диалога TLS и передаются уровню записи TLS, для того чтобы инициализировать состояние соединения. SecurityParameters включают в себя:
enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, idea }
BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { true, false } IsExportable; enum { null, md5, sha } MACAlgorithm;
/* Алгоритмы специфицированы в CompressionMethod, BulkCipherAlgorithm и MACAlgorithm и могут быть добавлены. */
struct { ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
IsExportable is_exportable;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
B. Словарь
| Протокол приложения | Протокол приложения является протоколом, который функционирует поверх транспортного уровня (напр., TCP/IP). Среди примеров можно назвать HTTP, TELNET, FTP и SMTP. |
| Асимметричный шифр | Смотри криптографию с общедоступным ключом |
| Аутентификация | Аутентификация - это механизм, который предоставляет возможность одному партнеру идентифицировать другого партнера |
| Блочный шифр | Блочный шифр - это алгоритм, который работает с фиксированными группами битов открытого текста, называемых блоками. 64 бита - обычный размер блока |
| Массовый шифр | Алгоритм симметричного шифрования, используемый для кодирования больших объемов данных. |
| Цепочный блок-шифр (CBC) | CBC является режимом, в котором каждый блок исходного текста закодированного блочным шифром сначала объединяется с предыдущим зашифрованным блоком с помощью исключающего ИЛИ (или в случае первого блока, с вектором инициализации). При дешифровании каждый блок сначала дешифруется, а затем объединяется с предыдущим зашифрованным блоком с помощью исключающего ИЛИ (или IV). |
| Сертификат | В качестве части протокола X.509, сертификаты выдаются проверенным провайдером (Certificate Authority) и обеспечивают строгую связь между идентичностью партнера, содержат некоторые другие атрибуты, а также общедоступный ключ |
| Клиент | Субъект, который инициирует TLS-соединение с сервером. Различие между сервером и клиентом заключается в том, что сервер обычно является аутентифицированным, в то время как клиент может быть аутентифицирован только опционно. |
| Ключ записи клиента | Ключ, используемый клиентом для шифрования записываемых данных. |
| Секретный код MAC записи клиента | Секретные данные, используемые для аутентификации информации, которую пишет клиент. |
| Соединение | Соединение - это транспортная среда (согласно определению модели OSI), которая предоставляет приемлемый тип услуг. Для TLS, такие соединения служат для установления канала между партнерами. Соединения прозрачны. Каждое соединение сопряжено с одной сессией. |
| Стандарт шифрования данных DES (Data Encryption Standard) | DES является широко используемым алгоритмом симметричного шифрования. DES представляет собой блочный шифр с 56 битным ключом и размером блока в 8 байтов. Заметим, что в TLS, для целей генерации ключей, DES рассматривается как имеющий 8-байтовую длину ключа (64 бита), но при этом обеспечивает безопасность на уровне 56 бит. (Младший бит каждого ключевого байта устанавливается с учетом формирования определенной четности каждого ключевого байта). DES может также работать в режиме, где используется три независимых ключа и три шифрования для каждого блока данных; при этом ключ имеет длину 168 бит (24 байта в методе генерации ключей TLS) и обеспечивает безопасность, соответствующую 112 битам. [DES], [3DES] |
| Стандарт цифровой подписи DSS (Digital Signature Standard) | Стандарт цифровой подписи, включая алгоритм цифровой подписи DSA, одобренный национальным институтом стандартов и технологии США, определенный в NIST FIPS PUB 186, "Digital Signature Standard," май, 1994. [DSS] |
| Цифровая подпись | Цифровые подписи используют криптографию с общедоступным ключом и однопроходные хэш-функции, для того чтобы аутентифицировать подписанные данные и гарантировать их целостность. |
| Диалог | Начальное согласование между клиентом и сервером, которое позволяет определить параметры транзакции. |
| Вектор инициализации (IV) | Когда используется блочный шифр в режиме CBC, перед шифрованием вектор инициализации объединяется с первым блоком исходного текста с помощью операции исключающее ИЛИ. |
| IDEA | 64-битовый блочный шифр, разработанный Xuejia Lai и James Massey. [IDEA] |
| Код аутентификации сообщения (MAC) | Код аутентификации сообщения представляет собой однопроходный хэш, вычисленный для сообщения и некоторых секретных данных. Его трудно взломать без знания секретных данных. Его целью является определение того, было ли сообщение модифицировано при транспортировке. |
| Мастерный секретный код | Безопасные секретные данные, используемые для генерации ключей шифрования, секретных кодов MAC и IV. |
| MD5 | MD5 представляет собой безопасную хэш-функцию, которая преобразует поток данных произвольного размера в дайджест фиксированного размера (16 байт). [MD5] |
| Криптография с общедоступным ключом | Класс криптографических методов, использующих двух-ключевой шифр. Сообщения, зашифрованные с помощью общедоступного ключа, могут быть дешифрованы посредством ассоциированного с ним секретного ключа. Сообщения, подписанные с помощью секретного ключа могут быть верифицированы посредством общедоступного ключа. |
| Однопроходная хэш-функция | Однопроходное преобразование, которое конвертирует произвольное количество данных в хэш фиксированной длины. С вычислительной точки зрения трудно осуществить обратное преобразование. MD5 и SHA представляют собой примеры однопроходных хэш-функций. |
| RC2 | Блочный шифр, разработанный Ron Rivest в компании RSA Data Security, Inc. [RSADSI] и описанный в [RC2]. |
| RC4 | Поточный шифр, лицензированный компанией RSA Data Security [RSADSI]. Совместимый шифр описан в [RC4]. |
| RSA | Очень широко используемый алгоритм шифрования с общедоступным ключом, который может быть использован для шифрования или цифровой подписи. [RSA] |
| salt | Несекретные случайные данные, используемые для того, чтобы сделать передаваемые ключи шифрования более устойчивыми против атак. |
| Сервер | Сервер - это субъект, который реагирует на запросы клиента по установлению соединения. |
| Сессия | Сессия TLS - это ассоциация клиента и сервера. Сессия создается с помощью протокола диалога. Сессия определяет набор криптографических параметров, которые могут использоваться несколькими соединениями. Сессия служит для того, чтобы избежать издержек, связанных с согласованием параметров безопасности каждого соединения. |
| Идентификатор сессии | Идентификатор сессии представляет собой код, генерируемый сервером для того, чтобы идентифицировать конкретную сессию. |
| Ключ записи сервера | Ключ, используемый сервером для записи шифрованных данных. |
| Секретный код MAC записи сервера | Секретные данные, используемые для аутентификации информации, записанной сервером. |
| SHA (Secure Hash Algorithm) | Алгоритм SHA описан в FIPS PUB 180-1. Он формирует дайджест размером 20-байт. Заметим, что все ссылки на SHA в действительности содержат модифицированный алгоритм SHA-1. [SHA] |
| SSL (Secure Socket Layer) | Протокол Netscape SSL [SSL3]. TLS базируется на версии SSL 3.0 |
| Поточный шифр | Алгоритм шифрования, который преобразует ключ в поток криптографически устойчивых данных, которые объединяются с исходным текстом с помощью операции исключающее ИЛИ |
| Симметричный шифр | Смотри массовый шифр. |
| Безопасность транспортного уровня TLS (Transport Layer Security) | Данный протокол; а также рабочая группа Transport Layer Security комиссии Internet Engineering Task Force (IETF). |
C. Определения CipherSuite
| CipherSuite | Is key Exportable Exchange | Шифр | Хэш |
| TLS_NULL_WITH_NULL_NULL | * NULL | NULL | NULL |
| TLS_RSA_WITH_NULL_MD5 | * RSA | NULL | MD5 |
| TLS_RSA_WITH_NULL_SHA | * RSA | NULL | SHA |
| TLS_RSA_EXPORT_WITH_RC4_40_MD5 | * RSA_EXPORT | RC4_40 | MD5 |
| TLS_RSA_WITH_RC4_128_MD5 | RSA | RC4_128 | MD5 |
| TLS_RSA_WITH_RC4_128_SHA | RSA | RC4_128 | SHA |
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 | * RSA_EXPORT | RC2_CBC_40 | MD5 |
| TLS_RSA_WITH_IDEA_CBC_SHA | RSA | IDEA_CBC | SHA |
| TLS_RSA_EXPORT_WITH_DES40_CBC_SHA | * RSA_EXPORT | DES40_CBC | SHA |
| TLS_RSA_WITH_DES_CBC_SHA | RSA | DES_CBC | SHA |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA | RSA | 3DES_EDE_CBC | SHA |
| TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA | * DH_DSS_EXPORT | DES40_CBC | SHA |
| TLS_DH_DSS_WITH_DES_CBC_SHA | DH_DSS | DES_CBC | SHA |
| TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA | DH_DSS | 3DES_EDE_CBC | SHA |
| TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA | * DH_RSA_EXPORT | DES40_CBC | SHA |
| TLS_DH_RSA_WITH_DES_CBC_SHA | DH_RSA | DES_CBC | SHA |
| TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA | DH_RSA | 3DES_EDE_CBC | SHA |
| TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA | * DHE_DSS_EXPORT | DES40_CBC | SHA |
| TLS_DHE_DSS_WITH_DES_CBC_SHA | DHE_DSS | DES_CBC | SHA |
| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA | DHE_DSS | 3DES_EDE_CBC | SHA |
| TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA | * DHE_RSA_EXPORT | DES40_CBC | SHA |
| TLS_DHE_RSA_WITH_DES_CBC_SHA | DHE_RSA | DES_CBC | SHA |
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA | DHE_RSA | 3DES_EDE_CBC | SHA |
| TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 | * DH_anon_EXPORT | RC4_40 | MD5 |
| TLS_DH_anon_WITH_RC4_128_MD5 | DH_anon | RC4_128 | MD5 |
| TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA | DH_anon | DES40_CBC | SHA |
| TLS_DH_anon_WITH_DES_CBC_SHA | DH_anon | DES_CBC | SHA |
| TLS_DH_anon_WITH_3DES_EDE_CBC_SHA | DH_anon | 3DES_EDE_CBC | SHA |
| Алгоритм ключевого обмена | Описание | Ограничение на размер ключа |
| DHE_DSS | Ephemeral DH with DSS signatures | None |
| DHE_DSS_EXPORT | Ephemeral DH with DSS signatures | DH = 512 bits |
| DHE_RSA | Ephemeral DH with RSA signatures | None |
| DHE_RSA_EXPORT | Ephemeral DH with RSA signatures | DH = 512 bits, RSA = none |
| DH_anon | Anonymous DH, no signatures | None |
| DH_anon_EXPORT | Anonymous DH, no signatures | DH = 512 bits |
| DH_DSS | DH with DSS-based certificates | None |
| DH_DSS_EXPORT | DH with DSS-based certificates | DH = 512 bits |
| DH_RSA | DH with RSA-based certificates | None |
| DH_RSA_EXPORT | DH with RSA-based certificates | DH = 512 bits, RSA = none |
| NULL | Отсутствие ключевого обмена | N/A |
| RSA | Ключевой обмен RSA | None |
| RSA_EXPORT | Ключевой обмен RSA | RSA = 512 бит |
Ограничение на размер ключа характеризуют максимальную длину ключевого общедоступного кода, который может быть легально использован в экспортируемом шифровом наборе.
| Шифр | Тип | <Ключевой материал | Расширенный ключевой материал | Эффективное число бит в ключе | Размер IV | Размер блока |
| NULL * | Поток | 0 | 0 | 0 | 0 | N/A |
| IDEA_CBC | Блок | 16 | 16 | 128 | 8 | 8 |
| RC2_CBC_40 * | Блок | 5 | 16 | 40 | 8 | 8 |
| RC4_40 * | Поток | 5 | 16 | 40 | 0 | N/A |
| RC4_128 | Поток | 16 | 16 | 128 | 0 | N/A |
| DES40_CBC * | Блок | 5 | 8 | 40 | 8 | 8 |
| DES_CBC | Блок | 8 | 8 | 56 | 8 | 8 |
| 3DES_EDE_CBC | Блок | 24 | 24 | 168 | 8 | 8 |
| Тип | Указывает является ли шифр поточным или блочным, работающим в режиме CBC. |
| Key Material | Число байтов из key_block, которые используются для генерации ключей записи. |
| Expanded Key Material | Число байтов действительно передаваемых алгоритму шифрования |
| Эффективные биты ключа | Сколько энтропийного материала, содержащегося в материале ключа, передается программам шифрования. |
| Размер IV | Сколько данных нужно сгенерировать для вектора инициализации (initialization vector). Нуль - для поточных шифров; число, равное размеру блока для блочных шифров. |
| Размер блока | Количество данных, которые блочный шифр преобразует за один раз; блочный шифр, работающий в режиме CBC, может переработать блок с размером четным кратным величине его блока. |
| Хэш-функция | Размер хэша | Размер заполнителя |
| NULL | 0 | 0 |
| MD5 | 16 | 48 |
| SHA | 20 | 40 |
D.1. Временные ключи RSA
Экспортные ограничения США устанавливает верхний предел длины ключей RSA равный 512 битам, но не вводят ограничений на размер RSA ключей, используемых для цифровых подписей. Часто нужны сертификаты длиннее 512 бит, так как 512-битные RSA ключи не достаточно безопасны для особо важных транзакций или для приложений требующих долговременной безопасности. Некоторые сертификаты предназначены исключительно для цифровых подписей и не могут использоваться для ключевого обмена.
Когда общедоступный ключ в сертификате не может быть использован для шифрования, сервер подписывает временный RSA-ключ, который затем пересылается.
В экспортируемых приложениях, временный RSA- ключ должен иметь максимально возможную длину (т.e., 512 бит). Так как 512-битовые RSA-ключи имеют относительно низкую безопасность, они должны часто заменяться. Для обычных коммерческих применений предлагается, чтобы ключи заменялись ежедневно или после каждых 500 транзакций, или даже чаще, если это возможно. Заметим, что, так как допускается многократное использование временного ключа, он должен каждый раз при использовании подписываться.
Генерация ключа RSA является трудоемким процессом. Во многих случаях, процессу формирования ключа может быть приписан низкий фоновый приоритет. Как только сформирован новый ключ, старый временный ключ может быть заменен.
D.2. Генерация псевдослучайных чисел и стартовые коды (Seeding)
TLS требует наличия криптографически безопасного генератора псевдослучайных чисел (PRNG). Должны быть приняты меры для формирования стартовых кодов такого PRNG. Доступны генераторы PRNG, базирующиеся на безопасных хэш операциях, например, MD5 и/или SHA, но они не могут предоставить большую безопасность, чем та, которая определяется размером псевдослучайного генерируемого числа. (Например: генератор, базирующийся на MD5 обычно гарантирует безопасность на уровне 128 бит.)
Чтобы оценить необходимую длину порождающего кода, следует добавить несколько битов непредсказуемой информации к каждому байту порождающего кода. Например: времена нажатия клавиш, полученные от стандартного 18.2 кГц PC таймера, может бать 1-2 безопасных бита, но в любом случае размер этого кода должен быть не менее 16 бит. В качестве порождающего кода для 128-битового генератора PRNG может потребоваться приблизительно 100 таких таймерных кодов.
Функции порождающих кодов в RSAREF и в версиях BSAFE до 3.0 не имеют порядковой зависимости. Например: если предоставлены 1000 бит порождающего кода, по одному за раз в результате 1000 обращений к этой функции, PRNG окажется в состоянии, которое зависит только от числа 0 или 1 в порождающем коде (т.e., имеется 1001 возможных конечных состояний).
Приложения, использующие BSAFE или RSAREF должны предпринимать дополнительные меры для обеспечения нужных порождающих кодов. Это может быть осуществлено путем накопления битов порождающего кода в буфере и обработки их как целое. Нужно только учитывать, что такие меры могут создать автокорреляции кодов.
D.3. Сертификаты и аутентификация
За верификацию целостности сертификата отвечает приложение, оно должно также поддерживать аннулирование сообщений, содержащих сертификат. Сертификаты должны всегда верифицироваться, чтобы гарантировать корректность подписи (СА). Выбор и добавление доверительных провайдеров сертификатов (СА) следует делать осмотрительно. Пользователи должны иметь возможность просмотреть информацию о сертификате и корневом провайдере сертификатов (CA).
D.4. Шифровые наборы
TLS поддерживает широкий диапазон размеров ключей и уровней безопасности, включая те, которые предоставляют минимальную или никакой безопасности. Корректная реализация не будет поддерживать много шифровых наборов. Например: 40-битовое шифрование легко ломается, поэтому приложения, требующие надежной безопасности, не должны разрешать применение 40-битовых ключей. Аналогично, анонимный алгоритм Diffie-Hellman не надежен, так как уязвим для атак 'посредников' (man-in-the-middle). Приложения должны накладывать также ограничения на минимальный и максимальный размер ключей. Например: сертификатные цепочки, содержащие 512-битные ключи RSA или подписи не могут считаться удовлетворительными для задач, требующих высокой безопасности.
E. Совместимость с SSL
По историческим причинам и для того чтобы избежать использования резервных номеров портов, прикладные протоколы, безопасность которых обеспечивается с помощью TLS 1.0, SSL 3.0, и SSL 2.0 часто используют один и тот же порт. Например: протокол HTTPS (HTTP с обеспечением безопасности за счет SSL или TLS) использует порт 443 вне зависимости от того, какой протокол безопасности применен. Таким образом, должен быть определен некоторый механизм согласования применения тех или иных протоколов.
TLS версии 1.0 и SSL 3. 0 очень схожи. Клиенты TLS, которые желают согласовать применение SSL 3.0, должны посылать серверу сообщения client hello, используя формат записей SSL 3.0 и посылая {3, 1} в поле версии (TLS 1.0). Если сервер поддерживает только SSL 3.0, он откликнется server hello SSL 3.0. Если же он поддерживает TLS, то пришлет отклик TLS server hello. Дальнейшее согласование будет продолжено согласно с выбранным протоколом.
Аналогично, TLS-сервер, который хочет работать с клиентами SSL 3.0, должен воспринимать сообщения SSL 3.0 client hello и реагировать на server hello, если получено SSL 3.0 client hello с полем версии равным {3, 0}, означающим, что клиент не поддерживает TLS.
Всякий раз, когда клиент уже знает верхний протокол, известный серверу (например, когда возобновляется сессия), он должен инициировать соединение в рамках этого протокола.
Клиенты TLS 1.0, которые поддерживают работу с серверами SSL версии 2.0, должны посылать сообщения client hello SSL версии 2.0 [SSL2]. Серверы TLS должны воспринимать любой формат client hello, если они хотят поддерживать работу с клиентами SSL 2.0, на том же порту соединения. Единственное отклонение спецификации от версии 2.0 является возможность специфицировать версию со значением три и поддерживать больше шифровых типов в CipherSpec.
Возможность посылать сообщения client hello версии 2.0 следует исключить из употребления так быстро, как это возможно. Разработчики должны предпринять все меры, чтобы ускорить эти работы. Версия 3.0 предоставляет лучшие механизмы для введения новых версий.
Следующие шифровые спецификации являются переходными от SSL версии 2.0. Они предполагают использования RSA для ключевого обмена и аутентификации.
V2CipherSpec TLS_RC4_128_WITH_MD5 | = { 0x01,0x00,0x80 }; |
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 | = { 0x02,0x00,0x80 }; |
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 | = { 0x03,0x00,0x80 }; |
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 | = { 0x04,0x00,0x80 }; |
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 | = { 0x05,0x00,0x80 }; |
| V2CipherSpec TLS_DES_64_CBC_WITH_MD5 | = { 0x06,0x00,0x40 }; |
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 | = { 0x07,0x00,0xC0 }; |
Шифровые спецификации совместимые с TLS могут быть включены в сообщения client hello версии 2.0, используя описанный ниже синтаксис. Любой элемент V2CipherSpec с первым байтом равным нулю будет игнорироваться серверами версии 2.0. Клиенты, посылающие любую из перечисленных выше спецификаций V2CipherSpecs должны также включать и TLS-эквивалент (смотри приложение A.5):
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
E.1. Hello клиента версия 2
Сообщение client hello версии 2.0 представлены ниже. Истинные определения предполагаются совпадающими со спецификацией SSL версии 2.0.
uint8 V2CipherSpec[3];
struct { uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
Random challenge;
} V2ClientHello;
| msg_type | Это поле, в сочетании с полем версии, идентифицирует сообщение client hello версии 2. Значение поля должно быть равно единице (1). |
| Version | Высшее значение версии протокола, поддерживаемое клиентом (равно ProtocolVersion.version, смотри приложение A.1). |
| cipher_spec_length | Это поле равно полной длине поля cipher_specs. Оно не может быть равно нулю и должно быть кратным длине V2CipherSpec (3). |
| session_id_length | Это поле должно иметь значение нуль или 16. Если равно нулю, клиент формирует новую сессию. Если равно 16, поле session_id будет содержать 16 байт идентификации сессии. |
| challenge_length | Длина в байтах обращения клиента к серверу, чтобы аутентифицировать себя. Это значение должно равняться 32. |
| cipher_specs | Это список всех CipherSpecs, которые клиент хочет и может использовать. Здесь должна быть по крайней мере одна спецификация CipherSpec, приемлемая для сервера. |
| session_id | Если длина этого поля не равна нулю, оно будет содержать идентификатор сессии, которую клиент хочет возобновить. |
| Challenge | Обращение клиента к серверу с целью идентификации самого себя. Его значение представляет собой псевдослучайное число произвольной длины. Сервер TLS проверяет обращение клиента, чтобы получить данные ClientHello.random (дополненные лидирующими нулями, если это нужно), как это специфицировано в данном протоколе. Если длина обращения больше чем 32 байта, то используются только последние 32 байта. Допускается (но не обязательно) для сервера V3 отклонять V2 ClientHello, которые имеют меньше 16 байтов обращения клиента. |
Запросы возобновления TLS- сессии должны использовать сообщение TLS client hello.
E.2. Избежание атак понижения версии посредником (man-in-the-middle)
Когда клиенты TLS возвращаются к режиму совместимости с версией 2.0, они должны использовать специальное форматирование блоков PKCS #1. Это сделано так, что TLS-серверы будут отклонять сессии версии 2.0 с совместимыми TLS-клиентами.
Когда клиенты TLS работают в режиме совместимости с версией 2.0, они устанавливают правые случайные 8 байт (менее значимые) заполнителя PKCS (исключая завершающий нулевой заполнитель) для RSA-шифрования поля ENCRYPTED-KEY-DATA CLIENT-MASTER-KEY, равными 0x03 (остальные байты заполнителя содержат произвольные случайные значения). После дешифрования поля ENCRYPTED-KEY-DATA, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом.
F. Анализбезопасности
Протокол TLS создан для того, чтобы установить безопасное соединение между клиентом и сервером через канал не гарантирующий безопасность. В данном документе делаются несколько традиционных предположений, включая то, что атакующие имеют достаточно большие вычислительные ресурсы и не могут получить секретную информацию из источников, помимо протокольных. Предполагается, что атакующий может перехватить, модифицировать, уничтожать и подменить сообщения, посланные по коммуникационному каналу.
F.1. Протокол диалога
Протокол диалога несет ответственность за выбор CipherSpec и генерацию мастерного секретного кода (Master Secret), которые вместе являются первичными криптографическими параметрами, сопряженными с безопасной сессией. Протокол диалога может также аутентифицировать партнеров, которые имеют сертификаты, подписанные пользующимся доверием провайдером сертификатов.
F.1.1. Аутентификация и обмен ключами
TLS поддерживает три режима аутентификации: аутентификация обоих партнеров, аутентификация сервера не аутентифицированным клиентом, и полностью анонимная. Всякий раз, когда сервер аутентифицирован, канал безопасен со стороны атак 'посредника' (man-in-the-middle), по анонимные сессии полностью беззащитны для такого рода атак.
Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение сертификата должно предоставить корректную сертификационную цепочку, ведущую к приемлемому провайдеру сертификатов. Аналогично, аутентифицированные клиенты должны предоставить приемлемый сертификат серверу. Каждый партнер ответственен за верификацию сертификата противоположной стороны, за его пригодность.
Общей целью процесса ключевого обмена является формирование pre_master_secret, известного партнерами обмена, но неизвестного хакерам. Код pre_master_secret будет использован для генерации master_secret (смотри раздел 8.1). Код master_secret необходим, чтобы сформировать сообщения верификации сертификата, шифровальных ключей, секретных кодов MAC финального сообщения (смотри разделы 7.4.8, 7.4.9 и 6.3). Путем посылки корректного финального сообщения (finished) партнеры подтверждают то, что они знают правильное значение pre_master_secret.
F.1.1.1. Анонимный обмен ключами
Полностью анонимные сессии могут быть реализованы с помощью ключевого обмена на основе алгоритмов RSA или Diffie-Hellman. При анонимном RSA, клиент шифрует pre_master_secret с помощью не сертифицированного общедоступного ключа сервера, полученного из его сообщения ключевого обмена. Результат посылается в сообщении ключевого обмена клиента. Так как злоумышленники не знают секретного ключа сервера, практически не реально для них дешифровать pre_master_secret. Заметим, что анонимные шифровые RSA-наборы в данном документе не определены.
В случае алгоритма Diffie-Hellman, общедоступные параметры сервера содержатся в его сообщении ключевого обмена, а параметры клиента посылаются в его сообщении ключевого обмена. Злоумышленники, которые не знают секретных ключей, не способны выполнить вычисления согласно алгоритму Diffie-Hellman и получить правильный результат (т.e. pre_master_secret).
Полностью анонимные соединения предоставляют защиту только против пассивных видов атак. Если только не используется надежно защищенный канал, позволяющий проверку того, что финальное сообщение не подменено злоумышленником, в ситуациях, где возможна активная атака 'посредника' (man-in-the-middle) необходима аутентификация сервера.
F.1.1.2. Обмен ключами по схеме RSA с аутентификацией
В случае RSA, ключевой обмен и аутентификация сервера совмещаются. Общедоступный ключ может содержаться в сертификате сервера или быть временным RSA-ключом, посланным в сообщении ключевого обмена сервера. Когда используются временные RSA-ключи, они подписываются сертификатом сервера RSA или DSS. Подпись включает текущее значение ClientHello.random, поэтому старые подписи и временные ключи не могут быть повторно использованы. Серверы могут использовать одиночный временный RSA-ключ для нескольких сессий.
Опция временного ключа RSA полезна, если серверы нуждаются в больших сертификатах, но вынуждены соглашаться с правительственными регламентациями для размеров ключей при ключевом обмене.
После проверки сертификата сервера, клиент шифрует pre_master_secret с помощью общедоступного ключа сервера. В случае успешной дешифровки pre_master_secret и выработки корректного финального сообщения, сервер демонстрирует, что он знает секретный ключ, соответствующий его сертификату.
Когда RSA используется для ключевого обмена, клиенты аутентифицируются, используя сообщение верификации сертификата (смотри раздел 7.4.8). Клиент подписывает значение, полученное из master_secret и все предыдущие сообщения диалога. Эти сообщения диалога включают сертификат сервера, который связывает подпись с сервером, и ServerHello.random, связывающий подпись с текущим процессом диалога.
F.1.1.3. Обмен ключами по схеме Diffie-Hellman с аутентификацией
Когда используется пересылка ключей по схеме Diffie-Hellman, сервер может либо предоставить сертификат, содержащий фиксированные параметры Diffie-Hellman, либо использовать сообщение ключевого обмена сервера, чтобы послать набор временных параметров, подписанных сертификатом DSS или RSA. Временные параметры хэшируются со значениями hello.random до формирования подписи, чтобы гарантировать, что злоумышленник не сможет воспользоваться старыми параметрами. В любом случае клиент может проверить сертификат или подпись, чтобы убедиться в том, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий фиксированные параметры Diffie-Hellman, его сертификат содержит информацию, необходимую для ключевого обмена. Заметим, что в этом случае клиент и сервер получат один и тот же результат (т.e., pre_master_secret) каждый раз, когда они обмениваются информацией. Чтобы предотвратить пребывание в памяти pre_master_secret дольше, чем это требуется, этот код должен быть, как можно быстрее преобразован в master_secret. Параметры клиента Diffie-Hellman должны быть совместимыми с теми, что поставляются сервером для ключевого обмена.
Если клиент имеет стандартный сертификат DSS или RSA или он не аутентифицирован, тогда клиент посылает набор временных параметров серверу в сообщении ключевого обмена клиента, затем опционно использует сообщение верификации сертификата, чтобы аутентифицировать себя.
F.1.2. Атаки понижения версии
Так как TLS содержит существенные улучшения по сравнению с SSL версии 2.0, атакующие могут попытаться создавать TLS-совместимых клиентов и серверов, чтобы вернуться к версии 2.0. Эта атака может произойти, если (и только если) два TLS-совместимых партнера используют диалог в SSL 2.0.
Хотя решение, использующее неслучайное заполнение сообщения блока PKCS #1 типа 2, не является красивым, оно предоставляет безопасный путь для серверов версии 3.0, чтобы заметить такую атаку. Это решение не безопасно по отношению злоумышленников, которые могут попытаться подсунуть ключ и осуществить подмену сообщения ENCRYPTED-KEY-DATA, содержащего тот же ключ (но с нормальным заполнителем) до момента истечения порога ожидания, заданного приложением. Партнеры, озабоченные атаками этого типа, никогда не должны использовать 40-битовые ключи шифрования. Вариация заполнителя младших 8 байт PKCS не увеличивает безопасности, так как это просто эквивалентно увеличению размера входного блока на 8 байт.
F.1.3. Регистрация атак против протокола диалога
Атакующий может попытаться повлиять на диалоговый обмен, чтобы заставить партнеров выбрать другой алгоритм шифрования, отличный от того, который бы они выбрали сами.
Так как многие реализации будут поддерживать 40-битовое экспортное шифрование, а некоторые могут даже поддерживать отсутствие шифрования или алгоритмы MAC, возможность такой атаки должна всегда учитываться.
Для этой атаки злоумышленник должен активно изменить одно или более сообщений диалога. Если это произойдет, клиент и сервер вычислят разные значения для хэшей сообщения диалога. В результате, партнеры не воспримут друг от друга финальные сообщения. Без master_secret, злоумышленник не может восстановить финальные сообщения, таким образом, факт атаки будет раскрыт.
F.1.4. Возобновляемые сессии
Когда соединение установлено путем возобновления сессии, новые значения ClientHello.random и ServerHello.random хэшируются вместе с master_secret сессии. Если установлено, что код master_secret не поврежден и что хэш-операции, использованные для получения ключей и секретных кодов MAC также безопасны, то соединение можно считать безопасным и независимым от предыдущих соединений. Атакующие не могут использовать известные ключи шифрования или секретные коды MAC, для того, чтобы скомпрометировать master_secret без нарушения исполнения операций хэширования.
Сессии не могут возобновляться, если только клиент и сервер не хотят этого. Если любой из партнеров подозревает, что сессия скомпрометирована, или что сертификаты не действительны, он должен потребовать полного диалога. Для верхнего предела времени жизни идентификатора сессии предлагается значение 24 часа, так как атакующий, получивший значение master_secret может подменить скомпрометированного партнера пока сохраняется старое значение ID-сессии. Приложения, которые могут работать в относительно небезопасной среде не должны записывать ID-сессии в постоянную память.
F.1.5. MD5 и SHA
TLS использует хэш-функции весьма консервативно. Где возможно, как MD5, так и SHA используются вместе для того, чтобы не катастрофические дефекты в одном алгоритме не приводили к разрушения всего протокола.
F.2. Защита прикладных данных
Код master_secret кэшируется с помощью ClientHello.random и ServerHello.random, чтобы получить уникальные ключи для шифрования данных и секретные коды MAC для каждого соединения.
Исходящие данные перед посылкой защищаются с помощью MAC. Для того чтобы исключить атаки, связанные с модификаций или воспроизведения сообщений, из секретного кода MAC вычисляется MAC, номер по порядку, длина сообщения, содержимое сообщения и две фиксированные символьные строки. Поле типа сообщения необходимо, чтобы гарантировать то, что сообщения, предназначенные для одного клиента слоя записи TLS, не будут переадресованы другому. Номер по порядку гарантирует, что попытки уничтожить или поменять порядок сообщений будут детектированы. Так как номера по порядку имеют 64 бита, они не могут быть переполнены. Сообщения от одного партнера не могут быть вставлены в выходные сообщения другого, так как они используют независимые секретные коды MAC. Аналогично, ключи записи сервера и клиента независимы, так что ключи поточных шифров используются только раз.
Если атакующий расколол ключ шифрования, все сообщения, зашифрованные этим ключом, могут быть прочитаны. Аналогично, раскрытие ключа MAC может сделать возможной атаку, сопряженную с модификацией передаваемых сообщений. Так как MAC зашифрован, атаки модификации сообщений требуют также взлома и алгоритма шифрования.
Секретные коды MAC могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивы против повреждений, даже если взломаны ключи шифрования.
G. Патентное заявление
Следует иметь в виду, что применение ряда алгоритмов ограничено действующими патентами. К их числу относятся, например, SSL (патент США No. 5,657,390; Netscape). Существуют ограничения на коммерческое использование алгоритма RSA (RSA Data Security, Inc.). Политика компании Netscape в этой области достаточно либеральна.
Ссылки
| [3DES] | W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. |
| [BLEI] | Bleichenbacher D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1--12, 1998. |
| [DES] | ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983. |
| [DH1] | W. Diffie and M. E. Hellman, "New Directions in Cryptography," IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, pp. 74-84. |
| [DSS] | NIST FIPS PUB 186, "Digital Signature Standard," National Institute of Standards and Technology, U.S. Department of Commerce, May 18, 1994. |
| [FTP] | Postel J., and J. Reynolds, "File Transfer Protocol", STD-9, RFC-959, October 1985. |
| [HTTP] | Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC-1945, May 1996. |
| [HMAC] | Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC-2104, February 1997. |
| [IDEA] | X. Lai, "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992. |
| [MD2] | Kaliski, B., "The MD2 Message Digest Algorithm", RFC-1319, April 1992. |
| [MD5] | Rivest, R., "The MD5 Message Digest Algorithm", RFC-1321, April 1992. |
| [PKCS1] | RSA Laboratories, "PKCS #1: RSA Encryption Standard," version 1.5, November 1993. |
| [PKCS6] | RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax Standard," version 1.5, November 1993. |
| [PKCS7] | RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax Standard," version 1.5, November 1993. |
| [PKIX] | Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC-2459, January 1999. |
| [RC2] | Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, January 1998. |
| [RC4] | Thayer, R. and K. Kaukonen, A Stream Cipher Encryption Algorithm, Work in Progress. |
| [RSA] | R. Rivest, A. Shamir, and L. M. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126. |
| [RSADSI] | Contact RSA Data Security, Inc., Tel: 415-595-8782 |
| [SCH] | B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Published by John Wiley & Sons, Inc. 1994. |
| [SHA] | NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, Work in Progress, May 31, 1994. |
| [SSL2] | Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995. |
| [SSL3] | A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. |
[TCP] | Postel, J., "Transmission Control Protocol," STD-7, RFC 793, September 1981. |
| [TEL] | Postel J., and J. Reynolds, "Telnet Protocol Specifications", STD-8, RFC-854, May 1993. |
| [TEL] | Postel J., and J. Reynolds, "Telnet Option Specifications", STD-8, RFC-855, May 1993. |
| [X509] | CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988. |
| [XDR] | R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data Representation Standard, August 1995. |
http://www.imc.org/ietf-tls/mail-archive/
Доработка
Когда вы поняли, что система восстановлена и приведена в безопасное состояние, вполне возможно, что в системе безопасности сохранились дыры и даже ловушки, допускающие отслеживание системы. Одним из важных этапов реагирования на инцидент довольно часто упускается, это фаза доводки системы безопасности. На фазе доводки, система должна мониторироваться на предмет объектов, которые оказались пропущены на предыдущей фазе. Было бы благоразумным использовать некоторые средства, упомянутые в главе 7.
Наиболее важным элементом стадии доводки является выполнение анализа инцидента и его последствий. Что конкретно случилось, и когда? Насколько эффективно действовал персонал во время инцидента? В какой информации персонал нуждается в первую очередь, и как такую информацию получить как можно быстрее? Что следует сделать персоналу по другому в следующий раз?
После инцидента, разумно написать доклад, описывающий точную последовательность событий: метод обнаружения, процедура коррекции, процедура мониторинга и резюме полученного опыта. Это поможет ясно понять проблему. Создание формальной хронологии событий (включая временные метки) важно также по юридическим причинам. Доклад доводки является ценным по многим причинам. Он используется в случае возникновения других сходных инцидентов. Важно также как можно быстрее получить денежную оценку ущерба, вызванного инцидентом. Эта оценка должна включать суммы, связанные с потерей программ и файлов (особенно стоимость частных данных, которые могут быть раскрыты), выхода из строя оборудования и трудозатраты для восстановления измененных файлов, реконфигурации поврежденных систем и пр. Эта оценка может стать основой для последующего преследования виновных. Доклад может помочь руководству составить представление о состоянии сетевой безопасности организации.
Дозванивающиеся пользователи должны быть аутентифицированы
Проверка имени пользователя и пароля должна завершаться до того как пользователь получит доступ к чему-либо в сети. Соображения о нормальной безопасности паролей особенно важны (смотри раздел 4.1.1).
Запомните, что телефонные линии могут быть снабжены отводами, и что достаточно легко перехватывать сообщения, посылаемые на сотовый телефон. Современные высокоскоростные модемы используют более изощренные методики модуляции, которые делают трудным их мониторирование, но разумно предположить, что хакеры знают, как прослушать ваши каналы. По этой причине, вам следует использовать одноразовые пароли.
Полезно создать один пункт коммутации (например, один большой модемный пул), так что все пользователи аутентифицируются идентичным образом.
Пользователи часто случайно ошибаются при вводе паролей. Установите малую задержку – скажем две секунды – после первой и второй неудачной авторизации, и осуществляйте разрыв соединения после третей неудачи. Это замедлит автоматизированные атаки паролей. Не сообщайте пользователю, что оказалось причиной неудачи: имя пользователя, пароль или оба эти ввода.
Другие сетевые технологии
Рассмотренные здесь технологии включают X.25, ISDN, SMDS, DDS и Frame Relay. Все они предоставляют физическое подключение через телефонные коммутаторы, что в принципе допускает перекоммутацию и несанкционированное подключение. Атакеры определенно интересуются телефонными коммутаторами также как и информационными сетями!
В случае коммутационных технологий, используйте постоянные виртуальные каналы или замкнутые группы пользователей всякий раз, когда это возможно. Технологии, которые предоставляют аутентификацию и/или шифрование (например, IPv6), развиваются достаточно быстро; рассматривайте именно их, когда нужно обеспечить высокий уровень безопасности.
Другие возможные функции сетевого оборудования
Дополнительные функции могут рассматриваться для будущих реализаций.
Реализация автоматического фильтрования на серверах удаленного доступа. В большинстве случаев, пользователь, дозванивающийся до сервера доступа, является индивидуальным пользователем своей ЭВМ. Единственно разрешенным адресом отправителя для этой ЭВМ является адрес, присвоенный ISP (статически или динамически). Сервер удаленного доступа может проверять каждый пакет на входе, чтобы гарантировать, что пользователь не фальсифицирует адрес отправителя. Очевидно, должна быть предусмотрена возможность того, что клиент легально подключает сеть через удаленный сервер, но это должно реализовываться опционно.
Мы рассматривали вариант, когда маршрутизаторы проверяют IP-адрес отправителя, как это предложено [8], но это методологически не будет работать хорошо в реальных сетях в настоящее время. Предлагаемый метод заключается в просмотре адреса отправителя на предмет того, проходит ли маршрут до него через тот же интерфейс, через который пришел пакет. При большом числе асимметричных маршрутов это будет весьма проблематично.
Физический доступ
Ограничение доступа к ЭВМ на физическом уровне предполагает разрешение работы только для лиц, кому это позволено. Список таких ЭВМ включает в себя терминалы (т.e., терминалы, которые допускают использование без аутентификации, такие как консоли, операторские терминалы и специальные терминалы), и индивидуальный микро-ЭВМ и рабочие станции, особенно те, которые подключены к вашей сети. Убедитесь в том, что рабочие области оформлены соответствующим образом с учетом ограничений доступа; в противном случае будут найдены пути обхода ваших физические средства безопасности (например, двери окажутся открытыми).
Храните исходные и резервные копии данных и программы в безопасном месте. Помимо хранения их в хороших условиях для целей резервирования, они должны быть защищены от кражи. Важно держать резервные копии в отдельном от оригиналов месте, не только с учетом возможного повреждения, но предотвращения ущерба в случае кражи.
Портативные ЭВМ подвергаются особому риску. Убедитесь, что даже кража портативной машины вашего персонала не вызовет проблем. Рассмотрите принципы обработки данных, которым разрешено храниться на дисках портативных машин, а также то, как эти данные должны быть защищены (например, шифрованием).
Другими областями, где должен быть ограничен доступ, являются коммутационные шкафы и важные сетевые элементы, типа файловых серверов, DNS-серверов и маршрутизаторов.
Формат информационных записей SSL
Часть данных рекорда SSL состоит из трех компонентов (передаваемых и получаемых в приведенном ниже порядке):
MAC-DATA[MAC-SIZE]
ACTUAL-DATA[N]
PADDING-DATA[PADDING]
ACTUAL-DATA представляет собой реальные переданные данные (поле данных сообщения). PADDING-DATA - это данные заполнителя, посылаемые когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения (Message Authentication Code).
Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]
Где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA>, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи - "big endian").
MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).
Значение SECRET зависит оттого, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC).
SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи, используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются.
Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE).
Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай "I/O Error" (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).
Окончательная проверка соответствия выполняется, когда используется блочный шифр и соответствующий протокол шифрования. Объем данных в рекорде (RECORD-LENGTH) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место "I/O Error" (что вызовет разрыв соединения).
Уровень рекордов SSL используется для всех коммуникаций SSL, включая сообщения диалога и информационный обмен. Уровень рекордов SSL применяется как клиентом, так и сервером.
Для двухбайтового заголовка, максимальная длина рекорда равна 32767 байтов. Для трехбайтового заголовка, максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL.
Прежде чем послать первый рекорд SSL все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVER-HELLO.
Фрагментация
Уровень записей фрагментирует информационные блоки и превращают их в записи TLSPlaintext, несущие данные в виде последовательностей длиной 214 байтов или меньше. Границы сообщения клиента на уровне записей не сохраняются (т.e., несколько сообщений клиента одного и того же ContentType могут быть объединены в одну запись TLSPlaintext, или одно сообщение может быть фрагментировано).
struct { uint8 major, minor;} ProtocolVersion;
| enum | { change_cipher_spec(20), alert(21), handshake(22), |
| application_data(23), (255) | |
| } ContentType; |
struct { ContentType type;
| ProtocolVersion version; | |
| uint16 length; | |
| opaque fragment[TLSPlaintext.length]; | |
| } TLSPlaintext; |
| type | Протокол верхнего уровня, использованный для обработки вложенного фрагмента . |
| version | Версия примененного протокола. В данном документе описывается TLS версии 1.0, который использует версию { 3, 1 }. Значение версии 3.1 является исторической: TLS версии 1.0 является минимальной модификацией протокола SSL 3.0, который несет значение версии 3.0. (Смотри приложение A.1). |
| length | Длина (в байтах) следующего TLSPlaintext.fragment. Длина не должна превосходить 214. |
| Fragment | Прикладные данные. Эти данные прозрачны и обрабатываются как независимые блоки, с которыми должен работать протокол верхнего уровня, который специфицирован полем тип. |
Данные различных типов содержимого уровня записей TLS могут перекрываться. Прикладные данные вообще имеют более низкий приоритет при передаче, чем другие типы содержимого.
Группы обслуживания случаев нарушения безопасности
Сейчас существует несколько бригад по ликвидации инцидентов CSIRT (Computer Security Incident Response teams), таких как Координационный центр CERT, Германский DFN-CERT и другие команды разбросанные по всему миру. Команды существуют во многих правительственных агентствах и больших корпорациях. Если имеется такая команда, ее оповещение должно быть главным приоритетом на ранних стадиях инцидента. Эти команды ответственны за координацию действий в области сетевой безопасности больших объединений узлов и других крупных объектов. Даже если инцидент ограничен одним узлом, возможно, что информация, имеющаяся в команде по ликвидации инцидентов, может помочь решить проблемы, связанные инцидентом.
Если определено, что уязвимость возникла благодаря пороку в системном оборудовании или программе, об этом должны быть проинформированы немедленно изготовитель (или поставщик) и команда по ликвидации инцидента. Это особенно важно, так как многие другие системы уязвимы и эти поставщики и команды могут помочь другим потенциально уязвимым узлам.
При формировании политики узла в отношении инцидентов, может быть желательно создать субгруппу, очень похожую на уже существующие бригады, которая будет ответственна за обеспечение безопасности узла (или организации). Если такая команда создана, существенно, чтобы были открыты коммуникационные линии между этой и другими аналогичными командами. Когда инцидент произошел, трудно открыть доверительный диалог между разными командами, если их не существует.
Hello done сервера
Сообщение сервера hello done посылается сервером, чтобы индицировать конец hello сервера и связанных с ним сообщений. После отправки этого сообщения сервер ждет отклика клиента.
Это сообщение означает, что сервер завершил подготовку для ключевого обмена, и клиент может приступить к процедуре пересылки ключей.
По получении сообщения сервера hello done клиент должен проверить, что сервер предоставил корректный сертификат, если это требуется, и что параметры, присланные сервером приемлемы.
Структура этого сообщения: struct { } ServerHelloDone;
Hello клиента
Когда клиент инициализирует соединение с сервером, первым должно быть послано сообщение client hello. Клиент может также послать client hello в качестве отклика на запрос hello или по своей собственной инициативе, для того чтобы заново согласовать параметры безопасности существующего соединения.
Сообщение hello клиента включает в себя случайную структуру, которая позднее используется протоколом.
struct { uint32 gmt_unix_time; opaque random_bytes[28];} Random;
| gmt_unix_time | Текущее время и дата согласно стандарта UNIX в 32-битовом формате (число секунд с момента полуночи 1-го января, 1970, GMT) согласно показаниям внутренних часов отправителя. Часы могут и не быть точно выверены на уровне протокола TLS. Прикладные протоколы могут накладывать дополнительные ограничения. |
| random_bytes | 28 байт сформированных безопасным генератором случайных чисел. |
Сообщение client hello включает в себя идентификатор сессии переменной длины. Если это поле не пусто, его значение идентифицирует сессию, чьи параметры безопасности клиент желает использовать повторно. Идентификатор сессии может соответствовать какому-то предшествующему соединению, текущему соединению, или другому активному соединению. Вторая опция полезна, если клиент хочет изменить случайные структуры и получить текущие значения параметров соединения, в то время как третья опция делает возможным установить несколько независимых безопасных соединений без повторения всей процедуры протоколы диалога. Эти независимые соединения могут существовать последовательно или одновременно; SessionID становится действенным, когда диалог согласования завершается обменом сообщениями Finished, и сохраняется до тех пор, пока не состарится или из-за фатальной ошибки в соединении данной сессии. Действительное содержимое SessionID определяется сервером.
opaque SessionID<0..32>;
Так как SessionID передается без шифрования или MAC-защиты, серверы не должны помещать конфиденциальные данные в идентификаторы сессий, что могло бы привести к возрастанию уязвимости.
Заметим, что содержимое диалога в целом, включая SessionID, защищено сообщениями Finished, пересылаемыми в конце диалога.
Список CipherSuite, передаваемый от клиента серверу в сообщении client hello, содержит комбинации криптографических алгоритмов, поддерживаемых клиентом в порядке их предпочтения (предпочтительный вариант - первый). Каждый CipherSuite определяет алгоритм пересылки ключей, алгоритм массового шифрования (включая длину секретного ключа) и алгоритм MAC. Сервер выберет шифровой набор или, если приемлемого варианта нет, пришлет уведомление об ошибке и прервет соединение.
uint8 CipherSuite[2]; /* Cryptographic suite selector */
Hello клиента включает в себя список алгоритмов сжатия, поддерживаемых клиентом, в порядке их предпочтения.
enum { null(0), (255) } CompressionMethod;
| struct | { ProtocolVersion client_version; |
| Random random; | |
| SessionID session_id; | |
| CipherSuite cipher_suites<2..216-1>; | |
| CompressionMethod compression_methods<1..28-1>; | |
| } ClientHello; |
| client_version | Версия протокола TLS, которой хочет воспользоваться клиент во время сессии. Это должна быть последняя версия (с наибольшим кодом), поддерживаемая клиентом. Для данной спецификации значение версии равно 3.1 (Смотри приложение E об обратной совместимости). |
| Random | Псевдослучайная структура, генерируемая клиентом. |
| session_id | ID-сессия, которую клиент хочет использовать для данного соединения. Это поле должно быть пустым, если нет ни одного session_id или клиент хочет выработать новые параметры безопасности. |
| cipher_suites | Список криптографических опций, поддерживаемых клиентом в порядке предпочтения. Если поле session_id не пусто (запрос восстановления сессии), этот вектор должен включать по крайней мере cipher_suite данной сессии. Значения определены в приложении A.5. |
| compression_methods | Список методов сжатия, поддерживаемых клиентом в порядке их предпочтения. Если поле session_id не пусто (запрос восстановления сессии) он должен включать compression_method данной сессии. Этот вектор должен содержать, а все реализации должны поддерживать CompressionMethod.null. Таким образом, клиент и сервер всегда могут согласовать метод сжатия информации. |
В интересах прямой совместимости, клиенту разрешено включать в сообщение client hello после методов сжатия дополнительные данные. Эти данные должны быть включены в хэши диалога, в противном случае они игнорируются. Это единственное сообщение диалога, для которого это допускается; для всех остальных сообщений, объем данных должен точно соответствовать описанию сообщения.
Hello сервера
Сервер посылает это сообщение в ответ на сообщение client hello, когда он может найти приемлемый набор алгоритмов. Если он не может сделать приемлемый выбор, он реагирует уведомлением об ошибке диалога.
Структура этого сообщения:
| Struct | { ProtocolVersion server_version; |
| Random random; | |
| SessionID session_id; | |
| CipherSuite cipher_suite; | |
| CompressionMethod compression_method; | |
| } ServerHello; |
| server_version | Это поле будет содержать самое низкое значение, которое предлагается клиентом в client hello и наибольшее значение версии, поддерживаемое сервером. Значение версии данной спецификации равно 3.1 (по поводу обратной совместимости смотри Приложение E). |
| Random | Эта структура генерируется сервером и должна быть отличной от ClientHello.random. |
| session_id | Идентифицирует сессию, соответствующую данному соединению. Если ClientHello.session_id не пусто, сервер будет искать соответствие с содержимым своего кэша сессий. Если соответствие найдено и сервер хочет установить новое соединение, используя специфицированное состояние сессии, он откликнется тем же значением ID, что было прислано клиентом. Это индицирует возобновляемую сессию и диктует, что партнеры должны продолжить обмен сообщениями finished. В противном случае это поле будет содержать другое значение идентифицирующее новую сессию. Сервер может вернуть пустое поле session_id, чтобы индицировать, что сессия не будет кэшироваться и, следовательно, не может быть возобновлена. Если сессия возобновлена, она должна использовать тот же шифровой набор, который был согласован ранее. |
| cipher_suite | Шифровой набор, выбранный сервером из списка в ClientHello.cipher_suites. Для возобновленных сессий это поле несет в себе значение, взятое из состояния возобновляемой сессии. |
| compression_method | Алгоритм сжатия, выбранный сервером из списка в ClientHello.compression_methods. Для возобновляемых сессий это поле содержит значение из состояния возобновляемой сессии. |
HMAC и псевдослучайные функции
Ряд операций на уровне записей и диалога требуют ключевого MAC; это дайджест определенных данных, защищенных секретным кодом. Фальсификация MAC невозможна без знания секретного кода. Конструкция, которая используется для этой операции, имеет название HMAC и описана в [HMAC].
HMAC может использоваться с разными хэш-алгоритмами. TLS использует ее при диалоге с другими алгоритмами: MD5 и SHA-1, обозначая их как HMAC_MD5(secret, data) и HMAC_SHA(secret, data). Для других шифровых наборов и защищенных данных могут быть определены дополнительные хэш-алгоритмы, но в данной версии протокола для целей диалога жестко заданы MD5 и SHA-1.
Кроме того, необходима схема расширения применения секретных кодов (secret) на блоки данных с целью генерации ключей и валидации. Такая псевдослучайная функция (PRF) использует в качестве входной информации секретный код, порождающий код (seed) и идентификационную метку (label). При этом формируется выходной массив произвольной длины.
Для того чтобы сделать PRF максимально секретной, она использует два хэш-алгоритма так, чтобы гарантировать секретность при сохранении работоспособности хотя бы одного из них.
Сначала, определена функция разложения данных, P_hash(secret, data), которая использует одну хэш функция для распространения секретного кода на произвольное число выходов:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
| HMAC_hash(secret, A(2) + seed) + | |
| HMAC_hash(secret, A(3) + seed) + ... |
где + обозначает объединение.
A() определено как:
| A(0) = seed | |
| A(i) = HMAC_hash(secret, A(i-1)) |
Для требуемого качества данных P_hash может итерироваться столько раз, сколько нужно. Например: если P_SHA-1 использовался для формирования 64 байт данных, его следует итерировать четыре раза (до A(4)), создавая 80 байт выходных данных; последние 16 байт последней итерации будут отброшены, оставляя 64 байта.
PRF TLS создана путем расщепления секретного кода на две части и использования одной половины для генерации данных с помощью P_MD5, а другой половины - для формирования данных посредством P_SHA-1, выходные данных этих двух процедур объединяются затем с помощью операции исключающего ИЛИ.
S1 и S2 являются двумя равными по длине половинами секретного кода. Их длина определяется путем округления результата деления исходного секретного кода на два. Таким образом, если исходный секретный код имеет длину в байтах, характеризуемую нечетным числом, то последний байт S1 будет тем же, что и первый байт S2.
L_S = длина секретного кода в байтах;
L_S1 = L_S2 = ceil(L_S / 2);
PRF определяется как результат смешения двух псевдослучайных потоков с помощью операции исключающее ИЛИ.
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);
Метка представляет собой ASCII-строку. Она должна быть включена в исходном виде без байта длины или завершающего нуля. Например: метка "slithy toves" будет представлена в виде:
73 6C 69 74 68 79 20 74 6F 76 65 73
Заметим, что, так как MD5 выдает на выход 16 байт, а SHA-1 - 20 байт, границы их внутренних итераций не будут выровнены; чтобы сформировать на выходе 80 байт P_MD5 осуществит итерации до A(5), в то время как P_SHA-1 - до A(4).
Хорошее гражданство в Интернет
При инциденте имеется два варианта поведения. В первом, узел может выбрать слежение за атакером с надеждой поймать его; или, узел может заняться очисткой системы и предотвращением дальнейшего проникновения в нее атакера. Это решение должно приниматься весьма обдуманно, так как может возникнуть юридическая ответственность, если вы решите оставить ваш узел открытым, а хакер воспользуется вашим узлом в качестве стартовой площадки для атаки других узлов. Быть хорошим гражданином Интернет означает, что вы должны стараться предупреждать прочие узлы, что они могут подвергнуться атаке.
IDEA - международный алгоритм шифрования данных
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
IDEA является блочным алгоритмом шифрования данных, запатентованным швейцарской фирмой Ascom (http://fn2.freenet.edmonton.ab.ca/~jsavard/co0404.html). Фирма, правда, разрешила бесплатное некоммерческое использование своего алгоритма (применяется в общедоступном пакете конфиденциальной версии электронной почты PGP). Здесь в отличие от алгоритма DES не используются S-блоки или таблицы просмотра. В IDEA применяются 52 субключа, каждый длиной 16 бит. Исходный текст в IDEA делится на четыре группы по 16 бит. Для того чтобы комбинировать 16 битные коды, используется три операции: сложение, умножение и исключающее ИЛИ. Сложение представляет собой обычную операцию по модулю 65536 с переносом. При составлении таблицы умножения принимаются специальные меры для того, чтобы операция была обратимой. По этой причине вместо нуля используется код 65536. Рассмотрим алгоритм IDEA.
Пусть четыре четверти исходного текста имеют имена A, B, C и D, а 52 субключа – К(1), К(2),…, К(52). Перед реализацией алгоритма выполняются операции:
А = А*К(1); B = B + K(2); C = C + K(3); D = D * K(4);
Первый цикл вычислений включает в себя:
E = A XOR C; F = B XOR D
E = E * K(5)
F = F + E
F = F * K(6)
E = E + F
A = A XOR F
C = C XOR F
B = B XOR E
D = D XOR E
Меняем местами В и С.
Повторяем это всё 8 раз, используя К(7) – К(12) для второго раза и, соответственно, К(43) – К(48) - для восьмого. После восьмого раза В и С местами не меняются. Выполняем после этого операции:
A = A * K(49)
B = B + K(50)
C = C + K(51)
D = D * K(52)
В результате закодированный текст имеет ту же длину, что и исходный. Схема этого весьма запутанного алгоритма может быть пояснена на рис. 6.4.7.1. По своему характеру алгоритм напоминает процедуры вычисления хэш-функции.
Рис. 6.4.7.1. Схема реализации алгоритма шифрования IDEA
При дешифровке используется тот факт, что A XOR B не изменяется, если C A и B будет произведена операция XOR C использованием любого числа. Это утверждение справедливо для любых значений А и В.
Операции сложения ( слагаемые заменяются их дополнением по модулю 2) и умножения (множители заменяются из обратными величинами по модулю 65537) также допускают инверсию. Первые четыре ключа дешифровки (KD) определяются несколько иначе, чем остальные.
KD(1) = 1/K(49);
KD(2) = -K(50);
KD(3) = -K(51);
KD(4) = 1/K(52);
Последующие операции производятся восемь раз с добавлением 6 к индексу ключей дешифрования и вычитанием 6 из индекса ключей шифрования.
KD(5) = K(47)
KD(6) = K(48)
KD(7) = 1/K(43)
KD(8) = -K(45)
KD(9) = -K(44)
KD(10) = 1/K(46)
Субключи IDEA генерируются следующим образом. 128-битовый ключ IDEA определяет первые восемь субключей (128=8*16). Последующие ключи (44) получаются путем последовательности циклических сдвигов влево этого кода на 25 двоичных разрядов.
SKIPJACK
Skipjack – секретный в прошлом блочный алгоритм, который ассоциируется с микросхемой Clipper (описание стало открытым в июне 1989 года). Алгоритм представляет собой альтернативу решениям, предлагаемым в алгоритмах IDEA и Safer (развитие идей DES, Lucifer и Blowfish). Блок исходных данных также как и в idea разбиваются на четыре группы. Алгоритм легко реализуется на обычной ЭВМ. Skipjack включает в себя 32 цикла шифрования. Эти циклы имеют две разновидности (А и В). Цикл А выполняет следующие операции.
Первая группа бит исходного текста подвергается шифрованию с использованием G-перестановок (четырех цикличный шифр Файстела – специальный класс блочных шифров, где зашифрованный текст получается из исходного путем многократного использования одного и того же преобразования, напоминает шифр DES. Исходный текст разделяется на две части. Функция преобразования f и ключ используются для преобразования одной из половин а результат объединяется со второй частью исходного кода с помощью операции исключающее ИЛИ. После этого части меняются местами и процедура повторяется и т.д.). Для полученного результата и номера цикла (RN = 1-32) и четвертой группы исходного текста (W4) выполняется операция XOR.
После этого производится перенос: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1.
Цикл В осуществляет следующие преобразования.
Для второй группы бит исходного текста (W2) выполняется операция XOR с номером цикла и первой группой бит исходного текста (W2 = (W2 XOR RN) XOR W1). Затем первая группа блока (W1) подвергается шифрованию с использованием G-перестановок. После этого производится перенос данных: W1 -> W2; W2 -> W3; W3 -> W4; W4 -> W1.
Последовательность выполнения алгоритма Skipjack предполагает выполнение 8 циклов типа А, 8 циклов В, 6 циклов А и 8 циклов В.
Рис. 6.4.7.2. Блок-схема алгоритма шифрования Skipjack
G-перестановки включают в себя разделение группы из 16 бит на две подгруппы по 8 бит. Подобно DES левая половина кода не изменяется в процессе реализации цикла шифрования, а используется в качестве входного параметра F-функции, для результата которой и правой части кода выполняется операция XOR. В отличии от DES половины кода меняются местами лишь после завершающего цикла.
F-функция G-перестановок достаточно проста: входные данные и субключ цикла объединяются операцией XOR, а результат заменяется кодом из таблицы просмотра (lookup-таблица - F). Субключи для G имеют длину 8 бит и являются первыми четырьмя байтами 80-битового исходного ключа. Первые 4 байта используются в первом цикле, следующие 4 – во втором, последние 2 байта вместе с первыми двумя – в третьем и т.д. 12 первых циклов реализации алгоритма шифрования Skipjack показаны на рис. 6.4.7.2. Первый цикл типа А отображен вместе со схемой реализации G-функции. Для следующих 7 циклов типа А G-функция отмечена квадратиком с буквой G. Цифрами (1-12) отмечен ввод данных для цикла с соответствующим номером. При реализации F-функции используется таблица (16*16) перестановок кодов 0-255.
В случае дешифровки циклы выполняются в обратном порядке. Аналогом цикла А при дешифровке является последовательность операций:
Для групп бит W1 и W2 и номера цикла выполняется операция XOR (циклы здесь нумеруются, начиная с 32 до 1).Затем W2 подвергается обратной G-перестановке, после чего выполняется перенос: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3. Аналог цикла типа В при дешифровке включает в себя следующие операции:
Группа бит W2 подвергается обратной G-перестановке. W3 объединяется с номером цикла и группой бит W2 с помощью операции исключающее ИЛИ. После чего производится перемещение: W1 -> W4; W2 -> W1; W3 -> W2; W4 -> W3.
Идентификация реальных потребностей в услугах
Существует большое разнообразие услуг, которые могут быть предоставлены, как локально, так и через Интернет. Управление безопасностью является во многих отношениях, управлением доступом к внутренним услугам и управлением тем, как внутренние пользователи осуществляют доступ к информации внешних узлов.
Услуги имеют тенденцию распространяться подобно волнам по Интернет. За годы во многих узлах были установлены анонимные FTP-серверы, серверы gopher, серверы wais, WWW-серверы и т.д., так как они становились популярными, но не были особенно нужны во всех узлах. Оцените все новые услуги скептически и определите, нужны ли они на самом деле или являются лишь модной прихотью Интернет.
Следует учитывать, что в случае предоставлении нескольких услуг сложность обеспечения безопасности может расти экспоненциально. Фильтрующие маршрутизаторы для поддержания новых протоколов должны быть модифицированы. Некоторые протоколы в действительности трудно фильтровать безопасным образом (например, услуги RPC и UDP), таким образом, предоставляя больше окон уязвимости внутренней сети. Услуги, предоставляемые на той же машине, могут взаимодействовать катастрофическим образом. Например, разрешение анонимного FTP на некоторой машине, которая выполняет функцию WWW-сервера, может позволить атакеру записать в область анонимного FTP некоторый файл, после чего запустить его посредством HTTP-сервера.
