Serguei E. Leontiev
2012-02-23 11:24:23 UTC
Всем привет,
Есть ли кто еще в этой конференции ФИДО? А то вот конференцию RU.CRYPT на
2:5020/400 (news.fido7.ru) даже и не видно в списке групп новостей, быть
может, там уже и никого нет.
Собственно, хозяйкам на заметку предлагается краткая, немного утрированная
история блочных режимов (CBC Block Cipher) в части обеспечения
конфиденциальности (TLS протокол большой и требует целой монографии для
изложения своей истории и всех своих защитных свойств).
Кратко, строго говоря, блочные режимы TLS 1.2, 1.1, 1.0, SSL 3.0, в общем
случае, не обеспечивают конфиденциальности передаваемой информации. Только
старый добрый SSL 2.0 ее обеспечивает для сессий разумного размера, но его
запретили.
SSL 2.0 <http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html>
и <http://tools.ietf.org/html/draft-hickman-netscape-ssl-00>
Имеет формат записи:
MAC-DATA[MAC-SIZE]
ACTUAL-DATA[N]
PADDING-DATA[PADDING]
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]
Лично мне не известны атаки нарушающие конфиденциальность этой записи с
приемлемой вероятностью, за исключением набора статистики на объемах
порядка sqrt(2^<длина блока шифра>), т.е. порядка гигабайт.
К несчастью, злые люди его запретили <http://tools.ietf.org/html/rfc6176>.
SSL 3.0 <http://tools.ietf.org/html/rfc6101#section-5.2.3.2> и
<http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00>
Формат записи:
block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
MAC (имитовставку) перенесли в середину, тем самым открыли возможность атак
с навязыванием синхропосылки (IV). Атака (1)
И возможность существования реализаций, которые обрабатывают записи по
частям, соответственно, адаптивных атак с выбором открытого текста. Атака
(2)
MAC = HMAC(write-secret, seq_num +
SSLCompressed.type + SSLCompressed.length +
SSLCompressed.fragment))
Из расчета MAC исключили выравнивание (padding), тем самым открыли
возможность атак основанных на оракуле формата данных, либо по сообщениям
об ошибке, либо по времени обработки. Атака (3)
Hеясно зачем включили длину данных в расчет, хэш функции и так ее включают.
Использование HMAC() так же было бы необязательно, если бы seq_num
оставили бы в конце записи. Тогда HMAC был еще не слишком известен, его
даже записали явно в виде формулы из двух хэш функций.
TLS 1.0 <http://tools.ietf.org/html/rfc2246>
Ввел возможность использования выравнивания длиной до 255 байт, тем самым
открыл возможность атак основанных на разнице времен обработки для коротких
записей. Атака (4)
TLS 1.1 <http://tools.ietf.org/html/rfc4346#section-6.2.3.2>
Формат записи:
block-ciphered struct {
opaque IV[CipherSpec.block_length];
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
Ввели синхропосылку (IV) в явном виде для защиты от атак типа (1), однако
кажется, что некоторые из рекомендованных способов ее генерации
некорректны.
Дополнительно, описали атаки типа (2) и рекомендовали обрабатывать записи
"целиком", почему-то упомянули только режим CBC. Так же замечу, что
рекомендации относятся только к шифрованию, хотя для обеспечения других
криптографический свойств, отличных от конфиденциальности, расшифрование
"целиком" критически важно.
Еще описали атаки основанные на разнице времен обработки, к сожалению,
рекомендованный "наилучший" способ обработки блокирует только атаки типа
(3). Известные мне реализации TLS 1.1 подвержены атакам типа (4).
TLS 1.2 <http://tools.ietf.org/html/rfc5246#section-6.2.3.2>
Hемного изменили описание синхропосылки существенно его улучшив, однако IV
не входит в рассчет MAC, в результате, вероятно, возможны адаптивные атаки
на целостность. Кроме того, длину IV внесли в параметры безопасности и
немного изменили описание формата (только описание).
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
К сожалению, рекомендованный "наилучший" способ обработки не претерпел
изменений и блокирует только атаки типа (3). Известные мне реализации TLS
1.2 подвержены атакам типа (4).
Резюме. Или как жить?
Строго говоря, в общем случае, пользоваться блочными режимами лучше не
надо. Т.к. в этой краткой истории упомянуты только более или менее
известные проблемы и не все они решены. Заметим, что блочный режим
шифрования не удовлетворяет некоторым теоретическим положениям, например,
работе Кравчика, т.к. он увеличивает длину без соответствующих мер защиты.
Поэтому, существует вероятность появления новых проблем.
По этому, в общем случае, лучше использовать, либо поточный режим (Standard
Stream Cipher) [TLS_RSA_WITH_RC4_128_SHA,
TLS_GOSTR341001_WITH_28147_CNT_IMIT, да даже TLS_RSA_WITH_RC4_128_MD5 можно
использовать], либо комбинированные режимы (AEAD Ciphers) введенные в TLS
1.2.
Как вариант, если быть оптимистами, то можно, в предположении, что за время
эксплуатации Вашей системы ничего нового не придумают, сделать следующее:
1. Взять "хорошую" реализацию, проверить ее (например, у некоторых "гнутых"
реализаций точно есть проблемы);
2. Исключить использование слишком быстрых сетей (например, поставить
межсетевой экран прямо перед одиночным сервером, никаких виртуальных
машин);
3. Исключить использование слишком медленных компьютеров (например,
запретить сотовые телефоны для использования в Вашей системе);
4. Исключить разделение одного соединения разными подсистемами (например,
разные сайты для информации одного приложения, для информации другого
приложения, для аутентификации и т.п.);
5. Следить за прессой и сохранять оптимизм всеми силами.
Ссылки и формулы по теме, если интересно, можно взглянуть в статье
<http://www.cryptopro.ru/sites/default/files/docs/TLSvsBEAST.pdf>,
<http://www.cryptopro.ru/blog> (блог - осторожно может встретиться реклама)
Есть ли кто еще в этой конференции ФИДО? А то вот конференцию RU.CRYPT на
2:5020/400 (news.fido7.ru) даже и не видно в списке групп новостей, быть
может, там уже и никого нет.
Собственно, хозяйкам на заметку предлагается краткая, немного утрированная
история блочных режимов (CBC Block Cipher) в части обеспечения
конфиденциальности (TLS протокол большой и требует целой монографии для
изложения своей истории и всех своих защитных свойств).
Кратко, строго говоря, блочные режимы TLS 1.2, 1.1, 1.0, SSL 3.0, в общем
случае, не обеспечивают конфиденциальности передаваемой информации. Только
старый добрый SSL 2.0 ее обеспечивает для сессий разумного размера, но его
запретили.
SSL 2.0 <http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html>
и <http://tools.ietf.org/html/draft-hickman-netscape-ssl-00>
Имеет формат записи:
MAC-DATA[MAC-SIZE]
ACTUAL-DATA[N]
PADDING-DATA[PADDING]
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]
Лично мне не известны атаки нарушающие конфиденциальность этой записи с
приемлемой вероятностью, за исключением набора статистики на объемах
порядка sqrt(2^<длина блока шифра>), т.е. порядка гигабайт.
К несчастью, злые люди его запретили <http://tools.ietf.org/html/rfc6176>.
SSL 3.0 <http://tools.ietf.org/html/rfc6101#section-5.2.3.2> и
<http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00>
Формат записи:
block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
MAC (имитовставку) перенесли в середину, тем самым открыли возможность атак
с навязыванием синхропосылки (IV). Атака (1)
И возможность существования реализаций, которые обрабатывают записи по
частям, соответственно, адаптивных атак с выбором открытого текста. Атака
(2)
MAC = HMAC(write-secret, seq_num +
SSLCompressed.type + SSLCompressed.length +
SSLCompressed.fragment))
Из расчета MAC исключили выравнивание (padding), тем самым открыли
возможность атак основанных на оракуле формата данных, либо по сообщениям
об ошибке, либо по времени обработки. Атака (3)
Hеясно зачем включили длину данных в расчет, хэш функции и так ее включают.
Использование HMAC() так же было бы необязательно, если бы seq_num
оставили бы в конце записи. Тогда HMAC был еще не слишком известен, его
даже записали явно в виде формулы из двух хэш функций.
TLS 1.0 <http://tools.ietf.org/html/rfc2246>
Ввел возможность использования выравнивания длиной до 255 байт, тем самым
открыл возможность атак основанных на разнице времен обработки для коротких
записей. Атака (4)
TLS 1.1 <http://tools.ietf.org/html/rfc4346#section-6.2.3.2>
Формат записи:
block-ciphered struct {
opaque IV[CipherSpec.block_length];
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
Ввели синхропосылку (IV) в явном виде для защиты от атак типа (1), однако
кажется, что некоторые из рекомендованных способов ее генерации
некорректны.
Дополнительно, описали атаки типа (2) и рекомендовали обрабатывать записи
"целиком", почему-то упомянули только режим CBC. Так же замечу, что
рекомендации относятся только к шифрованию, хотя для обеспечения других
криптографический свойств, отличных от конфиденциальности, расшифрование
"целиком" критически важно.
Еще описали атаки основанные на разнице времен обработки, к сожалению,
рекомендованный "наилучший" способ обработки блокирует только атаки типа
(3). Известные мне реализации TLS 1.1 подвержены атакам типа (4).
TLS 1.2 <http://tools.ietf.org/html/rfc5246#section-6.2.3.2>
Hемного изменили описание синхропосылки существенно его улучшив, однако IV
не входит в рассчет MAC, в результате, вероятно, возможны адаптивные атаки
на целостность. Кроме того, длину IV внесли в параметры безопасности и
немного изменили описание формата (только описание).
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
К сожалению, рекомендованный "наилучший" способ обработки не претерпел
изменений и блокирует только атаки типа (3). Известные мне реализации TLS
1.2 подвержены атакам типа (4).
Резюме. Или как жить?
Строго говоря, в общем случае, пользоваться блочными режимами лучше не
надо. Т.к. в этой краткой истории упомянуты только более или менее
известные проблемы и не все они решены. Заметим, что блочный режим
шифрования не удовлетворяет некоторым теоретическим положениям, например,
работе Кравчика, т.к. он увеличивает длину без соответствующих мер защиты.
Поэтому, существует вероятность появления новых проблем.
По этому, в общем случае, лучше использовать, либо поточный режим (Standard
Stream Cipher) [TLS_RSA_WITH_RC4_128_SHA,
TLS_GOSTR341001_WITH_28147_CNT_IMIT, да даже TLS_RSA_WITH_RC4_128_MD5 можно
использовать], либо комбинированные режимы (AEAD Ciphers) введенные в TLS
1.2.
Как вариант, если быть оптимистами, то можно, в предположении, что за время
эксплуатации Вашей системы ничего нового не придумают, сделать следующее:
1. Взять "хорошую" реализацию, проверить ее (например, у некоторых "гнутых"
реализаций точно есть проблемы);
2. Исключить использование слишком быстрых сетей (например, поставить
межсетевой экран прямо перед одиночным сервером, никаких виртуальных
машин);
3. Исключить использование слишком медленных компьютеров (например,
запретить сотовые телефоны для использования в Вашей системе);
4. Исключить разделение одного соединения разными подсистемами (например,
разные сайты для информации одного приложения, для информации другого
приложения, для аутентификации и т.п.);
5. Следить за прессой и сохранять оптимизм всеми силами.
Ссылки и формулы по теме, если интересно, можно взглянуть в статье
<http://www.cryptopro.ru/sites/default/files/docs/TLSvsBEAST.pdf>,
<http://www.cryptopro.ru/blog> (блог - осторожно может встретиться реклама)
--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)