- •7. Что такое электронная таблица?
- •Ввод и редактирование данных
- •Формат данных
- •Функции и формулы
- •Понятие формулы
- •Понятие функции
- •Мастер функций
- •[Править]Применение в серверных приложениях
- •[Править]Мультиплексирование
- •Методы и средства защиты от несанкционированного доступа
- •Криптография и шифрование Что такое шифрование
- •Основные термины и определения криптографии
- •Открытые ключи
- •Проблемы использования открытых/закрытых ключей
- •Сертификат
- •[Править]Центры доверия
- •Создание отчётов
- •Изменение структуры отчёта
- •Создание таблиц в режиме конструктора
- •Формирование запросов на выборку
- •Параметрические запросы
- •Запросы на обновление
- •Редактирование запросов
- •Поля и записи
- •Порядковые типы
- •Целые типы
- •Символьные типы
- •Булевы типы
- •Перечислимые типы
- •Поддиапазонные типы
- •Действительные типы
- •[Править]Использование в форматах файлов
- •3.1. Выполнение задания
- •6.2 Построитель выражений
- •Создание кнопочной формы с помощью диспетчера кнопочных форм
- •Примечания
- •Групповые функции в операторе select:
- •Раторы сравнения
- •Виды отношений
- •Отношения в App Engine Один-ко-многим
- •Один-к-одному
- •Многие-ко-многим
- •2. Свойства алгоритмов.
- •Вывод «Основные свойства алгоритмов»:
- •3. Способы описания алгоритмов.
- •Тестирование программного обеспечения
- •[Править]Уровни тестирования
- •[Править]Статическое и динамическое тестирование
- •[Править]Регрессионное тестирование
- •[Править]Тестовые скрипты
- •[Править]Тестирование «белого ящика» и «чёрного ящика»
- •[Править]Покрытие кода
- •Обеспечение целостности базы данных
- •Электронная почта (e-mail)
- •Группы новостей
- •Службы мгновенных сообщений
- •Основы tcp/ip
- •Краткое описание протоколов семейства tcp/ip с расшифровкой аббревиатур
- •Архитектура tcp/ip
- •Уровни сетей и протоколы tcp/ip
- •Краткое заключение
Проблемы использования открытых/закрытых ключей
Как мы уже сказали раньше, использование несимметричных алгоритмов шифрования и криптохешей позволяет защитить (казалось бы) передаваемую информацию от подслушивания и изменения.
Однако, условием этого является обмен открытыми ключами между сторонами (участвующими в обмене информацией). А как пользователь С сможет проверить, что полученный ключ - это ключ D, а не злобного E (который перехватил оригинальное письмо D, а вместо него отправил письмо со своим открытым ключом, и получая все сообщения от D, он их расшифровавает/меняет, шифрует/подписывает своим ключом и отправляет дальше к C)? Каким образом мы можем узнать, что данный ключ принадлежит данному пользователю? Опять шифроблокнотики, личные встречи и бумаги с печатами? (Кстати, это не самый сложный метод: люди обмениваются нотариально заверенными бумагами с распечатанными открытыми ключами - и никакой "злобный Е" не сможет притвориться одним из них. Главная проблема подобного метода - плохое масштабирование. Если 300 человек решат так сделать со всеми остальными 299 человеками, то потребуется 300*299=89700 нотариально заверенных распечаток откртых ключей).
Проблема получения правильного открытого ключа - это первая проблема. Вторая проблема: предположим, что закрытый ключ пользователя украли. Как ему оповестить всех людей, с кем у него защищённый обмен информацией о краже? А об утрате? Если он это сделает с помощью незащищённых каналов связи, то и злоумышленник может заявить (якобы от лица пользователя): "ключ украли, компьютер сломали, не слушайте больше писем с этим ключом". Т.е. вся защита держится на личном доверии, каких-то других каналах связи? Или вообще ни на чём не держится?
Главная проблема, которую можно выделить из этих примеров: пользователь не имеет возможности проверить, что ключ Aпринадлежит пользователю A. Любой другой пользователь (злоумышленник) может сделать то же самое, что пользователь A, и назвать себя пользователем A.
Как решить эту задачу?
Главная "правда" PKI состоит в том, что подобная задача не может быть решена только средствами криптографии. Необходима некая договорённость между использующими ключи людьми о том, как именно доказывать связь ключа и пользователя. Решение этого вопроса - и есть суть PKI. Дополнительно же, помимо "главной задачи" решается ещё несколько очень важных задач, позволяющих обеспечить множество видов дополнительного криптографического сервиса.
Сертификат
Определение сертификата очень простое:
сертификат - подписанная доверенной стороной связь между идентичностью и её открытым ключом (-ами).
На самом деле в этом определении очень много того, о чём мы пока не говорили. Оставим в стороне "подписанная доверенной стороной" (об этом позже). Сфокусируемся на "связь между идентичностью и открытым ключом".
Фактически, сертификат - это ключ, к которому дописали, чей это ключ. Мы открываем сертификат и видим, что он принадлежит Васе Пупкину. Значит, подписи сообщения от Васи Пупкина следует проверять указанным открытым ключом, и шифровать письма Васе Пупкину надо так же этим открытым ключом.
Однако, просто указание на имя (емейл) и открытый ключ не достаточно - такая конструкция ничем не отличается от предыдущей (электронное письмо "мой открытый ключ XXX-XXX-XXX-XXX, С уважением, Вася Пупкин"). Нужны какие-то объективные доказательства того, что ключ Васи Пупкина - это таки ключ Васи Пупкина. И Вася Пупкин - это именно ТОТ Вася, о котором мы думаем.
В принципе, если подумать, то если связь "вася пупкин + открытый ключ" подпишет кто-то из тех, чей ключ мы знаем (уже), то это добавит нам уверенности. Но только в том случае, если этот "кто-то" нам знаком и мы ему доверяем. А если нет?
Было бы неплохо иметь аналог нотариальной конторы, которая бы могла заверять связь идентичности и ключа. Нотариусу мы доверяем, значит, мы можем быть уверены, что ключ принадлежит именно тому, чья идентичность указана в сертификате.