Создание защищенного приложения для ведения учета продаж и закупок, ориентированного на малый бизнес
Проектирование модели базы данных в соответствии с предметной областью "Торговля". Разработка архитектуры системы безопасности приложения по ведению базы данных. Реализация приложения, обеспечивающего учет продаж и закупок предприятия. Способы его защиты.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 05.02.2017 |
Размер файла | 2,5 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
РЕФЕРАТ
Выпускная квалификационная
АРХИТЕКТУРА БЕЗОПАСНОСТИ, БАЗА ДАННЫХ, ЗАЩИЩЕННОЕ СОЕДИНЕНИЕ, ШИФРОВАНИЕ, ХЭШИРОВАНИЕ ДАННЫХ, ВЕДЕНИЕ ТОРГОВОГО УЧЕТА.
Целью работы является создание защищенного приложения для ведения учета продаж и закупок, ориентированное на малый бизнес.
Объектом исследования является механизм ведения торгового учета, а также архитектура безопасности приложения.
В процессе выполнения ВКР была спроектирована модель базы данных в соответствии с предметной областью «Торговля», разработана архитектура системы безопасности, создана диаграмма классов приложения, проанализировано взаимодействие методов защиты с работой приложения, разработано приложение по ведению базы данных, внедрены методы защиты приложения.
Созданная программа позволяет осуществлять работу для выбранных пользователей с учетом их спецификации - товаровед задает наименование товаров, поставщиков, складов, производителей и так далее, а также ведает закупками. Продавец формирует продажи по имеющейся номенклатуре. Директор просматривает отчеты с информацией о доходах и расходах предприятия. Администратор может корректировать все таблицы, а также исполнять административные функции, например, создавать новых пользователей.
- СОДЕРЖАНИЕ
- Определения, обозначения и сокращения
Введение
- 1. Моделирование предметной области
1.1 Анализ предметной области
1.2 Проектирование базы данных
2. Проектирование архитектуры системы безопасности приложения базы данных
2.1 Архитектура системы безопасности
2.2 Система контроля доступа с использованием ролевой политики
безопасности
2.3 Защищенное соединение
2.4 Защита от Sql-инъекций
2.5 Хэширование паролей
2.6 Обеспечение целостности данных
2.7 Шифрование содержимого базы данных
2.7.1 Многочлены с коэффициентами, принадлежащими полюGF(28)
2.8 Защита от дизассемблирования
2.9 Резервное копирование
3. Программная реализация и тестирование приложения
Заключение
Список использованных источников
Приложения
ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ
БД |
база данных |
|
СУБД |
система управления базами данных |
|
РРД |
ролевое разграничение доступа |
|
ИНН |
идентификационный номер налогоплательщика |
|
ИП |
индивидуальный предприниматель |
|
КПП |
код причины постановки |
|
MD5 |
message digest 5-алгоритм хэширования |
|
SHA-1 |
secure hash algorithm 1-алгоритмхэширования |
|
MAC |
message authentication code- кодпроверкисообщения |
|
HMAC |
hashed message authentication code - хэшированныйкодпроверкисообщения |
|
SSL |
secure sockets layer-криптографический протоколдля защищенного обмена данными |
|
TLC |
transportlayersecurity-криптографические протокол, обеспечивающие защищённую передачу данных |
|
DES |
dataencryptionstandard -алгоритм для симметричного шифрования |
|
3DES |
triple dataencryptionstandard-симметричный блочный шифр, на основе алгоритмаDES |
|
RC2 |
rivest'scipher2 -алгоритм блочного шифрования |
|
AES |
advancedencryptionstandard-симметричный алгоритмблочного шифрования |
ВВЕДЕНИЕ
На сегодняшний день предпринимательство может считать одной из самых распространённых профессий. Современные условия, в том числе Интернет, делают процесс предпринимательства доступным для широчайшей аудитории, в том числе для тех категорий людей, которые ещё 10 лет назад едва ли смогли бы начать своё дело: школьники, студенты, пенсионеры.
Важным аспектом в ведении предпринимательской деятельности является торговый учет. Именно благодаря ему мы можем оценить рентабельность предприятия, на основании продаж спрогнозировать дальнейшие заказы, на основании выручки и чистой прибыли сформировать ценовую политику. На основании средств, затраченных на рекламу и клиентов, пришедших с этой рекламы, строить свои выводы об эффективности маркетинговой компании и так далее. Таким образом, «цифры»- важнейший показатель в предпринимательской деятельности[2,5].
Возникает вопрос: «Каким образом лучше всего вести торговый учет?».
Логичным ответом на него является использование специализированных программ, например 1С. И действительно, данное решение подойдет очень многим предпринимателям, однако не всем. Дело в том, что система 1С является универсальной и многофункциональной - она ориентирована на любые виды бизнеса и торговый учет у нее может вестись в разрезе сотен измерений, что делает её достаточно неудобной для маленьких компаний, которым требуется малая часть от функционала, который предоставляет 1С. Другим достаточно важным недостатком является стоимость программы и постоянная плата за услуги мастера, который будет обновлять её.
Все это в совокупности делает подобную систему неподходящей для начинающего предпринимателя, не имеющего большого количества продаж и не работающего с большим количество видов документов. Другим ответом на поставленный вопрос является электронные таблицы, например, MSExcel. Данное приложение позволяет нам записывать суммы продаж и закупок и на основании их формировать представление о рентабельности малого предприятия. Однако на этом функционал Excel можно считать завершенным. Поэтому проведение анализа затруднено. В приложении MSExcel нет специальных функций для ведения учета по товарам, поставщикам, производителям, складам и датам. Таким образом, MSExcel также можно считать малопригодным для ведения торгового учета [6].
Остается третий вариант- использование бесплатной специализированной программы, не имеющей громоздкого функционала, но в то же время обладающей минимальным набором нужных опций. Разработка именно такой программы является целью ВКР.
Цель работы-создание защищенного приложения «Система ведения учета продаж и закупок» для малого бизнеса.
Поставленная цель ВКР определяет следующие задачи:
1. Проектирование модели базы данных в соответствии с предметной областью «Торговля».
2. Разработка архитектуры системы безопасности приложения по ведению базы данных.
3. Реализация приложения, обеспечивающего учет продаж и закупок предприятия, и реализация способов его защиты.
4. Тестирование приложения.
В результате выполняемой работы предполагается получение готового программного продукта.
1. МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Анализ предметной области
Ведение бизнеса может осуществляться несколькими способами: продажей товара, предоставлением разовых услуг, предоставлением сервиса с постоянными платежами, а также комбинациями данных способов.
Поскольку наше приложение ориентированно на учет продаж и закупок, будем рассматривать сферу бизнеса, связанную исключительно с продажей товара. Продажа товара может быть оптовой, розничной и оптово-розничной. Ведение оптовой и оптово-розничной торговли в большинстве случаев относится к средним и крупным компаниям, так как для осуществления подобной деятельности необходимы развитая логистика, большие денежные средства для закупок, наличие крупных складов, взаимодействие с другими компаниями и так далее. Помимо продаж и закупок существует масса других факторов, которые необходимо учитывать: расхождения в заказе поставщику и присланной продукцией, порча товара в пути, контроль брака товара, возвраты от других оптовых покупателей, сроки доставки, проведение ревизий и так далее. Таким образом, очевидно, что в данной деятельности требуется сложная и многофункциональная программа ведения торгового учета, поэтому мы сосредоточимся исключительно на розничной торговли.
Ведение розничной торговли может рассматриваться как осуществление двух основных торговых операций -закупок и продаж товара. Каждая закупка и продажа должна характеризоваться товаром, участвующим в операции, а также его количеством.
В свою очередь товар также должен содержать в себе некую дополнительную информацию, характеризующую его: является товар весовым или штучным, в каких формах он продается (упаковки, штуки, коробки и так далее), какова цена данного товара, кто является его поставщиком и производителем, какова ставка НДС для данного товара, какой штрих-код у товара и так далее.
При этом отметим, что каждый товар имеет как минимум две цены: цену поставщика, по которой мы его закупаем и цену продажи. Именно разница этих двух показателей будет формировать нам выручку, что является основой любой предпринимательской деятельности.
Некоторые характеристики товара также могут содержать в себе дополнительную информацию, например, поставщик товара обязательно имеет телефон и юридический адрес, тоже самое можно сказать и о производителе. Подобная информация будет храниться в столбцах соответствующих таблиц.
Продажа товара может осуществляться как с розничной точки, таки через интернет. Соответственно во втором случае требуется наличие некого склада, на котором будет храниться товар. В первом случае в качестве склада может выступать как сама розничная точка, так и отдельное помещение, которое имеет свой собственный адрес.
Информация о закупках и продажах будут отображаться в базе данных в виде табличных строк (в отдельных таблицах для закупок и продаж) с соответствующими характеристиками каждой торговой операции (дата, количество проданной или купленной номенклатуры, цена номенклатуры и так далее).
Выделим предварительный набор сведений, которые должны храниться в базе данных для корректного ведения управления торговлей:
1) наименование номенклатуры;
2) единица измерения номенклатуры;
3) поставщик номенклатуры;
4) адрес поставщика (город, улица, номер дома, телефон);
5) ИНН и КПП производителя;
6) ставка НДС;
7) страна происхождения номенклатуры;
8) производитель номенклатуры;
9) адрес производителя (город, улица, номер дома, телефон);
10)штрих-код;
11) закупочная цена;
12) розничная цена;
13)операция продажи;
14)дата продажи;
15)количество проданной продукции;
16) сумма продажи;
17)операция закупки;
18) дата операции закупки;
19) количество закупленной продукции;
20)сумма закупки;
21) склад номенклатуры;
22) подразделения (магазины).
Дополнительно будем выделять такие сведения, как «Цена с учетом НДС» (для закупок и продаж).
В качестве модели представления данных будет использована модель «Сущность-Связь». Любая предметная область может быть представлена как множество сущностей, между которыми существуют связи.
Под предметной областью подразумевается абстрагированная часть реального мира в виде понятий, описанная словами.
Абстрагирование - это мыслительная операция выделения существенных свойств объекта путем отвлечения в процессе познания от несущественных свойств. Абстрагирование, иначе, - это упрощенное описание части реального мира в форме понятий.
Метод «Сущность-Связь» использует следующие понятия:
1) сущность- это понятие, данное объекту реального мира;
2)свойство сущности- это понятие, данное свойству объекта реального мира;
3) атрибут сущности - это имя свойства сущности;
4) ключ сущности- это один или несколько атрибутов сущности, значения которых не могут встречаться в двух различных экземплярах сущности;
5) экземпляр сущности- это понятие, поставленное в соответствии объекту из набора объектов реального мира, в котором у каждого объекта имеется набор одинаковых свойств, и значения наборов свойств не повторяются.
5. Связь- это понятие, данное взаимодействию объектов реального мира [4].
То число сущностей, между которыми установлена связь, называют степенью связи. Рассмотрение степеней особенно полезно для бинарных связей. Рассмотри те виды связи, которые мы будем использовать:
- один к одному (обозначается 1:1).Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью;
- один ко многим (обозначается1: n).В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью[7].
Из анализа предметной области мы можем выделить 7 основных сущностей:
1) номенклатура;
2) поставщики;
3) производители;
4) продажи;
5) склады;
6) подразделения;
7) закупки.
Также выделим 3 дополнительные сущности, относящихся к пользователям и их ролям:
1) пользователь;
2) роль;
3) связи роли и пользователя.
Представим сущности с их атрибутами и связями между ними в виде модели предметной области (рисунки 1-2). Поскольку мы будем разделять хранение данных, связанных с торговлей и данных, связанных с пользователями, ролями и паролями, будет создано две модели БД.
Рисунок 1 - Модель предметной области «Пользователи и роли»
Рисунок2 - Модель предметной области «Главная база данных»
Благодаря средствам программы WorkBench данные модели были преобразованы в базы данных в СУБД MySql[8].
1.2 Проектирование базы данных
Проектирование базы данных будем осуществлять в соответствии с реляционной моделью данных. Для этого, исходя из предварительной информации раздела 1.1, сформируем следующие отношения:
1) номенклатура;
2) поставщики;
3) производители;
4) продажи;
5) склады;
6) подразделения;
7) закупки.
Поскольку для торговой отчетности нам может понадобиться история по таким данным, как изменение цены товара со временем, мы выделим отношения «Цена товара». Аналогично в отдельное отношение мы выделим данные по товарам на складе.
Также мы имеем некоторые наборы фиксированных данных, такие, как ставки НДС и, для сохранения целостности БД, будет разумно создать отдельное отношение, которое будет хранить ставки.
Без использования отношения «ставки НДС» возможны ошибки при вводе с клавиатуры, что не позволит создавать корректную отчетность по продажам, поскольку ставка НДС непосредственно влияет на итоговую цену товара.
Общий список отношений следующий: номенклатура; ставки НДС; поставщики; производители; продажи; склады; цены; подразделения; закупки.
Для каждого отношения мы должны определить атрибуты, которые определять каждый кортеж в отношении. Атрибуты мы можем выделить из проведенного ранее анализа предметной области.
Полученные отношения запишем в виде таблиц (таблица 1-12).
Таблица 1 -Номенклатура
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Наименование |
Name |
Текстовый (varchar) |
|
Единица измерения |
EdinitsaIzmereniya |
Текстовый (varchar) |
|
Поставщик |
PostavshikiName |
Текстовый (varchar) |
|
Страна происхождения |
Country |
Текстовый (varchar) |
|
Производитель |
ProizvoditeliName |
Текстовый(varchar) |
|
Ставка НДС |
StavkaNDSRazmerStavki |
Числовой (int) |
|
Штрихкод |
Shtrihkod |
Текстовый (varchar) |
Таблица 2 - Поставщики
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Наименование |
Name |
Текстовый (varchar) |
|
ИНН |
INN |
Числовой (int) |
|
КПП |
KPP |
Числовой (int) |
|
Город |
City |
Текстовый (varchar) |
|
Улица |
Street |
Текстовый (varchar) |
|
Номер дома |
BuildingNumber |
Текстовый (varchar) |
|
Телефон |
Phone |
Текстовый (varchar) |
Таблица 3 - Производители
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Наименование |
Name |
Текстовый (varchar) |
|
ИНН |
INN |
Числовой (int) |
|
КПП |
KPP |
Числовой (int) |
|
Город |
City |
Текстовый (varchar) |
|
Улица |
Street |
Текстовый (varchar) |
|
Номер дома |
BuildingNumber |
Текстовый (varchar) |
|
Телефон |
Phone |
Текстовый (varchar) |
Таблица 4 - Продажи
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Код продажи |
idProdazi |
Числовой (int) |
|
Подразделение |
PodrazdelenieName |
Текстовый (varchar) |
|
Номенклатура |
NomenklaturaName |
Текстовый (varchar) |
|
Дата |
Date |
Дата (data) |
|
Количество |
Kolichestvo |
Числовой (int) |
|
Розничная цена |
RoznichnayaTsena |
Числовой (int) |
|
Цена с учетом НДС |
TsenaSnds |
Числовой (int) |
|
Сумма |
Summa |
Числовой (int) |
Таблица 5 - Закупки
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Код закупки |
idZakupki |
Числовой (int) |
|
Поставщик |
PostavshikiName |
Текстовый (varchar) |
|
Номенклатура |
NomenklaturaName |
Текстовый (varchar) |
|
Склад |
Skladi_Name |
Текстовый (varchar) |
|
Дата |
Date |
Дата (data) |
|
Количество |
Kolichestvo |
Числовой (int) |
|
Закупочная цена |
ZakupochnayaTsena |
Числовой (int) |
|
Сумма |
Summa |
Числовой (int) |
Таблица 6 - Цены
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Номенклатура |
NomenklaturaName |
Текстовый (varchar) |
|
Подразделение |
Текстовый (varchar) |
Текстовый (varchar) |
|
Дата |
Date |
Дата (data) |
|
Цена продажи |
TsenaProd |
Числовой (int) |
|
Цена закупки |
TseniZakup |
Числовой (int) |
|
Поставщик |
PostavshikiName |
Текстовый (varchar) |
Цена для различного подразделения (магазина) может отличаться, поэтому используем наименование подразделения.
Таблица 7 - Ставки НДС
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Размер ставки |
RazmerStavki |
Числовой (int) |
Таблица 8 - Склады
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Наименование |
Name |
Текстовый (varchar) |
|
Город |
City |
Текстовый (varchar) |
|
Улица |
Street |
Текстовый (varchar) |
|
Номер дома |
BuildingNumber |
Числовой (int) |
|
Телефон |
Phone |
Текстовый (varchar) |
Таблица 9 - Подразделения
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Наименование |
Name |
Текстовый (varchar) |
|
Город |
City |
Текстовый (varchar) |
|
Улица |
Street |
Текстовый (varchar) |
|
Номер дома |
BuildingNumber |
Текстовый (varchar) |
|
Телефон |
Phone |
Текстовый (varchar) |
Помимо объектов для ведения учета торговой деятельности предприятия нам необходимо выделить отношения для регистрации новых пользователей и реализации политики управления доступом.
Для этих целей необходимо выделить следующие сведения:
1) пароль;
2) логин;
3) роль.
Отношения, которые будут содержать вышеприведенные наборы данных, следующие:
1) пользователи; роли.
Соответственно, отношение «Пользователи» содержит в себе информацию о логине и пароле, а отношение «Роли» информацию о роли данного пользователя. Однако, поскольку связь между двумя отношениями имеет тип «Многие ко многим»: один пользователей может иметь несколько ролей, и в то же время одна роль может распространяться на несколько пользователей, то дополнительно у нас будет отношение связи между пользователями и ролями. Данное отношение так и будет называться: «Связь роли и пользователя».
Таблица 10 - Пользователи
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Имя пользователя |
Name |
Текстовый (varchar) |
|
Пароль |
Password |
Текстовый (varchar) |
Таблица 11 - Роли
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Наименование |
Name |
Текстовый (varchar) |
Таблица 12 -Связь роли и пользователя
Имя поля в схеме данных |
Имя поля в компьютерной БД |
Тип поля |
|
Наименование роли |
Roles_Name |
Текстовый (varchar) |
|
Имя пользователя |
Users_Name |
Текстовый (varchar) |
|
Пароль |
Users_Password |
Текстовый (varchar) |
|
Доп. проверка |
DopProverka |
Текстовый (varchar) |
Создавая базу данных, мы будем использовать реляционную модель данных. Эта модель представляет собой набор отношений: отношений со сведениями о предметной области «Торговля» и отношений, обеспечивающих связь между отношениями.
При табличной организации данныхcтроки и столбцы могут быть просмотрены в любом порядке, поэтому высока гибкость выбора любого подмножества элементов в строках и столбцах.
Физическая реализация таблицы в базе данных представляет собой строки, которые называют записями, и столбцы, которые называют полями. На пересечении строки столбцов находятся ячейки с данными, то есть конкретные значения атрибутов.
Таблица в реляционной базе данных характеризуется следующим:
1) каждый столбец имеет уникальное имя;
2) порядок строк в таблице не определён;
3) в таблице нет одинаковых строк;
4) количество строк в таблице теоретически не ограниченно;
5) все строки таблицы имеют одинаковую структуру (тип данных в ячейке, количество ячеек)[1,3].
база архитектура безопасность закупка
2. ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ СИСТЕМЫ БЕЗОПАСНОСТИ ПРИЛОЖЕНИЯ БАЗЫ ДАННЫХ
Проектирование архитектуры системы безопасности будем осуществлять с учетом:
1. обеспечение целостности данных;
2. разграничение прав доступа;
3. хэширование паролей;
4. шифрование содержимого БД;
5. защита от SQL-инъекций;
6. защищенное соединение SSL;
7. резервное копирование;
8. защита от дизассемблирования.
2.1 Архитектура безопасности
Каждый элемент системы безопасности, за исключением защиты от дизассемблирования и резервного копирования, взаимодействует между собой. Данные взаимодействия происходят в соответствии с представленной на рисунке 3 архитектурой системы безопасности.
Рисунок 3-Модель системы безопасности
Как видно из модели, при запуске приложения у нас происходит установка защищенного соединения по протоколу SSL. Далее, при вводе логина и пароля в окне приложения и нажатию кнопки «Вход», происходит аутентификация пользователя. Сначала введенные данные(логин и пароль) проходят обработку защиты от SQL-инъекций. Далее происходит проверка логина, вычисление хэша пароля и его проверка. При создании новых пользователей вместо пароля пользователя в базу данных заноситься только их хэш. Затем для пользователя происходит определение его роли. Каждый пользователь, в соответствии с его ролью, получает доступ к интерфейсу. При внесении информации в базу данных она проходит проверку на целостность, после чего зашифровывается и через защищенное соединение по протоколу SSLпомещается в БД на сервер.
Таким образом, мы достигаем цели реализации необходимой степени защиты информации.
Поскольку база данных создана СУБД MySql, мы используем клиент-серверное взаимодействие для работы с данными (рисунок 4).
Рисунок 4- Схема клиент-серверного взаимодействия
Как видно из рисунка, запрос пользователя отправляется на сервер СУБД, где происходит его обработка, выбираются запрашиваемые данные, которые после отправляются пользователю для его дальнейшей работы.
2.2 Система контроля доступа с использованием ролевой политики безопасности
Контроль доступа гарантирует нам, что каждый пользователь будет иметь доступ только к тем функциям, которые определены его профессией: продавец оформляет продажи, директор просматривает отчетность и так далее.
Для обеспечения подобного контроля доступа в приложении была реализована система контроля доступа с использованием ролевой политики безопасности.
Ролевое разграничение доступа является составляющей многих современных компьютерных систем. Задание ролей позволяет определить четкие и понятные для пользователей компьютерной системы правила разграничения доступа. При этом РРД наиболее эффективно используется в компьютерных системах, для пользователей которых четко определен круг их должностных полномочий и обязанностей.
Роль является совокупностью прав доступа на объекты компьютерной системы. РРД определяет порядок предоставления прав доступа пользователям в зависимости от сессии его работы и от имеющихся или отсутствующих у него ролей в каждый момент времени. Для анализа и изучения свойств систем РРД используются математические модели РРД. В основе всех математических моделей РРД лежит базовая модель РРД.
Данная модель определяет самые общие принципы построения моделей РРД.
Основными элементами базовой модели являются:
- множество пользователей();
- множество ролей ();
- множество прав доступа на объекты компьютерной системы ();
- множество сессий пользователей ();
- функция, определяющая для каждой роли множество прав доступа; при этом для каждого существует , такая что, ;
- функция, определяющая для каждого пользователя множество ролейна которые он может быть авторизирован;
- функция, определяющая для каждой сессии пользователя, от имени которого она активизирована;
- функция, определяющая для пользователей множество ролей, на которые он авторизирован в данной сессии, при этом в каждый момент времени для каждоговыполняется условие:
. (1)
Отметим, что могут существовать роли, на которые не авторизирован ни один пользователь.
В базовой модели РРД предполагается, что множества ,, и функции, не изменяются с течением времени. Однако в нашем случае администратор может создавать произвольное число пользователей, а также различное число ролей.
2.3 Защищенное соединение
С целью повышения безопасности работы приложения с базой данных, необходимым шагом является создание защищенного соединения между сервером и клиентом.
Cоздание подобного соединения будет проходить по протоколу SSL.
Криптографический протокол SSL был разработан в 1996 году компанией Netscape и вскоре стал наиболее популярным методом обеспечения защищенного обмена данными через Интернет. Этот протокол интегрирован в большинство браузеров и веб-серверов и использует ассиметричную криптосистему с открытым ключом, разработанную компанией RSA. Для осуществления SSL соединения необходимо, чтобы сервер имел инсталлированный цифровой сертификат. Цифровой сертификат - это файл, который уникальным образом идентифицирует пользователей и серверы. Протокол SSL обеспечивает защищенный обмен данных за счет двух следующих элементов [21-23]:
а) аутентификация;
б) шифрование.
SSL использует асимметричную криптографию для аутентификации ключей обмена, симметричный шифр для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений.
Протокол SSL предоставляет «безопасный канал», который имеет три основных свойства [24]:
1) канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа;
2) канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, а клиентская делает это опционально;
3) канал надежен. Транспортировка сообщений включает в себя проверку целостности.
Работу протокол SSL можно разделить на два уровня.
Первый уровень представляет слой протокола подтверждения подключения (HandshakeProtocolLayer). Он состоит из трех подпротоколов: протокол подтверждения подключения (HandshakeProtocol), протокол изменения параметров шифра (ChangeCipherSpecProtocol) и предупредительный протокол (Alertprotocol).
Второй уровень представляет слой протокола записи. На рисунке 5 схематично изображены уровни слоев SSL.
Рисунок 5 -уровни слоев SSL
Уровень подтверждения подключения состоит из трех подпротоколов:
а) подтверждение подключения. Этот подпротокол используется для согласования данных сессии между клиентом и сервером. В данные сессии входят:
1) идентификационный номер сессии; 2) сертификаты обеих сторон; 3) параметры алгоритма шифрования, который будет использован; 4) алгоритм сжатия информации, который будет использоваться; 5) «общий секрет», применён для создания ключей;
6) открытый ключ;
б) изменения параметров шифрования. Этот подпротокол используется для изменения данных ключа (keyingmaterial), который используется для шифрования данных между клиентом и сервером. Данные ключа - это информация, которая используется для создания ключей шифрования. Подпротокол изменения параметров шифрования состоит из одного единственного сообщения. В этом сообщении сервер говорит, что отправитель хочет изменить набор ключей. Дальше, ключ вычисляется из информации, которой обменялись стороны на уровне подпротокола подтверждения подключения;
в) предупреждение. Предупредительное сообщение показывает сторонам изменение статуса или о возможной ошибке. Существует множество предупредительных сообщений, которые извещают стороны, как при нормальном функционировании, так и при возникновении ошибок. Как правило, предупреждение отсылаются тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
Подпротокол подтверждения подключения обеспечивает реализацию многих функций безопасности. Он производит цепочку обмена данными, что в свою очередь начинает проверку подлинности сторон и согласовывает шифрование, алгоритмы хэширования и сжатия.
Установление подлинности участников. Для определения подлинности участников обмена данных, протокол подтверждения подключения использует сертификат стандарта Х.509. Это помогает подтвердить подлинность второй стороны, которая владеет сертификатом и секретным ключом.
Сертификат - это цифровой способ идентификации, который выпускает центр сертификации. В сертификате содержится идентификационная информация, период действия, публичный ключ, серийный номер, и цифровые подписи эмитента.
Сертификационный центр - это третья сторона, которой по умолчанию доверяют обе стороны. При попытке установить подключение в режиме SSL сессии, сертификационный центр проверяет инициатора (обычно в этой роли выступает пользователь, компьютер клиента), а затем выдает ему сертификат. Если необходимо, сертификационный центр обновляет или конфискует сертификаты. Проверка подлинности проходит по схеме:
1) клиенту предоставлен сертификат сервера; компьютер клиента пытается сопоставить эмитента сертификата сервера со списком доверительных сертификационных центров;
2) если эмитент сертификата - доверительный сертификационный центр, то клиент связывается и этим центром и проверяет, является ли сертификат настоящим, а не подделанным;
3) после проверки сертификата у сертификационного центра, клиент принимает сертификат как свидетельство подлинности сервера.
Шифрование данных. Существует два основных способа шифрования данных: симметричный ключ (еще называется «общий секретный ключ») и ассиметричный ключ (второе название «открытый ключ» или «схема открытый-секретный ключ»). Протокол SSL использует как симметричные, так и ассиметричные ключи для шифрования данных [21].
SSL-ключ- это зашифрованные данные, которые используются для определения схемы шифрования данных во время сессии. Чем длиннее ключ, тем труднее его взломать. Как правило, алгоритмы ассиметричных ключей более стойкие, их практически невозможно взломать.
Симметричный ключ. При шифровании симметричным ключом используется один и тот же ключ для шифрования данных. Если две стороны хотят обмениваться зашифрованными сообщениями в безопасном режиме, то обе стороны должны иметь одинаковые симметричные ключи.
Шифрование симметричным ключом обычно используется для шифрования большого объема данных, так как это процесс проходит быстрее, чем при ассиметричном шифровании. Обычно используются алгоритмы DES, 3DES, RC2, и AES.
Ассиметричный ключ. Шифрование с применением ассиметричного (открытого) ключа использует пару ключей, которые оба были получены, пройдя целый комплекс математических вычислений. Один из ключей используется в качестве открытого, как правило, сертификационный центр публикует открытый ключ в самом сертификате владельца. Секретный ключ держится в тайне и никогда никому не открывается.
Эти ключи работают в паре: один ключ используется для запуска противоположных функций второго ключа. Так, если открытый ключ используется чтоб шифровать данные, то расшифровать их можно только секретным ключом. Если данные шифруются секретным ключом, то открытый ключ должен это расшифровывать. Такая взаимосвязь позволяет, используя схему шифрования открытым ключом, делать две важные вещи.
Во-первых, любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, у которого есть секретный ключ.
Во-вторых, если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ.
Именно это является основой для цифровых подписей. Самый распространенный алгоритм, который используется при шифровании с ассиметричными ключами - RSA (назван в честь разработчиков Rivest, Shamir, Adleman).
Протокол SSL использует шифрование с открытым ключом для того, чтоб подтвердить клиенту подлинность сервера, и наоборот. Шифрование открытым ключом также используется для определения ключа сессии. Ключ сессии используется симметричными алгоритмами для шифровки большого объема данных.
Это объединяет ассиметричное шифрование (для проверки подлинности) и быстрое симметричное шифрование объемных данных(что не требует больших вычислительных ресурсов и больших затрат времени).
Хэширование. Во время подтверждения подключения согласовывается также и хэш-алгоритм. Хэш-функция - это односторонняя математическая функция, которая принимает на входе сообщение произвольной длины и вычисляет из него строку фиксированной длины. Хэш-значение играет роль идентификационной отметки, «отпечаток сообщения». Как и отпечатки пальцев уникальны для каждого человека, хэш-значения тоже уникальны. Кроме того, как отпечатки пальцев значительно меньше, чем сам человек, так и хэш-значение намного меньше оригинального сообщения.
Хэширование используется для обеспечения целостности передачи данных. Самыми популярными хэш-алгоритмами являются MD5 и SHA-1. MD5 создает 128 битноехэш-значение, а SHA-1 создает 160 битное хэш-значение. Есть также новые, более устойчивые алгоритмы хэширования: Whirlpool, Haval, Tiger [25].
Результатом работы хэш-алгоритма выступает значение, которое используется для проверки целостности переданных данных. Это значение создается с использованием либо MAC либо HMAC.
MACиспользует отображающую функцию и предоставляет данные в виде значений фиксированного размера, а затем хэширует само сообщение. MAC гарантирует, что данные не были изменены во время передачи. Разница между MAC и цифровой подписью состоит в том, что цифровая подпись это также способ подтверждения подлинности. Протокол SSL использует MAC.
HMAC похож на MAC, но при этом используется хэш-алгоритм вместе с общим секретным ключом. Общий секретный ключ прикрепляется к данным, которые хэшируются.
Это позволяет сделать хэширование более безопасным, так как обе стороны должны иметь одинаковые секретные ключи для подтверждения подлинности данных. HMAC используется только протоколом TLC.
Уровень записи. Протокол на уровне слоя записи получает зашифрованные данные от программы-клиента и передает его на транспортный слой. Протокол записи берет данные, разбивает на блоки размером, который подходит криптографическому алгоритму, использует MAC (или HMAC) и потом шифрует (расшифровывает) данные. При этом используется информация, которая была согласованна во время протокола подтверждения данных. В некоторых случая на этом уровне проходит сжатие (распаковка) данных.
Использование протоколаSSL встроено в Mysql и необходимо только выполнить ряд действий для его активации. В частности, необходимо скачать библиотеку OpenSSL и сгенерировать файлы ключей и сертификатов, а далее прописать в терминале Mysql.
2.4 Защита от Sql-инъекций
Внедрение SQL-кода - один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.
Внедрение SQL, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных(например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и (или) записи локальных файлов и выполнения произвольных команд на атакуемом сервере [18,19].
Атака типа внедрения SQL может быть возможна из-за некорректной обработки входных данных, используемых в SQL-запросах.
С целью предотвращения данных атак в приложении создан класс, обеспечивающий обработку вводимых данных при авторизации (рисунок 6).
Защита от SQL-инъекций |
|
mydb: QSqlDatabase qry: QSqlQuery |
|
make_qry(Qstring,Qstring,Qstring) |
Рисунок 6 - Диаграмма класса защиты от SQL-инъекций
В частности, вместо подстановки переменных в SQL-запрос используются плэйсхолдеры, то есть данные попадают в запрос не напрямую, а через некоего представителя, подстановочное выражение [20]. Данная подстановка осуществляется в функции «make_qry(Qstring,Qstring,Qstring)», которая возвращает роль пользователя. Переменные «mydb»и «qry» используются для установки соединения с базой данных и осуществления запроса к базе данных.
2.5 Хэширование паролей
С точки зрения безопасности хранение паролей в явном виде в базе данных не допустимо. Один из способов защиты паролей - это их хэширование.
При аутентификации пользователя вычисляется хэш введенного пароля и полученное значение сравнивается с тем, что хранится в базе данных [12].
При написании программного кода мы будем использовать хэш-функциюMD5.Представим алгоритм данной функции [13]:
1) на вход алгоритма поступает входной поток данных, хеш которого необходимо найти. Длина сообщения может быть любой (в том числе нулевой). В конец потока дописывают единичный байт 0х80, а затем дописывают нулевые биты, до тех пор, пока длина сообщения не будет сравнима с 448 по модулю 512;
2) в конец сообщения дописывают 64-битное представление длины данных (количество бит в сообщении) до выравнивания. Сначала записывают младшие 4 байта, затем старшие. Если длина превосходит , то дописывают только младшие биты (эквивалентно взятию по модулю. После этого длина сообщения станет кратной 512. Вычисления будут основываться на представлении этого потока данных в виде массива слов по 512 бит;
3) для вычислений инициализируются 4 переменных размером по 32 бита и задаются начальные значения шестнадцатеричными числами (рисунок 6).
Рисунок7 - Инициализация переменных
В этих переменных будут храниться результаты промежуточных вычислений.
Происходитопределение4 вспомогательных логических функций, которые преобразуют входные 32-битные слова, в 32-битные выходные (рисунок 7).
Рисунок8 - Вспомогательные логические функции
Также на этом шаге реализуется так называемый «белый шум» - усиление алгоритма, состоящее из 64 элементного массива, содержащего псевдослучайные числа, зависимые от синуса числа i:
(2)
Каждый 512-битный блок проходит 4 этапа вычислений по 16 раундов (рисунок 8). Для этого блок представляется в виде массива из 16 слов по 32 бита. Все раунды однотипны и имеют вид:[abcd k s i], определяемый как
,(3)
где , ,, - регистры;
F(B,C,D)- одна из логических функций; X [k]-k-й элемент 16-битного блока; T [i]-i-й элемент таблицы «белого шума»;
s-операция циклического сдвига на s позиций влево.
Число s задается отдельно для каждого раунда.
Этапы вычисления представлены на рисунке 8.
Рисунок9 - Четыре основных этапов вычисления алгоритма
Далее суммируем с результатом предыдущего цикла:
,,,. (4)
После окончания цикла необходимо проверить, есть ли ещё блоки для вычислений. Если да, то переходим к следующему элементу массива и повторяем цикл.
Результат вычислений находится в буфере , это и есть хэш. Если выводить побайтово, начиная с младшего байта и закончив старшим байтом , то мы получим MD5-хэш.
Для большей безопасности мы будем находить и сравнивать хэши не только паролей, но также и 1 и 3 символов из пароля. Таким образом, на основании одного пароля, будет происходить двойная проверка.
2.6 Обеспечение целостности данных
Целостность базы данных -это соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности. Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и так далее.
Обеспечение целостности данных было заложено ещё в создании модели базы данных при задании типов полей и использовании внешних ключей. Таким образом, пользователь не сможет в качестве наименования поставщика записать число и не сможет, создавая номенклатуру указывать поставщика, которого нет в базе данных.
Реализация приведенного ограничения не гарантирует нам полное соблюдение целостности данных. Например, на предприятии имеется два склада: склад № 1 и склад № 2. Пусть товар поступает на склад№ 1 и оформляется его продажа. Поскольку нет прямого соответствия между складами и товарами (нет таблицы с полями «Склад» и «Номенклатура»), может получиться так, что мы будем продавать товар с подразделения, которое связано со складом № 2, но не имеет отношения к складу №1.
Если не создать дополнительные проверки, то мы будем получать отрицательные остатки по складу № 2, в то время как на складе № 1 будет лежать товар. Данная ситуация некорректна, и мы обязаны включить дополнительные проверки на целостность, но уже реализованные в приложении.
2.7 Шифрование содержимого базы данных
Обязательным шагом в защите базы данных является шифрование её содержимого, ведь в случае успешного взлома и отсутствия шифрования злоумышленник получит сразу всю информацию. Если информация зашифрована, то её злонамеренное использование невозможно.
В качестве алгоритма шифрования выбран алгоритмAES. На текущий момент этот алгоритм считается достаточно надежным, имеет приемлемую длину ключа и отсутствие метода простого взлома [14].
AES является стандартом, основанным на алгоритме Rijndael. Для AES длина блока входных данных (input) и длина блока с промежуточным результатом шифрования (State) постоянна и равна 128 бит, а длина шифроключа Kсоставляет 128, 192, или 256 бит. При этом, исходный алгоритм Rijndael допускает длину ключа и размер блока от 128 до 256 бит с шагом в 32 бита. Для обозначения выбранных длин input, Stateи K в32-битных словах используются обозначения: для input и State, для K соответствующих длин [15].
В начале шифрования input копируется в массив State по правилу:
,(5)
для и.
После этого к State применяется процедура AddRoundKey() и затем State проходит через процедуру трансформации (раунд) 10, 12, или 14 раз (в зависимости от длины ключа), при этом надо учесть, что последний раунд несколько отличается от предыдущих. В итоге, после завершения последнего раунда трансформации, State копируется в блок выходных данных (output) по правилу.
Отдельные трансформации SubBytes(), ShiftRows(), MixColumns()иAddRoundKey()обрабатываютState. Массив w содержит keyschedule.
В рассматриваемой версии алгоритма AES-128 ключ шифра состоит из 128 битов, поделенных на 16 байтов:k0, k1, k2, … k15и записывается в столбцы матрицы InputKey. Каждый столбец матрицы InputKey образует слово, то есть фактически ключ шифра - это четыре слова w0, w1, w2, w3, где w0= k0, k1, k2, k3,w1 = k4, k5, k6,k7и так далее (рисунок 9).
k0 |
k4 |
k8 |
k12 |
||||||||
k1 |
k5 |
k9 |
k13 |
||||||||
k2 |
k6 |
k10 |
k14 |
||||||||
k3 |
k7 |
k11 |
k15 |
||||||||
w0 |
w1 |
w2 |
w3 |
w4 |
w5 |
w6 |
w7 |
… |
w42 |
w43 |
Рисунок10- Формирование ключей раунда
Из этих слов с помощью специального алгоритма (о нем позже) образуется последовательность из 44 слов: w0, w1, w2, …, w43 (каждое слово по 32 бита).
На каждый раунд шифрования подаются по четыре слова этой последовательности. Они и будут играть роль раундового ключа. Схема преобразования данных показана на рисунке10.
Рисунок 11- Схема шифрования и дешифрования AES
Перед первым раундом выполняется операция AddRoundKey (суммирование по модулю 2 с начальным ключом шифра). Преобразования, выполненные в одном раунде, обозначают Round (State, RoundKey) где переменная State является матрицей, описывающей данные на входе раунда и на его выходе после шифрования; переменная RoundKey - матрица, содержащая раундовый ключ.
Раунд состоит из 4 различных преобразований (рисунок 11).
В данные преобразования входят:
1) побайтовая подстановка в S-боксе с фиксированной таблицей замен (SubBytes);
2) побайтовый сдвиг строк матрицы State на различное количество байт (ShiftRows);
3) перемешивание байт в столбцах (MixColumns);
4) сложение по модулю 2 с раундовым ключом (AddRoundKey).
Последний раунд несколько отличается от предыдущих тем, что не задействует функцию MixColumns [16,17].
Рисунок 12- Схема раундов шифрования и дешифрования AES
При дешифровании в каждом раунде выполняются обратные операции: InvShiftRows, InvSubBytes, AddRoundKey и InvMixColumns. Порядок выполнения операций при шифровании и дешифровании различен, причины чего будут ясны после детального рассмотрения каждого преобразования.
Поскольку алгоритм используетконечное поле Галуа GF(28), рассмотрим математические основы шифра AES. Для описания алгоритма используется конечное поле Галуа GF(28), построенное как расширение поля GF(28) {0,1} помодулю неприводимого многочлена. Элементами поляGF(28) являются многочлены вида:
. (7)
Степень многочленов меньше 8,а коэффициенты b7,b6,…,b0{0,1}. Операции в поле выполняются по модулю. Всего в поле GF(28) насчитывается 256многочленов.
Представление двоичного числаb7b6b5b4b3b2b1b0 в виде многочлена с коэффициентами b7,b6,…,b0позволяет интерпретировать байт как битовый многочлен в конечном поле GF(28):
.(8)
Например, байт 63 задает последовательность битов 01100011 и определяет конкретный элемент поля 01100011 .
Рассмотрим основные математические операции в поле GF(28):
1) сложение байт можно выполнить любым из трех способов:
1.1) представить байты битовыми многочленами и сложить их по обычному правилу суммирования многочленов с последующим приведением коэффициентов суммы по модулю 2 (операция XOR над коэффициентами);
1.2)суммировать по модулю 2 соответствующие биты в байтах;
1.3)сложить байты в шестнадцатеричной системе исчисления;
Например, следующие три записи эквивалентны:
- представление в виде многочленов:
; (9)
-битовое представление:
; (10)
- шестнадцатеричное представление:
{57} {83} {D4}; (11)
2) умножение байт выполняется с помощью представления их многочленами и перемножения по обычным алгебраическим правилам. Полученное произведение необходимо привести по модулю многочлена (результат приведения равен остатку от деления произведения на).
Перемножение многочленов в поле можно упростить, введя операцию умножения битового многочленана :
.(12)
Для любого ненулевого битового многочленав полеGF(28) существует многочлен обратный к нему по умножению, то есть
). (13)
Для нахождения обратного элемента используют расширенный алгоритм Эвклида.
2.7.1 Многочлены с коэффициентами, принадлежащими полю GF(28)
Многочлены третьей степени с коэффициентами GF(28)из конечного поля имеют вид:
(14)
Таким образом, в этих многочленах в роли коэффициентов при неизвестных задействованы байты вместо бит. Далее такие многочлены будем представлять в форме слова[a0,a1, a2,a3].
В стандарте AES при умножении многочленов используется приведение по модулю другого многочлена .
Для изучения арифметики рассматриваемых многочленов введем дополнительно многочлен:
,(15)
где GF(28).
Тогда сумма многочленов иимеет вид:
.(16)
Умножение является более сложной операцией. Пусть, мы перемножаем два многочлена:
,
. (18)
Результатом умножения будет многочлен
,(19)
где ;
;
;
;
;
;
Чтобы результат можно было представить четырехбайтовым словом, необходимо взять результат по модулю многочлена степени не более 4. Авторы шифра выбрали для этой цели многочлен , для которого справедливо
. (20)
Поэтому в произведении коэффициенты при степенях , 0,1,2, 3 равны сумме произведений по индексам, для которых,
, = 0,1,2,3. Таким образом, после приведения по модулю получим:
, (21)
где;
;
;
Рассмотрим подробнее преобразования раунда шифрования:
1) операция SubBytes. Операция выполняет нелинейную замену байтов, выполняемую независимо с каждым байтом матрицы State. Замена обратима и построена путем комбинации двух преобразований над входным байтом (рисунок 12);
2) нахождение обратного (инвертированного) элемента относительно умножения в поле GF(28) (считается, что нулевой байт {00} переходит самв себя);
3) выполнение некого аффинного преобразования: умножение инвертированного байта на многочлен
(22)
и суммирование с многочленом
(23)
в поле F2.
В матричной форме процедура SubBytes записывается как
, (24)
где через обозначены входные биты, а через - выходные.
Если на вход функции попадает нулевой байт, то результатом замены будет число . Процесс замены байтов с помощью таблицы подстановки иллюстрирует рисунок 12. Нелинейность преобразования обусловлена нелинейностью инверсии , а обратимость - обратимостью матрицы.
Рисунок 13-Операция SubBytes
Созданную на основе операцииSubBytes специальную таблицу замен байтов в шестнадцатеричной системе называют S-боксом или таблицей преобразований SubBytes(таблица 13).
Таблица 13 -Таблица преобразований SubBytes
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
A |
B |
C |
D |
E |
F |
||
0 |
63 |
7C |
77 |
7B |
F2 |
6B |
6F |
C5 |
30 |
01 |
67 |
2B |
FE |
D7 |
AB |
76 |
|
1 |
CA |
82 |
C9 |
7D |
FA |
59 |
47 |
FO |
AD |
D4 |
A2 |
AF |
9C |
A4 |
72 |
CO |
|
2 |
B7 |
FD |
93 |
28 |
36 |
3F |
F7 |
CC |
34 |
A5 |
E5 |
F1 |
71 |
D8 |
31 |
15 |
|
3 |
04 |
C7 |
23 |
C3 |
18 |
96 |
05 |
9A |
07 |
12 |
80 |
E2 |
EB |
27 |
B2 |
75 |
|
4 |
09 |
83 |
2C |
1A |
1B |
6E |
5A |
AO |
52 |
3B |
D6 |
B3 |
29 |
E3 |
2F |
84 |
|
5 |
53 |
D1 |
00 |
ED |
20 |
FC |
B1 |
5B |
6A |
CB |
BE |
39 |
A4 |
AC |
58 |
CF |
|
6 |
DO |
EF |
AA |
FB |
43 |
4D |
33 |
85 |
45 |
F9 |
02 |
F7 |
50 |
3C |
9F |
A8 |
|
7 |
51 |
A3 |
40 |
8F |
92 |
9D |
38 |
F5 |
BC |
B6 |
DA |
21 |
10 |
FF |
F3 |
D2 |
|
8 |
CD |
0C |
13 |
EC |
5F |
97 |
44 |
17 |
C4 |
A7 |
7E |
3D |
64 |
5D |
19 |
73 |
|
9 |
60 |
81 |
4F |
DC |
22 |
2A |
90 |
88 |
46 |
EE |
B8 |
14 |
DE |
5E |
0E |
DE |
|
A |
E0 |
32 |
3A |
0A |
49 |
06 |
24 |
5C |
C2 |
D3 |
AC |
62 |
91 |
95 |
AE |
79 |
|
B |
E7 |
CB |
37 |
6D |
8D |
D5 |
4E |
A9 |
6C |
56 |
F4 |
EA |
65 |
E7 |
8B |
08 |
|
C |
BA |
78 |
25 |
2E |
1C |
A6 |
B4 |
C6 |
F8 |
DD |
74 |
IF |
4B |
BD |
1D |
8A |
|
D |
70 |
3E |
B5 |
66 |
48 |
03 |
F6 |
OE |
61 |
35 |
57 |
B9 |
86 |
C1 |
2B |
9E |
|
E |
E1 |
F8 |
98 |
11 |
69 |
D9 |
8E |
94 |
9B |
1E |
87 |
E9 |
CE |
55 |
28 |
DF |
|
F |
8C |
A1 |
89 |
OD |
BF |
E6 |
42 |
68 |
41 |
99 |
2D |
OF |
BO |
54 |
BB |
16 |
Например, если 1,1, то результат замены этого байта следует искать на пересечении строки с индексом и столбца с индексом . Операция ShiftRows применяется к строкам матрицы State- ее первая строка неподвижна, а элементы нижних трех строк циклически сдвигаются вправо на 1, 2 и 3 байта соответственно (рисунок 14). По сути это перестановка элементов матрицы, в которой участвуют только элементы строк, поэтому преобразование обратимо.
.
Рисунок14- Операция ShiftRows
С помощью операции MixColumns выполняется перемешивание байтов в столбцах матрицы State. Каждый столбец этой матрицы принимается за многочлен над полем GF(28) и умножается на фиксированный многочлен
(25)
по модулю многочлена (рисунок 15).
Как показано выше, такую операцию можно записать в матричном виде как
(26)
Рисунок15-ОперацияMixColumns
Функция AddRoundKey(State,RoundKey) побитово складывает элементы переменной RoundKey и элементы переменной State по принципу: i-й столбец данных ( 0,1,2,3) складывается с определенным4-байтовым фрагментом расширенного ключа , где - номер поточного раунда алгоритма (рисунок 16).
При шифровании первое сложение ключа раунда происходит до первого выполнения операции SubBytes.
Рисунок 16- Операция AddRoundKey
Рисунок 17 демонстрирует свойства рассеивания и перемешивания информации в ходе шифрование алгоритмом AES. Видно, что два раунда обеспечивают полное рассеивание и перемешивание информации. Достигается это за счет использования функций ShiftRowsи MixColumns. Операция SubBytes придает шифрованию стойкость против дифференциального криптоанализа, а операция AddRoundKey обеспечивает необходимую секретную случайность.
Рисунок 17-Перемешивание информации
Для трех вариантов ключей AES полный перебор требует 2127, 2191 или 2255операций соответственно.
Даже наименьшее из этих чисел свидетельствует, что атака с использованием перебора ключей сегодня не имеет практического значения. В соответствии с оценками разработчиков шифр устойчив против таких видов криптоаналитических атак как:
1) дифференциальный криптоанализ;
2)линейный криптоанализ;
3)криптоанализ на основе связанных ключей (слабых ключей в алгоритме нет)
2.8 Защита от дизассемблирования
Процесс дизассемблирования представляет собой преобразование программы в её исходный код на языке ассемблера. Обладая исходным кодом, злоумышленник может определить важную функцию и использовать её, например, авторизацию в приложение.
Подобные документы
Проектирование базы данных для автоматизации деятельности по учету автотранспорта ГИБДД Вяземского района. Выбор инструментария для разработки базы данных и приложения по её ведению. Описание интерфейса и физической структуры приложения баз данных.
курсовая работа [2,2 M], добавлен 28.06.2011Разработка приложения, позволяющего автоматизировать документооборот предприятия по списанию основных средств. Мероприятия по защите и обеспечению целостности базы данных. Разработка клиентского приложения. Запросы к базе данных, руководство пользователя.
курсовая работа [700,0 K], добавлен 14.01.2015Разработка клиент-серверного приложения, определяющего объемы закупок товаров; автоматизация построения тренда с целью уменьшения затрат времени на прогнозирование объемов продаж. Программная реализация: структура базы данных, интерфейс программы.
курсовая работа [3,0 M], добавлен 23.05.2013Инфологическая и даталогическая модели предметной области. Проектирование функциональной структуры приложения, защиты базы данных. Алгоритмы решения задачи и их реализация. Разработка инструкций для сопровождающего программиста и для пользователя.
курсовая работа [2,5 M], добавлен 20.11.2013Проектирование приложения для базы данных "Оптовый склад" средней сложности с типовым пользовательским интерфейсом. Изучение особенностей ведения учета поставщиков, покупателей, продаж, движения товара на складе. Выборка, удаление таблиц из базы данных.
курсовая работа [424,1 K], добавлен 03.11.2014Логическая и физическая модели базы данных. Запрет на содержание неопределенных значений. Размещение базы данных на сервере. Реализация клиентского приложения управления базой данных. Модульная структура приложения. Основные экранные формы приложения.
курсовая работа [1,4 M], добавлен 13.06.2012Разработка Web-приложения для ООО "Научно-производственная фирма по применению информационных технологий в электрических сетях". Техническое задание, проектирование процессов, создание базы данных, разработка дизайна, тестирование и отладка сайта.
дипломная работа [3,8 M], добавлен 24.06.2011Автоматизация системы снятия показаний счетчиков энергии. Разработка базы данных и клиентского приложения для структур жилищно-коммунального хозяйства, занимающихся составлением квитанций. Описание предметной области. Тестирование клиентского приложения.
курсовая работа [953,3 K], добавлен 01.09.2016Методы проектирования базы данных по заданной предметной области с использованием CASE-средств ER/Studio и СУБД MS Access. Формирование и связывание таблиц, ввод данных. Создание экранных форм, запросов, отчетов, меню приложения. Генерация приложения.
курсовая работа [884,0 K], добавлен 08.09.2010Назначение и логическая структура системы документооборота ИП Быкова Л.Ф. Техническое задание и программное обеспечение информационной подсистемы учета закупок и реализации продовольственной продукции; создание базы данных и клиентского приложения.
дипломная работа [5,7 M], добавлен 11.06.2014