Введение
Проектные решения для защиты системы влияют на производительность,
масштабируемость и доступность. Обычно всегда приходится выбирать между
безопасностью и производительностью/ доступностью. Чем более безопасна
система, тем ниже производительность и доступность. При проектировании
защищенной системы необходимо определить все возможные угрозы, уязвимые
места и атаки и выбрать методы реализации защиты, направленные в первую
очередь на снижение угрозы и во вторую очередь на производительность.
В этой статье сравнивается относительная производительность различных
средств защиты, используемых для аутентификации клиента, алгоритмов
хэширования, методов шифрования и цифровых подписей. Для простоты были
выделены различные категории безопасности, и сравнение
производительности отдельно для каждой категории; безопасность реальной
защищенной системы определяется, конечно, комбинацией одной или
нескольких категорий.
Инструментарий и стратегия тестирования
Для тестирования использовался Microsoft Application Center Test
(ACT), предназначенный для стресс-тестов Web-серверов и анализа проблем,
связанных с производительностью и масштабируемостью Web-приложений, в
том числе ASPX-страниц и используемых ими компонентов. Более подробная
информация о создании и запуске тестов содержится в документации к ACT.
С помощью Application Center Test можно смоделировать большую группу
пользователей путем открытия нескольких подключений к серверу и быстрой
отправкой HTTP-запросов. Он также позволяет построить реалистичные
сценарии тестирования, где можно вызвать один и тот же метод со
случайным набором значений параметров. Это важно, поскольку один и тот
же метод с одинаковыми значениями параметров не будет вызываться
пользователями многократно. Другая полезная возможность Application
Center Test - это запись результатов тестирования, в которых содержатся
наиболее важные сведения о производительности Web-приложения.
В ACT поддерживаестя аутентификация Basic, Kerberos и Digest. ACT не
поддерживает автоматическую аутентификацию на уровне ASP.NET Forms. Тело
запроса было явно отредактировано для моделирования передачи клиентской
формы.
В качестве контроллера домена использовался отдельный компьютер. В
Active Directory содержались десять тысяч учетных записей пользователя.
Из такого же числа пользователей во время теста Application Center Test
случайно выбирал того или иного пользователя.
Конфигурация системы
В следующих таблицах содержится краткий обзор конфигурации системы,
используемой для тестирования.
Таблица 1. Конфигурация клиентской системы
Кол-во клиентов |
Компьютер/CPU |
Кол-во CPU |
Память |
Жесткий диск |
Программное обеспечение |
1 |
Compaq Proliant 1130 МГц |
2 |
1 Гбайт |
16,9 Гбайт |
Windows 2000 Advanced Server SP 2 Application Center Test |
Таблица 2. Конфигурация Web-сервера
Кол-во серверов |
Компьютер/CPU |
Кол-во CPU |
Память |
Жесткий диск |
Программное обеспечение |
1 |
Compaq Proliant 1000 МГц |
2 |
1 Гбайт |
16,9 Гбайт |
Windows 2000 Advanced Server SP 2 .NET Framework SP1 |
Таблица 3. Конфигурация сервера приложений
Кол-во серверов |
Компьютер/CPU |
Кол-во CPU |
Память |
Жесткий диск |
Программное обеспечение |
1 |
Compaq Proliant 1126 МГц |
2 |
1 Гбайт |
16,9 Гбайт |
Windows 2000 Advanced Server SP 2 .NET Framework SP1 |
Таблица 4. Конфигурация сервера базы данных
Кол-во серверов |
Компьютер/CPU |
Кол-во CPU |
Память |
Жесткий диск |
Программное обеспечение |
1 |
Compaq Proliant 700 МГц |
4 |
4 Гбайта |
18 Гбайт |
Windows 2000 Advanced Server SP 2 SQL Server Enterprise
Edition SP 2 |
Результаты тестирования производительности
Ключевые показатели производительности – это пропускная способность и
время ожидания. Для заданного объема возвращаемых данных пропускная
способность - это число клиентских запросов, обработанных за
определенную единицу времени, обычно за одну секунду. Поскольку пиковая
пропускная способность может произойти за время ответа, что недопустимо
с точки зрения применимости, отслеживалось время ожидания, измеряемое
как время ответа с помощью отчета, сгенерированного Application Center
Test для каждого тестового прогона.
Примечание. Показатели производительности, сгенерированные для
пропускной способности и времени ожидания, являются лишь основанием для
сравнения этих технологий. Эти показатели не представляют собой
абсолютную производительность.
Аутентификация клиента
Сервер аутентифицирует клиента, принимая его удостоверение и проверяя
достоверность этого удостоверения. Рассмотрим подробнее
аутентификационные режимы, поддерживаемые Microsoft® ASP.NET, включая
Microsoft IIS 5.0 и аутентификацию на уровне ASP.NET Forms. Более
подробная информация содержится в разделе Защита
Web-приложений ASP.NET в Руководстве разработчика .NET Framework.
Получение страницы по умолчанию
В данном тесте отдельный запрос отправляется клиенту одним
пользователем ACT. После запроса страницы пользователь должен
аутентифицировать себя путем предоставления своего имени пользователя и
пароля. После аутентификации пользователя страница возвращается простой
строкой.
Примечание. Этим тестом не моделируется сценарий, где после
аутентификации в первом запросе пользователь отправляют последующие
запросы путем предъявления Web-серверу своеобразного билета,
свидетельствующего об уже выполненной аутентификации.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 1. Аутентификационные режимы: число запросов в секунду и
время ответа
Примечания:
Как и ожидалось, самой высокой оказалась производительность при
анонимном аутентификационном режиме, в котором аутентификация не
выполняется. Web-сервер не требует от клиента посылать удостоверение
пользователя перед просмотром Web-страницы. Этот режим больше всего
подходит для общедоступного сайта.
Во всех остальных аутентификационных режимах клиенту необходимо
послать дополнительные аутентификационные сообщения, что приводит к
дополнительным циклам обработки на Web-сервере. При аутентификациях
Basic, Digest и Kerberos поток HTTP-заголовков выглядит следующим
образом:
|
Дополнительная информация по рисунку
Web client = Web-клиент
Get Default.aspx = получение страницы Default.aspx
Challenge 401 Access Denied = ошибка 401 - доступ запрещен
WWW-Authenticate = Web-аутентификация
Challenge Response = ответ на запрос
Returns Default.aspx = возвращение страницы Default.aspx
Web server = Web-сервер |
Рис. 2. Поток аутентификационных заголовков
Как показано на рис. 1, в аутентификационных режимах Digest и
Kerberos производительность практически одинакова, однако каждый из этих
режимов имеет свои издержки. При аутентификации Digest сервер посылает
клиенту запрос (NONCE) об имени пользователя и пароле. NONCE шифруется с
помощью одностороннего хэша пароля (состоящего из вызываемого ресурса и
области) и затем посылается серверу, подтверждающему аутентификацию
клиента. Пароль не отправляется открытым текстом, что дает преимущество
над аутентификацией Basic. Несмотря на то, что аутентификация Digest
является промышленным стандартом, ее поддерживает только ограниченное
число браузеров и Web-серверов, что является самым большим ее
недостатком и препятствует ее широкому использованию. Впервые поддержка
этой аутентификации наряду с IIS 5.0 и более поздними версиями
реализована в Microsoft® Internet Explorer 5.0. Она выполняется только
для учетных записей домена Windows 2000, в которых пароли должны
храниться в виде зашифрованного открытого текста (обратите внимание, что
в Microsoft® .NET® Server это не имеет места).
В аутентификации Kerberos браузер пытается использовать
пользовательское удостоверение из параметров входа в домен. В случае
отклонения этого пользовательского удостоверения клиент должен ввести в
диалоговом окне свои имя пользователя и пароль. Пользовательское
удостоверение посылается непосредственно серверу службы выдачи билетов,
который подтверждает достоверность удостоверения и выдает клиенту билет
Kerberos. Этот билет является временным сертификатом, который
идентифицирует пользователя на сетевом сервере. Обычно билет кэшируется
на клиенте, что позволяет ему использоваться в последующих запросах
серверу до истечения срока действия.
Как показано на рис. 1, производительность аутентификаций Basic и
FormsAuth_SQL абсолютно одинакова. В аутентификации Basic клиент
посылает пользовательское удостоверение Web-серверу, который выполняет
цикл обработки к контроллеру домена для аутентификации пользователя. Не
следует забывать, что аутентификация Basic чрезвычайно небезопасна,
поскольку пароль передается по сети открытым текстом (фактически он
зашифрован в base64, который можно очень легко расшифровать). Для
повышения безопасности Basic можно использовать SSL, позволяющий
провести безопасный сеанс. Тем не менее, его уровень безопасности не
столь высок по сравнению с любым из реальных сетевых протоколов
аутентификации, например, с Kerberos и Digest, при которых используемые
секретные данные не посылаются удаленному серверу.
Поток HTTP-заголовков для аутентификации на уровне ASP.NET Forms
выглядит следующим образом:
|
Дополнительная информация по рисунку
Web client = Web-клиент
Redirects to Logon Page = перенаправление на страницу
регистрации
Get Logon Page = получение страницы регистрации
Return Logon Page = возвращение страницы регистрации
User Name, Pwd = имя пользователя, пароль
Redirects to Default.aspx = перенаправление на страницу
Default.aspx
Get Default.aspx = получение страницы Default.aspx
Returns Default.aspx = возвращение страницы Default.aspx
Web server = Web-сервер |
Рис. 3. Поток аутентификационных заголовков
Обратите внимание, что производительность аутентификации ASP.NET
Forms ниже, чем всех схем аутентификации Windows. Причиной этому служат
несколько перенаправлений перед показом страницы. При аутентификации
FormsAuth_AD выполняется программный поиск пользователя в Active
Directory. Если пользователь с указанным паролем найден в Active
Directory, аутентификация пользователя подтверждается. Аналогично при
аутентификации FormsAuth_SQL для поиска пользователя в базе данных
система вызывает хранимую процедуру SQL. Если запрос завершен успешно,
аутентификация пользователя подтверждается. Вместо хранения в базе
данных пароля открытым текстом было решено хранить односторонний хэш
пароля пользователя, объединенного с синхропосылкой (salt). Для
генерации хэша использовался SHA1. Так в режиме FormsAuth_SQL, когда
пользователь отправляет свое удостоверение, система сначала получает хэш
и синхропосылку, связанную с пользователем из базы данных. Затем
генерируется хэш переданного пользователем пароля и синхропосылки,
только что полученной из базы данных. При совпадении двух этих хэшей
аутентификация пользователя подтверждается. Для этого процесса требуются
дополнительные циклы, поскольку при подтверждении аутентификации
пользователя хэш генерируется с помощью алгоритма SHA1.
Аутентификация на уровне ASP.NET Forms столь же небезопасна, как и
Basic, поскольку пароль отправляется по сети открытым текстом. Тем не
менее, при этом имеются различия: при аутентификации на уровне Forms
пользовательское удостоверение отсылается один раз, а затем используется
зашифрованный билет, тогда как при аутентификации Basic посылка
пользовательского удостоверения выполняется с каждым запросом. Для
повышения безопасности аутентификации на уровне Forms можно использовать
SSL, который позволяет провести безопасный сеанс; однако при этом
снижается производительность. При использовании аутентификации на уровне
Forms без SSL она не защищена от атаки с повторением пакетов.
Дополнительную информацию об аутентификации см. в разделе
ASP.NET: Руководство по безопасности .NET, где обсуждаются
преимущества и недостатки этих схем аутентификации и среда, для которой
они лучше всего подходят.
Методы шифрования
Методы шифрования (криптографии) обеспечивают защиту данных,
обнаружение вмешательства и аутентификацию путем шифрования данных,
передаваемых между сервером и клиентом, при необходимости передать
секретную информацию и недопустить ее расшифровки. Рассмотрим подробнее
алгоритмы хэширования SHA1 и MD5, симметричные алгоритмы DES, RC2, 3DES
и Rijndael и асимметричные алгоритмы RSA и DSA. Более подробная
информация содержится в разделе
Криптография: обзор в Руководстве разработчика .NET Framework.
Алгоритмы хэширования
Хэш-алгоритмы отображают часть данных произвольного размера в
маленьком уникальном значении фиксированной длины. Сравним алгоритмы
SHA1 и MD5. Более подробная информация содержится в разделе
Криптография: обзор в Руководстве разработчика .NET Framework.
ComputeHash
Этот метод позволяет вычислить хэш данных, сохраненных в файле. Для
анализа влияния размера данных на производительность в тесте
использовались данные размером 4 Кбайт, 135 Кбайт и 1 Мбайт.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 4. Хэш-алгоритмы (4 Кбайт): число запросов в секунду и время
ответа
Примечания:
- В .NET Framework поддерживаются различные хэш-алгоритмы, такие
как MD5, SHA1, SHA256, SHA384 и SHA512. Единственное различие между
разными реализациями SHA - в размере генерируемого хэша. Для
тестирования были выбраны только алгоритмы SHA1 и SHA512.
- Было решено использовать System.Security.Cryptography,
предлагающего различные реализации SHA1 и MD5.
- В System.Security.Cryptography имеется только одна реализация
MD5 - MD5CryptoServiceProvider, заключающая CAPI в обертку.
- В настоящий момент алгоритмы SHA256, SHA384 и SHA512 не доступны
в CryptoAPI. Они реализованы непосредственно в управляемом коде. Эти
алгоритмы были добавлены только для поддержки новых требований AES к
генерации ключа, а не для обеспечения более стойких алгоритмов, чем
SHA1. В настоящее время принято считать, что алгоритм SHA1 хорошо
подходит для хэширования данных.
- Для алгоритмов SHA1 и SHA512 использовались управляемые
реализации SHA1Managed и SHA512Managed, доступные в
System.Security.Cryptography.
Как показано на рис. 4, производительность всех алгоритмов
практически одинакова, но у SHA512 она немного ниже. Размер хэша,
генерируемого алгоритмом MD5, равен 128 битам. Процесс вычисления в SHA
во многом смоделирован на основе MD5. Он генерирует 160-битовый хэш.
Больший размер хэша более надежен при атаках перебором. Алгоритм
SHA512 генерирует 512-битовый хэш, SHA1 – 160-битовый, MD5 –
128-битовый; поэтому SHA1 более надежен при атаках перебором, чем MD5.
При этом также подразумевается отсутствие слабых мест в алгоритмах.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 5. Хэш-алгоритмы (135 Кбайт): число запросов в секунду и
время ответа
При увеличении объема данных увеличилось различие в
производительности алгоритмов. При 5 параллельных пользователях
производительность у MD5 приблизительно на 33% выше, чем у SHA1. Хотя
методы атаки на MD5 пока неизвестны, теоретически существуют конфликты,
которые могут использоваться против него.
При увеличении объема данных производительность SHA512 снизилась. Она
приблизительно на 55% ниже, чем у SHA1.
Не следует забывать, что при увеличении размера хэша безопасность
увеличивается за счет снижения производительности, как упоминалось
ранее.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 6. Хэш-алгоритмы (1 Мбайт): число запросов в секунду и время
ответа
При дальнейшем увеличении объема данных различие в производительности
алгоритмов увеличилось еще значительнее.
Производительность MD5 приблизительно на 43% выше, чем у SHA1 при 5
параллельных пользователях (при другом числе пользователей этот алгоритм
быстрее примерно на 20%). SHA1 примерно на 72% быстрее, чем SHA512.
Алгоритмы с симметричным ключом
В тестируемом методе данные сначала были зашифрованы и затем
дешифрованы. Для анализа влияния размера данных на производительность в
тесте использовались данные размером 4 Кбайт, 100 Кбайт и 500 Кбайт.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 7. Алгоритмы с симметричным ключом (4 Кбайта): число запросов
в секунду и время ответа
Примечания
- В тесте использовались управляемые обертки для DES, 3DES и RC2,
доступные в System.Security.Cryptography, которые заключают в
обертку доступные в CryptoAPI неуправляемые реализации. К
нимотносятся соответственно DESCryptoServiceProvider,
TripleDESCryptoServiceProvider и RC2CryptoServiceProvider. В
System.Security.Cryptography доступна только одна чистая управляемая
реализация Rijndael, которая и использовалась при тестировании.
- Ниже приведены размеры ключа и блока, используемые алгоритмами
для шифрования и дешифрования данных:
Алгоритм |
Размер ключа
(в битах) |
Размер блока
(в битах) |
DES |
64 |
64 |
3DES |
192 |
64 |
RC2 |
128 |
64 |
Rijndael |
256 |
128 |
- В алгоритмах 3DES, RC2 и Rijndael поддерживаются также ключи
другой длины, однако в тестах данные шифровались и дешифровались с
максимальной поддерживаемой длиной ключа. Поскольку для ключа
большей длины требуется более длительная и сильная атака, и такой
ключ обеспечивает лучшую защиту, это позволяет измерить
производительность алгоритма с максимальной защитой.
- Ключ большей длины обеспечивает большую безопасность благодаря
уменьшению вероятности успешных атак по поиску ключа путем
увеличения числа возможных комбинаций ключа.
- Другие алгоритмы с ключом такой же длины (например, 128) не
всегда обладают одинаковой стойкостью.
При небольшом размере данных метод Rijndael, называемый также AES
(Advanced Encryption standard - Усовершенствованный стандарт
шифрования), является самым быстрым из всех методов. В нем используется
различная длина блока и ключа, которые можно выбрать из следующих
значений: 128, 192 или 256 бит. Кроме того, для генерации шифрованного
текста в нем может применяться различное число циклов, зависящее от
длины ключа и длины блока.
В алгоритме DES данные шифруются и дешифруются блоками размером 64
бита с помощью 64-битового ключа. Для генерации шифрованного текста
каждый блок данных итерируется 16 раз. Несмотря на большую
производительность по сравнению с 3DES и RC2, этот алгоритм уязвим при
атаке перебором из-за короткой длины ключа. Для современных, более
быстрых и мощных компьютеров этот алгоритм становится еще более уязвимым
и легко атакуемым.
Алгоритм 3DES (Triple DES - Тройной DES) был разработан для улучшения
защиты DES путем троекратного шифрования данных с помощью DES и трех
различных ключей (обратите внимание, что троекратное шифрование данных с
помощью одного ключа не имеет никаких преимуществ). Этот алгоритм
является просто другим режимом DES, но он в большой степени безопасен, и
поэтому его производительность ниже. Алгоритм использует 192-битовых
ключ, разделенный на три 64-битовых субключа. Эта процедура полностью
идентична процедуре DES, но повторяется три раза и поэтому намного более
безопасна. Данные шифруются первым субключом, дешифруются вторым
субключом и снова шифруются третьим субключом.
При маленьком размере шифруемых данных алгоритм RC2 оказался самым
медленным методом. Для построения зависящей от ключа таблицы в нем
выполняется фронтальное вычисление, издержки на которое довольно высоки
по сравнению с издержками на шифрование данных небольшого размера. RC2 –
это шифр с симметричным блоком и переменной длиной ключа, разработанный
как альтернатива DES.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 8. Алгоритмы с симметричным ключом (100 Кбайт): число
запросов в секунду и время ответа
При увеличении размера шифруемых и дешифруемых данных ситуация,
наблюдавшаяся в предыдущем тесте, полностью изменилась. Самым быстрым
является алгоритм DES, за ним следует RC2, который примерно на 20%
быстрее алгоритма 3DES. Обратите внимание, что издержки на вычисление в
RC2 для построения зависящей от ключа таблицы, упомянутой в предыдущем
тесте, амортизируются при увеличении размера данных. Алгоритм Rijndael
является самым медленным в этом тесте - он на 25% медленнее, чем 3DES.
Обратите внимание, что для шифрования Rijndael используется 256-битовый
ключ, определяющий его большую стойкость по сравнению с другими методами
(хотя на этот алгоритм оказывалось некоторое давление по причине
возможных атак, которые могут быть успешнее, чем атака перебором) и,
соответственно, самую низкую производительность. Аналогично для 3DES
использовался 192-битовый ключ, более длинный, чем ключи для шифрования
DES и RC2.
Следует снова отметить, что использование ключей одинаковой длины не
всегда подразумевает одинаковую стойкость различных алгоритмов.
Различные алгоритмы обладают различными характеристиками и,
следовательно, не могут обеспечить одинаковую стойкость.
Как уже упоминалось в статье, всегда необходимо выбирать между
безопасностью и производительностью. Прежде чем выбрать наиболее
подходящий алгоритм для защиты данных необходимо осознать значение
данных, оценить стоимость развертывания и выбрать между применимостью и
производительностью. Если стоимость данных, которые требуется защитить,
высока, следует выбрать меньшую производительность и большую
безопасность. В противном случае можно сэкономить средства, используя
менее безопасный алгоритм.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 9. Алгоритмы с симметричным ключом (500 Кбайт): число
запросов в секунду и время ответа
При увеличении размера шифруемых и дешифруемых данных в этом тесте
наблюдается та же тенденция, хотя разница между производительностью
различных алгоритмов, за исключением 3DES и Rijndael, увеличилась.
Алгоритмы с асимметричным ключом
Шифрование с помощью алгоритмов с асимметричным ключом выполняется
очень медленно, особенно при большом размере данных; следовательно, они
не используются для шифрования больших объемов данных. Для шифрования
больших объемов данных следует использовать алгоритмы с симметричным
ключом. Асимметричные алгоритмы могут использоваться для обмена ключами.
Как правило, используются два асимметричных алгоритма - RSA и DSA.
Алгоритм RSA может использоваться как для шифрования, так и для
генерации подписи, тогда как алгоритм DSA может использоваться только
для генерации подписи. Сравнение RSA и DSA было основано на скорости
генерации и проверки цифровой подписи.
Создание подписи
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 10. Создание подписи (100 Кбайт): число запросов в секунду и
время ответа
Примечания:
- В тесте использовались RSACryptoServiceProvider и
DSACryptoServiceProvider, доступные в System.Security.Cryptography,
которые являются соответственно управляемыми обертками неуправляемых
реализаций RSA и DSA, предоставляемых CryptoAPI.
- В RSA используется 1024-битовый ключ.
- В DSA используется 512-битовый ключ.
Как показано на рис. 10, при генерации цифровой подписи
производительность DSA примерно на 29% выше, чем у RSA. В процессе
создания цифровой подписи с помощью RSA закрытый ключ используется
только для шифрования профиля сообщения. Зашифрованный метод становится
цифровой подписью.
Несмотря на схожесть с RSA, в алгоритме DSA профиль сообщения не
шифруется закрытым ключом и не дешифруется открытым ключом. Вместо этого
DSA использует специальные математические функции и генерирует цифровую
подпись из двух 160-битовых чисел, получаемых из профиля сообщения и
закрытого ключа.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 11. Создание подписи (500 Кбайт): число запросов в секунду и
время ответа
При увеличении размера данных алгоритм DSA по-прежнему быстрее, чем
алгоритм RSA.
Проверка подписи
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 12. Проверка подписи (100 Кбайт): число запросов в секунду и
время ответа
При проверке подписи были получены обратные результаты. Алгоритм RSA
быстрее, чем алгоритм DSA, приблизительно на 29%. Для проверки подписи в
RSA используется открытый ключ. При этом из полученных данных
генерируется новый профиль сообщения, затем первоначальный профиль
сообщения шифруется открытым ключом создателя, и дешифрованный профиль
сообщения сравнивается с новым. Если эти два профиля совпадают, проверка
целостности сообщения выполнена. Идентификация создателя также
подтверждается, поскольку открытым ключом можно дешифровать только
данные, зашифрованные соответствующим закрытым ключом.
Для проверки подписи в DSA также используется открытый ключ, однако
процесс проверки более сложен, чем в RSA.
|
Дополнительная информация по рисунку
Request / Second vs. User Load = число запросов в секунду к
числу пользователей
Data Size = размер данных
Response Time vs. User Load = время ответа к числу
пользователей |
Рис. 13. Проверка подписи (500 Кбайт): число запросов в секунду и
время ответа
При увеличении размера данных различия в производительности двух
алгоритмов стали незначительными.
Заключение
Как показали тесты, схемы аутентификации, алгоритмы хэширования и
методы шифрования характеризуются издержками различного размера, и,
следовательно, значительно отличающимися показателями
производительности. Кроме того, существенным фактором является размер
данных, передаваемых как алгоритмам хэширования, так и методам
шифрования.
При проектировании защищенной системы необходимо выбрать методы
реализации, основанные в первую очередь на снижении угрозы и во вторую
очередь на производительности. В частности, аутентификация Basic без SSL
может использоваться для повышения производительности, однако,
независимо от быстроты, эту аутентификацию не рекомендуется применять в
системах, уязвимых для атак.
В этой статье не рассматривалось общее влияние на производительность
аутентификации и защиты данных, которыми определяется структура
безопасности в реальной системе. Производительность защищенной системы
будет изменяться в зависимости от комбинации используемых схем.