forked from vlsergey/infosec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
ipsec.tex
164 lines (115 loc) · 17.3 KB
/
ipsec.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
\section{Защита IPsec на сетевом уровне}
\selectlanguage{russian}
Набор протоколов IPsec (Internet Protocol Security) является неотъемлемой частью IPv6 и дополнительным необязательным расширением IPv4. IPsec обеспечивает защиту данных на сетевом уровне IP-пакетов.
IPsec определяет:
\begin{itemize}
\item первичную аутентификацию сторон и управление сеансовыми ключами (протокол IKE, Internet Key Exchange),
\item шифрование с аутентификацией (протокол ESP, Encapsulating Security Payload),
\item только аутентификацию сообщений (протокол AH, Authentication Header).
\end{itemize}
Основное (современное) применение этих протоколов состоит в построении виртуальных сетей VPN (virtual private network) при использовании IPsec в, так называемом, туннельном режиме.
Аутентификация в режимах ESP и AH определяется по-разному. Аутентификация в ESP гарантирует целостность только зашифрованных полезных данных (пакетов следующего уровня после IP). Аутентификация AH гарантирует целостность всего IP-пакета (за исключением полей, изменяемых в процессе передачи пакета по сети).
\subsection{Протокол создания ключей IKE}
%http://www.ietf.org/rfc/rfc4306.txt
Протокол IKE версии 2 (Internet Key Exchange), по существу, можно описать следующим образом. Пусть $I$ -- инициатор соединения, $R$ -- отвечающая сторона.
Протокол состоит из двух фаз. Первая фаза очень похожа на установление соединения в SSL/TLS, она включает возможный обмен сертификатами $C_I, C_R$ стандарта X.509 для аутентификации (или альтернативную аутентификацию по общему заранее созданному секретному ключу) и создание общих предварительных сеансовых ключей протокола IKE по протоколу Диффи--Хеллмана. Сеансовые ключи протокола IKE служат для шифрования и аутентификации сообщений второй фазы. Вторая фаза создает сеансовые ключи для протоколов ESP, AH, то есть ключи для шифрования конечных данных. Сообщения второй фазы также используются для смены ранее созданных сеансовых ключей, и в этом случае протокол сразу начинается со второй фазы с применением ранее созданных сеансовых ключей протокола IKE.
\begin{enumerate}
\item Создание предварительной защищенной связи для протокола IKE и аутентификация сторон.
\begin{enumerate}
\item $I \rightarrow R$: ~ $\left(g^{x_I}\right.$, одноразовая метка $N_I$, идентификаторы поддерживаемых криптографических алгоритмов$\left.\right)$.
% HDR, SAi1, KEi, Ni -->
\item $I \leftarrow R$: ~$\left(g^{x_R}\right.$, одноразовая метка $N_R$, идентификаторы выбранных алгоритмов, запрос сертификата $C_I\left.\right)$.
% <-- HDR, SAr1, KEr, Nr, [CERTREQ]
Протокол Диффи--Хеллмана оперирует с генератором $g=2$ в группе $\Z_p^*$ для одного из двух фиксированных $p$ длиной 768 или 1024 бита. После обмена элементами $g^{x_I}$ и $g^{x_R}$ обе стороны обладают общим секретом $g^{x_I x_R}$.
Одноразовые метки $N_I, N_R$ созданы криптографическим генератором псевдослучайных чисел $PRF$.
После данного сообщения стороны договорились об используемых алгоритмах и создали общие сеансовые ключи:
\[ seed = PRF(N_i ~\|~ N_r, ~g^{x_I x_R}), \]
\[ \{ K_d \| Ka_I \| Ka_R \| Ke_I \| Ke_R
% \| Kp_I \| Kp_R
\} = PRF(seed, ~ N_i ~\|~ N_r), \]
где $Ka_I, Ka_R$ -- ключи кода аутентификации для связи в оба направления, ~ $Ke_I, Ke_R$ -- ключи шифрования сообщений для двух направлений, ~ $K_d$ -- инициирующее значение генератора $PRF$ для создания сеансовых ключей окончательной защищенной связи, ~ функцией $PRF(x)$ обозначается выход генератора с инициализирующим значением $x$.
%$Kp_I, Kp_R$ -- which areused when generating an AUTH payload.
Дальнейший обмен данными зашифрован алгоритмом AES в режиме CBC со случайно выбранным инициализирующим вектором $IV$ на сеансовых ключах $Ke$ и аутентифицирован кодом аутентификации сообщений на ключах $Ka$. Введем обозначения для шифрования сообщения $m$ со сцеплением блоков $E_{Ke_X}(m)$ и совместного шифрования и добавления кода аутентификации сообщений $\langle m \rangle_X$ для исходящих данных от стороны $X$:
\[ E_{Ke_X}(m) = IV ~\|~ E_{Ke_X}(IV ~\|~ m), \]
\[ \langle m \rangle_X = E_{Ke_X}(m) ~\|~ \HMAC(Ka_X, ~ E_{Ke_X}(m)). \]
\item $I \rightarrow R$: ~ $\langle ID_I, ~ C_I, ~\text{запрос сертификата}~ C_R, ~ ID_R, ~ A_I \rangle_I$.
% HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} -->
По значениям идентификаторов $ID_I, ID_R$ сторона $R$ проверяет знание стороной $I$ ключей $Ke, Ka$.
Поле $A_I$ обеспечивает аутентификацию стороны $I$ стороне $R$ по одному из двух способов. Если используются сертификаты, то $I$ показывает, что обладает секретным ключом, парным открытому ключу сертификата $C_I$, подписывая сообщение $data$:
\[ A_I = \textrm{ЭЦП}(data). \]
Сторона $R$ также проверяет сертификат $C_I$ по цепочке до доверенного сертификата верхнего уровня.
Второй вариант аутентификации -- по общему секретному симметричному ключу аутентификации $K_{IR}$, который заранее был создан $I$ и $R$, как в Kerberos. Сторона $I$ показывает, что знает общий секрет, вычисляя
\[ A_I = PRF( PRF(K_{IR}, ~ \text{текст ''Key Pad for IKEv2''}), ~ data). \]
Сторона $R$ сравнивает присланное значение $A_I$ с вычисленным и убеждается, что $I$ знает общий секрет.
Сообщение $data$ -- это открытое сообщение данной транзакции, за исключением нескольких полей.
\item $I \leftarrow R$: ~ $\langle ID_R, ~ C_R, ~ A_R \rangle_R$.
% HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}
Производится аутентификация стороны $R$ стороне $I$ аналогичным образом.
\end{enumerate}
\item Создание защищенной связи для протоколов ESP, AH, то есть ключей шифрования и кодов аутентификации конечных полезных данных. Фаза повторяет первые две транзакции первой фазы с созданием ключей по одноразовой метке $N'$ и протоколу Диффи--Хеллмана с секретными ключами $x'$.
\begin{enumerate}
\item $I \rightarrow R$: ~ $\langle g^{x'_I}$, одноразовая метка $N'_I$, поддерживаемые алгоритмы для ESP, AH$\rangle_I$.
% HDR, SK {[N], SA, Ni, [KEi], [TSi, TSr]} -->
\item $I \rightarrow R$: ~ $\langle g^{x'_R}$, одноразовая метка $N'_R$, выбранные алгоритмы для ESP, AH$\rangle_R$.
% <-- HDR, SK {SA, Nr, [KEr], [TSi, TSr]}
\end{enumerate}
По окончании второй фазы обе стороны имеют общие секретные ключи $Ke, Ka$ для шифрования и кодов аутентификации в двух направлениях, от стороны $I$ и от стороны $R$:
\[ \{Ka'_I ~\|~ Ka'_R ~\|~ Ke'_I ~\|~ Ke'_R \} = PRF(K_d, ~ g^{x'_I x'_R} ~\|~ N'_I ~\|~ N'_r). \]
\end{enumerate}
Итогом протокола IKE является набор сеансовых ключей для шифрования $Ke'_I, ~ Ke'_R$ и кодов аутентификации $Ka'_I, ~ Ka'_R$ в протоколах ESP и AH.
\subsection{Таблица защищенных связей}
\textbf{Защищенная связь} (security association, SA) является \emph{однонаправленной} от отправителя к получателю и характеризуется тремя основными параметрами:
\begin{itemize}
\item индексом параметров защиты -- уникальное 32-битовое число, входит в заголовок ESP- и AH- пакетов,
\item IP-адресом стороны-отправителя,
\item идентификатором применения ESP- или AH-протокола.
\end{itemize}
Защищенные связи хранятся в таблице защищенных связей со следующими полями.
\begin{itemize}
\item Счетчик порядкового номера, входит в заголовок ESP- и AH-пакетов.
\item Окно защиты от воспроизведения -- скользящий буфер порядковых номеров пакетов для защиты от пропуска и повтора пакетов.
\item Информация протокола ESP и AH -- алгоритмы, ключи, время действия ключей.
\item Режим протокола: транспортный или туннельный
\end{itemize}
По индексу параметров защиты, находящемся в заголовке ESP- и AH-пакетов, получатель из таблицы защищенных связей извлекает параметры (названия алгоритмов, ключи и т.д.), производит проверки счетчиков, аутентифицирует и расшифровывает вложенные данные для принятого IP-пакета.
%Или создает зашифрованный аутентифицированный IP пакет, который включает индекс параметров защиты, чтобы получатель мог из своей таблицы защищенных связей извлечь ключи для аутентификации и расшифрования.
Протоколы ESP и AH можно применять к IP-пакету в трех вариантах:
\begin{itemize}
\item только ESP-протокол,
\item только AH-протокол,
\item последовательное применение ESP и AH протоколов.
\end{itemize}
Подчеркнем, что только AH-протокол гарантирует целостность всего IP-пакета, поэтому для организации виртуальной сети VPN, как правило, применяется третий вариант (последовательно ESP и AH протоколы).
\subsection{Транспортный и туннельный режимы}
Протоколы ESP, AH могут применяться в транспортном режиме, когда исходный IP-пакет расширяется заголовками и концевиками протоколов ESP, AH, или в туннельном режиме, когда весь IP-пакет вкладывается в новый IP-пакет, который включает заголовки и концевики ESP, AH.
Новый IP-пакет в туннельном режиме может иметь другие IP-адреса, отличные от оригинальных. Именно это свойство используется для построения виртуальных частных сетей (Virtual Private Network, VPN)\index{VPN}. IP-адресом нового пакета является IP-адрес IPsec шлюза виртуальной сети. IP-адрес вложенного пакета является локальным адресом виртуальной сети. IPsec шлюз производит преобразование IPsec пакетов в обычные IP-пакеты виртуальной сети и наоборот.
Схемы транспортного и туннельного режимов показаны ниже отдельно для ESP- и AH-протоколов.
\subsection{Протокол шифрования и аутентификации ESP}
Протокол ESP определяет шифрование и аутентификацию вложенных в IP-пакет сообщений в формате, показанном на рис. \ref{fig:ipsec-esp}.
\begin{figure}[h!]
\centering
\includegraphics[width=0.9\textwidth]{pic/ipsec-esp}
\caption{Формат ESP пакета\label{fig:ipsec-esp}}
\end{figure}
Шифрование вложенных данных производится в режиме CBC алгоритмом AES на ключе $Ke'$ с псевдослучайным вектором инициализации IV, вставленном перед зашифрованными данными.
Аутентификатор сообщения определяется как усеченное до 96 бит значение $\HMAC(Ka', m)$, вычисленное стандартным способом.
\begin{figure}[h!]
\centering
\includegraphics[width=0.9\textwidth]{pic/ipsec-esp-modes}
\caption{Применение ESP протокола к пакету IPv6\label{fig:ipsec-esp-modes}}
\end{figure}
На рис. \ref{fig:ipsec-esp-modes} показано применение протокола в транспортном и туннельном режимах.
\subsection{Протокол аутентификации AH}
Протокол AH определяет аутентификацию всего IP пакета в формате, показанном на рис. \ref{fig:ipsec-ah}.
\begin{figure}[h!]
\centering
\includegraphics[width=0.7\textwidth]{pic/ipsec-ah}
\caption{Заголовок AH пакета\label{fig:ipsec-ah}}
\end{figure}
Аутентификатор сообщения определяется так же, как и в протоколе ESP -- усеченное до 96 бит значение $\HMAC(Ka', m)$, вычисленное стандартным способом.
\begin{figure}[h!]
\centering
\includegraphics[width=0.9\textwidth]{pic/ipsec-ah-modes}
\caption{Применение AH протокола к пакету IPv6\label{fig:ipsec-ah-modes}}
\end{figure}
На рис. \ref{fig:ipsec-ah-modes} показано применение протокола в транспортном и туннельном режимах.