0000000000000000000000000 cw42-180620153131

РЕФЕРАТ
Звіт про виконання ДР: 75 с., 23 рис., 21 табл., 32 джерела, 4 додатки
Ключові слова: ЗАХИСТ ІНФОРМАЦІЇ, ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ,
ШИФРУВАННЯ, КРИПТОГРАФІЯ, RC4
Розглянуті питання захисту інформації, що зберігається та передається, за допомогою шифрування і розміщення на з’ємних носіях.
У процесі виконання роботи розглянуто модель оцінки рівня безпеки автоматизованих систем, алгоритм шифрування RC4, розроблено архітектуру прикладного
програмного та апаратного забезпечення, розроблено прототип – рішення для захисту інформації в середовищі Windows.
В якості використовуваних технологій проектування та реалізації обрані:
UML, XƎLATEX, C#, C++, AVR.
РЕФЕРАТ
Отчет о выполнении ДР: 75 с., 23 рис., 21 табл., 32 источника, 4 приложения
Ключевые
слова:
ЗАЩИТА
ИНФОРМАЦИИ,
ОБЕСПЕЧЕНИЕ, ШИФРОВАНИЕ, КРИПТОГРАФИЯ, RC4
ПРОГРАММНОЕ
Рассмотрены вопросы защиты информации, хранящейся и передаваемой с помощью шифрования и размещения на съемных носителях.
В процессе выполнения работы рассмотрена модель оценки уровня безопасности автоматизированных систем, алгоритм шифрования RC4, разработана архитектура прикладного программного и аппаратного обеспечения, разработан прототип – решение для защиты информации в среде Windows.
В качестве используемых технологий проектирования и реализации избраны:
UML, XƎLATEX, C#, C++, AVR.
ABSTRACT
Report of implementation of DW: 75 p., 23 fig.,21 tab., 32 sources, 4 appendices
Key words: INFORMATION PROTECTION, SOFTWARE, ENCRYPTION,
CRYPTOGRAPHY, RC4
The questions of information protection stored and transmitted via removable media
drives and encryption are researched.
In the work were reviewed the model for evaluating the safety of automated systems
and encryption algorithm RC4. The author has made a prototype of information security
solution, its architecture for software and hardware system parts.
Such technologies were used: UML, XƎLATEX, C#, C++, AVR.
2
ЗМІСТ
Перелік позначень та скорочень . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Вступ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1 Опис предметної області та постановка задачі дослідження . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Опис предметної області . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Аналіз існуючих методів захисту інформації . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Модель кількісної оцінки рівня уразливості системи . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Постановка задачі . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Теоретичні основи для розробки засобу захисту інформації . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Розробка загальної схеми вирішення задачі . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Вибір алгоритму шифрування . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Потоковий алгоритм шифрування RC4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Алгоритм ініціалізації S-блоку (Key-Scheduling) . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Алгоритм
генерації
псевдовипадкових
чисел
(Pseudo-Random
Generation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Розробка програмного та апаратного забезпечення . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Розробка специфікації системних вимог . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Функціональні вимоги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Нефункціональні вимоги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Вибір системної архітектури . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Вибір методології розробки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Розробка протоколу обміну . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Вибір апаратної платформи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Розробка пакету UML-діаграм . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1 Діаграма розгортання . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2 Діаграма класів клієнтського ПЗ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.3 Проектування мікропрограмного ПЗ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Проектування апаратного забезпечення . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Вибір інструментальних засобів реалізації програмного забезпечення . . . . 35
4 Огляд програмної реалізації та тестування програмного забезпечення. . . . . . . . . . 37
4.1 Вхідна і вихідна інформація програмної системи. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Вимоги до апаратної та програмної частини користувача . . . . . . . . . . . . . . . . . . . 37
3
4.3 Процес інсталяції ПС. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Опис візуального інтерфейсу системи. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Результат використання системи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Тестування системи. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6.1 Планування робіт . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.2 Проектування та виконання тестування . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6.3 Аналіз отриманих результатів . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 Економічне обґрунтування науково-дослідної роботи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Вступ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Обґрунтування цілей і задачі дослідження . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Оцінка рівня науково-технічного ефекту роботи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4 Розрахунок кошторису витрат на проведення науково-дослідної роботи . . 52
5.4.1 Заробітна плата персоналу . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.2 Відрахування в бюджет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.3 Витрати на відрядження . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.4 Контрагентські витрати . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.5 Витрати на матеріали . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.6 Витрати на електроенергію . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4.7 Витрати на воду та інші ресурси . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.8 Витрати на устаткування і покупні вироби . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.9 Витрати на малоцінний інвентар . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.10Амортизаційні відрахування . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.11Накладні витрати . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5 Оцінка соцiально-економічного ефекту НДР . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6 Загальні питання охорони праці та навколишнього середовища . . . . . . . . . . . . . . . . . 59
6.1 Загальні питання охорони праці. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2 Структура управління охороною праці на підприємстві . . . . . . . . . . . . . . . . . . . . . 59
6.3 Загальна характеристика приміщення та робочого місця . . . . . . . . . . . . . . . . . . . . 60
6.4 Метеорологічні параметри робочої зони . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5 Освітлення . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.6 Шум та вібрація у робочому приміщенні . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.7 Електробезпека . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4
6.8 Ергономічні вимоги до робочого місця . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.9 Охорона навколишнього середовища. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Висновки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Список джерел інформації . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Додаток А Артефакти, що були отримані в ході виконання роботи . . . . . . . . . . . . . . . . . 69
Додаток Б Схема СУОПП для підприємства «ВІРТ» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Додаток В Загальна характеристика приміщення щодо вибухо-пожежної небезпеки та за важкістю робіт . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Додаток Г Загальна характеристика умов праці . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5
ПЕРЕЛІК ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ
AES – Advanced Encryption Standard;
CASE – Computer-Aided Software Engineering;
CIA – Confidentiality, Integrity, and Availability;
CPU – Central Processing Unit;
CRC – Cyclic Redundancy Check;
GUI – Graphical User Interface;
HDD – Hard Drive Disk;
MVC – Model-View-Controller;
RAD – Rapid Application Development;
RAM – Random Access Memory;
RC4 – Rivest Cipher 4;
RUP – Rational Unified Process;
SD – Secure Digital;
SDK – Software Development Kit;
SHA – Secure Hash Algorithm;
UDP – User Datagram Protocol;
UML – Unified Modeling Language;
USB – Universal Serial Bus;
WEP – Wired Equivalent Privacy;
WPA – Wi-Fi Protected Access;
ІБ – Інформаційна Безпека;
КНОІ – Канал Несанкціонованого Отримання Інформації;
МВС – Міністерство Внутрішніх Справ;
НДР – Науково-Дослідницька Робота;
ОС – Операційна Система;
ПДВ – Податок на Додану Вартість;
ПЕОМ – Персональна Електрона Обчислювальна Машина;
ПЗ – Програмне Забезпечення;
ПС – Програмна Система;
СУОП – Система Управління Охороною Праці.
6
ВСТУП
Інформаційна безпека – невід’ємна деталь будь-якої діяльності, пов’язаної з
розмежуванням прав доступу до інформації. Державні органи та зовнішньополітичні відомства, військово-промисловий комплекс, приватний бізнес (в тому числі
інтернет-сервіси) – ось невелика частина списку споживачів, зацікавлених у збереженні своєї інформації в таємниці від третіх осіб.
Розроблено безліч методів захисту інформації, серед яких: кодування, криптографія, стеганографія. Один з найпростіших і ефективних, криптографічний, спирається в основному на обчислювальні можливості сучасних комп’ютерів.
Існуючий рівень забезпечення безпеки можна проаналізувати, якщо звернути увагу на загальнодоступну інформацію. Мова йде про експлуатації уразливості
Heartbleed таких популярних інтернет-сервісів як Wikipedia, GitHub, IFTTT, а також
ОС Android, деяких дистрибутивів Linux, роутерів Cisco systems та інших. У ході
експлуатації даної уразливості зловмисники отримали особисті дані користувачів
цих продуктів: імена, номери паспортів і банківських карт, тощо.
Очевидно, що для приватної інформації подібні витоки неприпустимі, що змушує військові відомства та інші подібні організації шукати свої шляхи вирішення
проблеми інформаційної безпеки. Їх практика показує, що використання сертифікованого побутового апаратного та програмного забезпечення (наприклад, материнських плат) зводить систему безпеки нанівець: обладнання та програми мають закриту архітектуру, а копіювання цінної інформації на незахищений носій не представляється складним завданням для користувача сертифікованого, але побутового
обладнання і програмного забезпечення.
Відомі уразливості можуть таємно експлуатуватися впродовж тривалого часу,
якщо продукт має закриту архітектуру. Таким же чином з ужитку вийшли моноалфавітні шифри, такі як шифр Цезаря: закритість конкретної деталі алгоритму не
означає можливості зворотного інжинірингу зловмисником.
Тож можна зробити висновок про потреби ринку в ряді вузькоспеціалізованих
продуктів для забезпечення інформаційної безпеки з відкритою архітектурою.
Метою даної дипломної роботи є розробка архітектури для подібного засобу,
а також реалізація його дешевого і працездатного прототипу.
7
1 ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ ДОСЛІДЖЕННЯ
1.1 Опис предметної області
Інформаційна безпека – захищеність інформації і підтримуючої інфраструктури від випадкових або навмисних впливів природного або штучного характеру, здатних завдати шкоди власникам або користувачам інформації і інфраструктури [1].
Об’єктом інформаційної безпеки вважається інформація, яка зачіпає державні, службові, комерційні, інтелектуальні та особистісні інтереси, а також засоби та
інфраструктуру її обробки і передачі [1].
Для характеристики основних властивостей інформації як об’єкта захисту часто використовується модель CIA [2]:
– конфіденційність (confidentiality) – властивість інформації, яка полягає в тому, що інформація не може бути отримана неавторизованим користувачем;
– цілісність (integrity) – означає неможливість модифікації неавторизованим
користувачем;
– доступність (availability) – властивість інформації бути отриманою авторизованим користувачем, за наявності у нього відповідних повноважень, в необхідний
для нього час.
Згідно з українським законодавством [3], вирішення проблеми інформаційної
безпеки має здійснюватися шляхом:
– створення повнофункціональної інформаційної інфраструктури держави та
забезпечення захисту її критичних елементів;
– підвищення рівня координації діяльності державних органів щодо виявлення, оцінки і прогнозування загроз інформаційній безпеці, запобігання таким загрозам та забезпечення ліквідації їхніх наслідків, здійснення міжнародного співробітництва з цих питань;
– вдосконалення нормативно-правової бази щодо забезпечення інформаційної безпеки, зокрема захисту інформаційних ресурсів, протидії комп’ютерній злочинності, захисту персональних даних, а також правоохоронної діяльності в інформаційній сфері;
– розгортання та розвитку Національної системи конфіденційного зв’язку як
сучасної захищеної транспортної основи, здатної інтегрувати територіально розпо-
8
ділені інформаційні системи, в яких обробляється конфіденційна інформація.
Системну класифікацію загроз [4], що зазнає інформація, наведено в таблиці 1.1.
Таблиця 1.1 – Системна класифікація загроз інформації
Параметри класифікації
1
Значення
параметрів
2
Зміст значення
3
Порушення
фізичної
Знищення (спотворення)
цілісності
Види загроз
Порушення
логічної
Спотворення структури
структури
Порушення змісту
Несанкціонована
модифікація
Порушення
Несанкціановане
конфиденційності
отримання
Порушення права
Привласнення чужого
власності
права
Відмови; Збої; Помилки;
Природа походження
Довільна
Стихійні лиха; Побічні
впливи.
Навмисна
Зловмисні дії людей
– Кількісна недоста-
Передумови появи загроз
Об’єктивні
тність елементів системи;
– Якісна
недоста-
тність елементів системи.
9
Закінчення таблиці 1.1
1
2
3
Розвідоргани іноземних
держав; Промислове
Суб’єктивні
шпигунство; Кримінальні
елементи; Недобросовісні
співробітники.
Люди
Джерела загроз
Сторонні особи;
Користувачі; Персонал.
Реєстрації; Передачі;
Технічні пристрої
Зберігання; Переробки;
Видачі.
Моделі,
алгоритми,
програми
Загального призначення;
Прикладні; Допоміжні.
Ручні; Інтерактивні;
Технологічні
Внутрішньомашинні;
схеми обробки
Зовнішня середа
Мережеві.
Стан атмосфери; Побічні
шуми; Побічні сигнали.
Виділяють ряд завдань інформаційної безпеки [1].
1 Забезпечення права особистості і суспільства на отримання інформації.
2 Забезпечення об’єктивною інформацією.
3 Боротьба з кримінальними погрозами у сфері інформаційних і телекомунікаційних систем, з телефонним тероризмом, відмиванням грошей і т.д.
4 Захист особистості, організації, суспільства і держави від інформаційнопсихологічних загроз.
5 Формування іміджу, боротьба з наклепом, чутками, дезінформацією. Роль
інформаційної безпеки зростає при виникненні екстремальної ситуації, коли будьяке недостовірне повідомлення може привести до погіршення обстановки.
Суб’єктами інформаційної безпеки є органи та структури, які в тій чи іншій
10
мірі займаються її забезпеченням. Крім цього, суб’єктами ІБ можуть бути:
– громадяни та громадські об’єднання;
– засоби масової інформації;
– підприємства та організації незалежно від форми власності.
1.2 Аналіз існуючих методів захисту інформації
Створення системи інформаційної безпеки передбачає виявлення джерел інформаційних небезпек і загроз. Існують чотири дії, пов’язані з інформацією, які можуть містити в собі загрозу:
– збір;
– модифікація (спотворення);
– витік і знищення інформації.
Ці дії є базовими для розгляду класифікації джерел інформаційних небезпек і
загроз.
Повна класифікація загроз надана у вигляді діаграми на рисунку 1.1.
Рисунок 1.1 – Класифікація інформаційних загроз
Рівень захисту сучасних інформаційних систем є недостатнім, що обумовлює
актуальність роботи. Є декілька дуже широко відомих злочинів такого роду.
1 Stuxnet і ядерна програма Ірану [5]. 2010 рік. Комп’ютерний черв’як Stuxnet
успішно атакував і частково вивів з ладу ядерну систему Ірану. За іранськими даними, восени вірус заблокував роботу п’ятої частини іранських центрифуг, при цьому
скопіював запис систем відеоспостереження та прокрутив її під час операції, щоб
служба безпеки нічого не запідозрила. Оскільки атака виявилася успішною, виникло припущення, що це розробка ізраїльських спецслужб, яким допомагали США.
11
2 Команда найвідомішого спамера Валдіра Пауло де Алмейди в момент його
арешту бразильською владою розсилала три мільйони фішингових листів в день [6].
За різними оцінками, йому вдалося викрасти з банківських карт до $37 млн. Крадіжка грошей проводилася за допомогою «троянів», які проникали в пристрої користувачів онлайн-банкінгу з шкідливих розсилок. Діяла група з 18 чоловік.
3 12 лютого 2004 компанія Microsoft заявила про крадіжку вихідного коду операційної системи Windows 2000 [7]. Було вкрадено 600МБ даних, це 31000 файлів
або 13,5 млн рядків коду. Витік інформації торкнувся і Windows NT4. Спочатку корпорація заявила, що код був вкрадений через партнерську компанію Mainsoft, проте
пізніше з’ясувалося, що дані були вкрадені прямо з мережі Microsoft. Викрадені дані
були викладені в мережу.
Сучасний захист інформації реалізується за допомогою трьох підходів [8]:
– апаратні:
1) генератори кодів;
2) біометричні пристрої;
3) пристрої ”прозорого” шифрування.
– програмні:
1) антивірусне ПЗ;
2) криптографічні засоби;
3) засоби ідентифікації користувачів;
4) засоби аудиту.
– організаційні:
1) розробка організаційно-розпорядчих документів, які регламентують
весь процес отримання, обробки, зберігання, передачі та захисту персональних даних;
2) заснування відділу інформаційної безпеки підприємства, що несе відповідальність за ІБ.
Апаратні та програмні заходи захисту засновані на використанні електронних
пристроїв і спеціальних програм, що входять до складу автоматизованої системи і
виконують (самостійно або в комплексі з іншими засобами) функції захисту.
Організаційні заходи необхідні для забезпечення ефективного застосування
інших заходів і засобів захисту в частині, що стосується регламентації дій людей.
12
У той же час організаційні заходи необхідно підтримувати більш надійними апаратними та програмними заходами.
Очевидно, що найбільш вигідним є впровадження програмних засобів захисту, так як вони не вимагають розробки, закупівлі обладнання, додаткового навчання персоналу. Серед інших, найбільш перспективним є захист даних за допомогою
криптографічних засобів, бо він дозволяє гарантувати захист, цілісність, полегшує
контроль доступу.
1.3 Модель кількісної оцінки рівня уразливості системи
Для кількісної оцінки рівня безпеки інформаційної системи зручно використовувати математичну модель.
Одна з таких досить універсальних моделей враховує вплив множини випадкових факторів. Сам по собі їх вплив не веде до несанкціонованого доступу до інформації, однак сприяє появі каналів несанкціонованого отримання інформації (КНОІ),
ними і може скористатися зловмисник.
Вірогідність несанкціонованого отримання інформації порушником k-ї категорії по i-му КНОІ в I-й зоні i-го структурного компонента системи визначається
залежністю [4], наведеної у формулі 1.1.
(a)
(c)
(v)
(i)
PijkI = PkiI PijI PijkI PijI
де
(1.1)
(a)
PkiI – ймовірність доступу порушника k-ї категорії в I-у зону i-го компонента системи;
(c)
PijI – ймовірність наявності j-го КНОІ в I-й зоні i-го компонента системи;
(v)
PijkI – ймовірність доступу порушника k-й категорії до j-го КНОІ в I-й
зоні i-го компонента за умови доступу порушника в зону;
(i)
PijI – ймовірність наявності інформації в j-му КНОІ в I-й зоні i-го компоненту в момент доступу порушника.
Вірогідність несанкціонованого отримання інформації в одному компоненті
системи одним зловмисником однієї категорії по одному КНОІ називається базовим
показником вразливості інформації [4] і має вигляд, наведений у формулі 1.2.
13
(B)
Pijk
N [
]
∏
(a) (c) (v)
(i)
1 − PkiI PijI PijkI PijI
=1−
(1.2)
i=1
де
N – загальна кількість компонентів системи.
Виконавши згортку базового показника ризику по компонентах системи i, по
каналах отримання інформації j і за категоріями зловмисників k, отримуємо загальний показник уразливості системи [4], приведений в формулі 1.3.
P =1−
∏[
1−
(B)
Pijk
i
]∏[
j
1−
(B)
Pijk
]∏[
1−
(B)
Pijk
]
(1.3)
k
1.4 Постановка задачі
Як можна побачити з таблиці 1.1, користувачі інформаційних систем різного
роду піддаються великої кількості загроз. Очевидно, що визнання P ≡ 0 є неможливим, що доказує актуальність роботи.
Для зменшення показника уразливості системи необхідно впливати на окремі
показники P (a) , P (c) , P (v) , P (i) .
Автор вважає, що такий вплив може бути досягнений за допомогою накопичувача даних з ”прозорим” шифруванням та відкритою апаратною і програмною
архітектурами.
Таким чином, потрібно спроектувати і розробити працездатний прототип накопичувача даних з відкритою архітектурою. Користувачами закінченого рішення
можуть бути будь-які зацікавлені приватні особи чи організації.
Об’єктом дослідження є механізм забезпечення інформаційної безпеки в автоматизованих системах.
Предмет дослідження – сукупність криптографічних алгоритмів і прикладних
аспектів підвищення інформаційної безпеки в середовищі ОС Windows.
Мета роботи – отримання працездатного прототипу засобу захисту інформації
в середовищі ОС Windows.
14
2
ТЕОРЕТИЧНІ ОСНОВИ ДЛЯ РОЗРОБКИ ЗАСОБУ ЗАХИСТУ ІНФОРМАЦІЇ
2.1 Розробка загальної схеми вирішення задачі
Розробка накопичувача даних з ”прозорим” шифруванням та відкритою апаратною і програмною архітектурами полягає у виконанні ряду завдань. Головною
задачею є керування процесом доступу до Flash-накопичувача таким чином, щоб
виключити можливість небажаного витоку, змінення чи знищення інформації.
Для формалізації процесів буде використовуватись нотація IDEF0 – нотація
для створення функціональних моделей; є структурованим зображенням функцій
виробничої системи чи середовища, а також інформації та об’єктів, що зв’язують
ці функції. Після створення функціональної моделі проводиться функціональна декомпозиція – система розбивається на підсистеми і кожна підсистема описується
окремо.
Процес розробки формалізовано в нотації IDEF0 на діаграмі, яку представлено
на рисунку 2.1.
Рисунок 2.1 – Модель процесів роботи в нотації IDEF0
15
Надалі проведена декомпозиція функціональної моделі, її наведено в додатку А на рисунках А.3 – А.4.
2.2 Вибір алгоритму шифрування
В якості основного критерію класифікації криптографічних алгоритмів використовується тип виконуваного над вихідним текстом перетворення [9].
Класифікацію криптографічних алгоритмів в нотації UML діаграми класів наведено на рисунку 2.2.
Рисунок 2.2 – Класифікація криптографічних алгоритмів
Тайнопис припускає, що відправник і одержувач виконують над повідомленням перетворення, відомі тільки їм двом. Стороннім особам невідомі зміни над
відкритим текстом, що і є гарантією безпеки даних на етапі аналізу.
На противагу тайнопису, криптоалгоритми з ключем побудовані на тому принципі, що алгоритм впливу на передані дані відомий всім стороннім особам, але він
залежить від деякого параметра, який тримається в секреті – «ключа», який відомий лише двом особам, бере участі в обміні інформацією. Основу такого підходу до
шифрування заклав в кінці XIX століття голландець Огюст Керкхофф, який запропонував, що стійкість шифру повинна визначатися тільки секретністю ключа, тобто
криптоаналітику можуть бути відомі всі деталі процесу шифрування і дешифрування, але невідомо, який ключ використовувався для шифрування даного тексту [10].
16
Сьогодні криптографія займається виключно алгоритмами з ключами. Це обумовлено тим, що захищеність системи не повинна залежати від секретності чогось,
що неможливо швидко змінити в разі витоку секретної інформації, а змінити ключ
шифрування на практиці набагато простіше, ніж весь використовуваний в системі
алгоритм.
Симетричне шифрування використовує один і той же ключ і для зашифрування, і для розшифрування.
Поточний шифр – це симетричний шифр, в якому кожен символ відкритого
тексту перетворюється на символ шифрованого тексту в залежності не тільки від
використовуваного ключа, а й від його розташування в потоці відкритого тексту [9].
Блоковий шифр оперує групами біт фіксованої довжини – блоками, характерний розмір яких змінюється в межах 64-256 біт. Якщо вихідний текст (або його залишок) менше розміру блоку, перед шифруванням його доповнюють. Фактично, блоковий шифр являє собою підстановку на алфавіті блоків [9].
Асиметричне шифрування використовує два різних ключі: один для зашифрування (який також називається відкритим), інший для розшифрування (називається
закритим) [9].
Сьогодні блокові алгоритми, такі як AES, широко використовуються для захисту даних під час їх передачі на великих швидкостях. Інший широко відомий симетричний шифр, Rivest Chiper 4, є менш вимогливим до обсягу оперативної пам’яті
та є більш простим для розуміння. Саме цей алгоритм використовується в стандарті
WEP для забезпечення захисту передачі даних в реальному часі, тому для створення
прототипу захисту інформації автор обрав RC4.
2.3 Потоковий алгоритм шифрування RC4
Rivest Cipher 4 – потоковий шифр, що широко застосовується в різних системах захисту інформації в комп’ютерних мережах (наприклад, в протоколах SSL і
TLS, алгоритмі безпеки бездротових мереж WEP і WPA) [11].
Основні переваги шифру - висока швидкість роботи і змінний розмір ключа.
RC4 досить уразливий, якщо використовуються не випадкові або пов’язані ключі,
один ключовий потік використовується двічі. Ці фактори, а також спосіб використання можуть зробити криптосистему небезпечною (наприклад WEP).
17
Головними факторами, що сприяли широкому застосуванню RC4, були простота його апаратної й програмної реалізації, а також висока швидкість роботи алгоритму в обох випадках.
Узагальнена діаграма діяльності для алгоритму наведена на рисунку 2.3.
Рисунок 2.3 – Узагальнена діаграма діяльності для алгоритму RC4
На вхід алгоритму RC4 надходить потік даних для шифрування m і послідовність ключових бітів k. Так виходить шифрограма c:
c i = mi ⊕ k i
Розшифровка полягає в регенерації ключового потоку (ki ) і складення з шифрограмою (ci ) по модулю двох. В силу властивостей підсумовування за модулем двох на
виході ми отримаємо вихідний незашифрований текст (mi ):
mi = ci ⊕ ki = (mi ⊕ ki ) ⊕ ki
18
За умови, що послідовність бітів ключа обирається довільно і не має періодів, зламати шифр неможливо, але виникає проблема передачі довгого ключа. Тому на практиці для генерації ключового потоку k використовується генератор псевдовипадкових
чисел на основі заданого ключа.
Процес отримання ключового потоку k складається з двох етапів:
1) ініціалізація S-блоку (Key-Scheduling Algorithm);
2) генерація
псевдовипадкових
чисел
ki
(Pseudo-Random
Generation
Algorithm).
Для генерації ключового потоку шифр використовує прихований внутрішній
стан, що складається з двох частин:
– перестановки, що містить всі можливі байти від 0 до 255 (S);
– змінні-лічильники x = 0, y = 0.
2.3.1 Алгоритм ініціалізації S-блоку (Key-Scheduling)
Діаграму діяльності алгоритму наведено на рисунку 2.4.
Рисунок 2.4 – Діаграма діяльності для Key-Scheduling Algorithm
19
Алгоритм використовує ключ key, який подається на вхід користувачем, і має
довжину l байт.
S=
{0, 1, . . . , 255};
j=
0;
j=
(j + Si + keyi÷l ) ÷ 256;
a=
Si ;
Si =
Sj ;
Sj =
a;
i=
(2.1)
0, 255.
Максимальне значення i (на формулі 2.1 це 255) визначає розмір слова для
алгоритму та залежить від параметру n. Як правило n = 8, тож маємо 28 = 256
ітерацій для здійснення перестановок S.
2.3.2 Алгоритм генерації псевдовипадкових чисел (Pseudo-Random
Generation)
Діаграму діяльності алгоритму наведено на рисунку 2.5.
Рисунок 2.5 – Діаграма діяльності для Pseudo-Random Generation Algorithm
20
Генератор ключового потоку RC4 переставляє значення, що зберігаються в S.
В одному циклі RC4 визначається одне n-бітове слово K з ключового потоку. Надалі
ключове слово буде складено по модулю два з вихідним текстом, який користувач
хоче зашифрувати.
21
3
РОЗРОБКА ПРОГРАМНОГО ТА АПАРАТНОГО ЗАБЕЗПЕЧЕННЯ
3.1 Розробка специфікації системних вимог
3.1.1 Функціональні вимоги
Ана́ліз ви́мог полягає в визначенні потреб та умов які висуваються щодо нового, чи зміненого продукту, враховуючи можливо конфліктні вимоги різних замовників, таких як користувачі чи бенефіціари.
Аналіз вимог є критичним для успішної розробки проекту. Вимоги мають бути задокументованими, вимірними, тестовними, пов’язаними з бізнес-потребами, і
описаними з рівнем деталізації достатнім для конструювання системи.
Функціональні вимоги – це перелік функцій або сервісів, які повинна надавати
система, а також обмежень на дані і поводження системи при їхньому виконанні.
Специфікація функціональних вимог – опис функцій та їхніх властивостей, які не
містять у собі протиріч і виключень.
Для системи, що розробляється були сформульовані наступні функціональні
вимоги:
1) засіб повинен працювати в середовищі Windows NT, бути сумісним з
Windows 7, 8, 8.1;
2) засіб повинен виконувати шифрування файлів та каталогів, при чому:
– користувач повинен мати змогу обрати носій, на якому будуть збережені дані;
– користувач повинен мати змогу обрати ключ шифрування.
3) засіб повинен виконувати дешифрування своїх криптоконтейнерів, при чому:
– засіб повинен працювати навіть якщо користувач не знає алгоритму
шифрування та тип криптоконтейнера, але знає лише ключ шифрування;
– засіб повинен перевіряти ключ шифрування так, щоб у випадку помилкового ключа користувач отримував про це інформацію;
– засіб повинен мати змогу перевіряти цілісність криптоконтейнеру.
Функціональні вимоги було формалізовано до UseCase-діаграми, яку наведено
на рисунку 3.1.
22
Рисунок 3.1 – UseCase-діаграма функціональних вимог
3.1.2 Нефункціональні вимоги
Нефункціональні вимоги визначають умови виконання функцій (наприклад,
захист інформації у БД, аутентифікація доступу до ПС тощо) у середовищі, що безпосередньо не пов’язані з функціями, а відбивають потреби користувачів щодо їх виконання. Ці вимоги характеризують принципи взаємодії із середовищами або іншими системами, а також визначають показники часу роботи, захисту даних і досягнення якості з урахуванням рекомендацій використовуваного стандарту. Вони можуть
встановлюватися як числові значення (наприклад, час чекання відповіді, кількість
клієнтів, що обслуговуються і ін.) у різних одиницях виміру, включаючи, наприклад, ймовірність (значення ймовірності безвідмовної роботи системи – показника
її надійності).
Для системи, що розробляється були сформульовані наступні нефункціональні
вимоги:
1) користувач повинен мати змогу використовувати ПЗ в зручному інтерфейсі;
2) в процесі роботи засіб не повинен блокувати взаємодію з файлами та каталогами, які він опрацьовує.
3.2 Вибір системної архітектури
Архітектура програмного забезпечення містить такі важливі визначення [12]:
23
– організації системи програмного забезпечення;
– структурних елементів і їх інтерфейсів, з яких система складається, їх поведінка у взаємодії;
– склад цих елементів у великих підсистемах;
– архітектурний стиль, який визначає це ПЗ, його елементи і їх інтерфейси, їх
взаємодія та їх склад.
Архітектура програмного забезпечення стосується не тільки структури та поведінки, а й використання, функціональності, продуктивності, стійкості, повторного
використання, зрозумілості, економічних і технологічних обмежень, компромісів і
естетики ПЗ.
Системна архітектура – частина загальної архітектури ПЗ. Вона може бути
представлена у виді кортежу, який задається наступною множиною:
SA = ⟨C, F, I⟩ ,
де
C – множина програмних компонентів, які реалізовані на різних мовах
програмування та виконують задану функціональність системи;
F – множина допустимих структурних взаємодій, в яких можуть бути
об’єднані елементи з множини C;
I – множина зовнішніх інтерфейсів, які дана система надає зовнішнім системам, компонентам, користувачам.
Автор розглядав наступні патерни системних архітектур:
– standalone application. Всі дані зберігаються та обробляються в одному місці;
– 2-tier application. Обробка даних може проходити завдяки серверу;
– 3-tier application. Обробка та збереження даних забезпечується відповідними серверами.
Автором обрано трирівневу архітектуру завдяки наступним перевагам:
1) збереження даних відбувається на зімнному носії, який легко замінити в
разі поломки, сховати або винищити;
2) шифрування даних відбувається на спеціальному сервері. Він захищений
від втручань в свою роботу: мінімум комунікаційних інтерфейсів та програмного
забезпечення;
3) ”Тонкий” клієнт є менш вразливим, адже уся робота по збереженню і ши-
24
фруванню відбувається в іншому місці.
3.3 Вибір методології розробки
Автор розглядав дві альтернативні методології розробки ПЗ:
– RUP – Rational Unified Process;
– RAD – Rapid Application Development.
В основі RUP лежать наступні принципи:
– рання ідентифікація і безперервне усунення основних ризиків;
– концентрація на виконанні вимог замовників до виконуваній програмі;
– очікування змін у вимогах, проектних рішеннях і реалізації в процесі розробки;
– компонентна архітектура, реалізована і тестована на ранніх стадіях проекту;
– постійне забезпечення якості на всіх етапах розробки проекту;
– робота над проектом в згуртованої команді, ключова роль у якій належить
архітекторам.
Схематично методологію RUP зображено на рисунку 3.2.
Рисунок 3.2 – Схема стратегії RUP
25
З іншого боку, принципи RAD технології спрямовані на забезпечення трьох
основних її переваг: високій швидкості розробки, низької вартості і високої якості.
В основі RAD лежать наступні принципи:
– інструментарій повинен бути націлений на мінімізацію часу розробки;
– мінімізація часу розробки версії, за рахунок перенесення вже готових модулів;
– команда розробників повинна тісно співпрацювати, кожен учасник повинен
бути готовий виконувати декілька обов’язків;
– управління проектом має мінімізувати тривалість циклу розробки.
Принципи RAD застосовуються не тільки при реалізації, але і поширюються
на всі етапи життєвого циклу, зокрема на етап обстеження організації, побудови вимог, аналіз і дизайн. Порівняння цих методологій наведено в таблиці 3.1
Таблиця 3.1 – Порівняння методологій розробки
Властивості
Методологія розробки
RUP
RAD
На всіх етапах
На початку ітерації
Архітектура
Компонентна
Компонентна
Вибір
Забезпечення високої якості
Забезпечення високої
інструментів
розробки
швидкості розробки
Поділ ролей
Чіткий
Розмитий
Якість, відповідність
Якість, швидкість,
вимогам
дешевизна
Очікування змін у
вимогах
Пріоритети
Зважаючи на стислі строки, команду з одного студента та незмінність вимог,
була обрана методологія RAD.
3.4 Розробка протоколу обміну
Для обміну між клієнтом та сервером потрібно використати готову реалізацію
транспортного протоколу, або розробити власну.
В ході виконання роботи було вирішено орієнтуватися на протокол UDP [13],
бо він простий в реалізації та добре підходить в для цілей тестування і налагодже-
26
ння, бо не потребує підтвердження про доставку і має зрозумілу, мінімалістичну
структуру. Ії наведено в таблиці 3.2.
Таблиця 3.2 – Структура UDP пакету
Біти
0 – 15
0 – 31
Порт відправника (Source port)
32 – 63
Довжина датаграми (Length)
64 – …
16 – 31
Порт одержувача (Destination
port)
Контрольна сума (Checksum)
Дані (Data)
UDP не надає жодних гарантій доставки повідомлення для вищого за ієрархією протоколу і не зберігає стану відправлених повідомлень.
UDP забезпечує багатоканальну передачу (за допомогою номерів портів) і перевірку цілісності (за допомогою контрольних сум) заголовка і істотних даних, але
протокол не гарантує правильної послідовності пакетів та доставки пакетів взагалі.
Таким чином автор виділив ряд недоліків протоколу UDP в контексті реалізації даної дипломної роботи. Список проблем а також їх вирішення наведено в таблиці 3.3.
Таблиця 3.3 – Проблеми UDP та їх можливі вирішення
Недолік UDP
Вирішення
Немає підтримки декількох пристроїв
Необхідно додати поля для адреси
на шині
відправника та адреси одержувача
Правильна послідовність пакетів не
гарантована
Передача може обірватися після
отримання валідного заголовку. Замість
секції даних може бути отриманий шум
(через збій)
Використовувати протокол як stateless
(без збереження стану, по аналогії з
HTTP)
Обов’язково перевіряти розмір пакету.
Помістити блок контрольної суми після
тіла пакету
З урахуванням всіх зауважень, було розроблено схему пакету для власної реалізації. Її наведено в таблиці 3.4.
27
Таблиця 3.4 – Структура пакету за власним протоколом
Назва блоку
Розмір (біт)
Призначення
Data Size
16
Вказує на розмір секції даних
Sender Address
64
Адреса відправника
Target Address
64
Адреса одержувача
Target Sensor
64
Data
<Data Size>
CRC
32
Внутрішня адреса одержувача
(”порт”)
Секція даних – ”тіло” пакету
Контрольна сума CRC32 всіх
попередніх секцій
Так як протокол розроблено без збереження стану, стан передається в кожному
пакеті. Приклад тіла пакету для передачі даних на пристрій наведено в таблиці 3.5.
Таблиця 3.5 – Структура тіла пакету для запису даних на знімний носій
Назва блоку
Розмір (біт)
Призначення
Режим запису. 0 – звичайний
Mode
8
режим запису, 255 – перезапис
ФС
Offset
32
Відступ від нульового байту
файлу, байт
Повний розмір файлу.
Total size
32
Використовується тільки якщо
<Mode>= 255
Data size
32
Розмір даних в секції <Data>
Data
<Data Size>
Секція даних – ”тіло” файлу
3.4.1 Вибір апаратної платформи
Існує безліч апаратних засобів, за допомогою яких може бути реалізоване
”прозоре” шифрування з записом на знімний носій. Серед умов розробки значиться
реалізація на ”слабкій” апаратній платформі, доступ до якої не обмежується ціною
та часом входження в розробку, тому розглядалися не всі доступні засоби.
28
Таблиця 3.6 – Порівняння апаратних платформ
Простота
Назва
Налагоджувальна
плата
Архітектура
Частота
розробки (за
10-бальною
шкалою)
1
ATmega 2560
STM32F103
2
3
Arduino MEGA 2560
AVR
R3 та інші
STM32F103-DIP40
та інші
Cortex M3
4
0–
40MHz
72MHz
5
2
5
Таким чином вибір пав на процесор ATmega 2560 на більш розповсюдженій
налагоджувальній платі Arduino MEGA 2560.
ATmega 2560 – це розповсюджений 8-бітний мікроконтролер з 256 kB flash
пам’яті, 4 kB EEPROM енергонезалежної пам’яті та 8 kB SRAM (”оперативна”
пам’ять). З такими характеристиками контролер потребує лише 1.8 V 500 µA живлення, тож може працювати навіть від акумуляторних батарей [14].
Жорсткі обмеження вимушують використовувати нескладні алгоритми та
низькорівневі технології розробки.
3.5 Розробка пакету UML-діаграм
3.5.1 Діаграма розгортання
Діаграма розгортання – діаграма, на якій представлені вузли системи.
Діаграма розгортання застосовується для подання загальної структури і топології системи і містить зображення розміщення компонентів по окремих вузлах системи. Крім того, діаграма розгортання показує наявність фізичних з’єднань - маршрутів передачі інформації між апаратними засобами, задіяними в реалізації системи.
На рисунку 3.3 показана діаграма розгортання для системи, що розроблюється.
29
Рисунок 3.3 – Діаграма розгортання
Як видно з рисунка 3.3, для реалізації поданих вище вимог було обрано класичну трирівневу архітектуру з ”тонким” клієнтом – прикладним додатком, який
базується на користувальницькому обладнанні.
3.5.2 Діаграма класів клієнтського ПЗ
Діаграма класів (class diagram) служить для представлення статичної структури моделі системи в термінології класів об’єктно-орієнтованого програмування. На
цій діаграмі показують класи, інтерфейси, об’єкти й кооперації, а також їхні відносини.
Клієнтське ПЗ (”тонкий” клієнт) є об’єктно-орієнтованим, тож для нього побудована діаграма класів, яку наведено на рисунку 3.4.
30
Рисунок 3.4 – Узагальнена діаграма класів клієнтського ПЗ
”FileSystemPanel” та ”ProtectedFileSystemPanel” з пакету ”UI” репрезентують
інтерфейс користувача, а саме – панелі файлового менеджеру: загальну, для файлів
користувача, та безпечну, для з’єднання та синхронізації з безпечним пристроєм.
За отримання даних з відповідних файлових систем відповідають класи
”FileSystem” та ”ProtectedFileSystem” з пакету ”Model”.
Клас ”App” за пакету ”Controller” містить контролер програми. Для кожної
файлової панелі передбачено контролер ”FilePanel”.
Так як програмне забезпечення представляє собою двопанельний файловий
менеджер (як показано на рисунку 3.5), на діаграмі відображена уніфікація подібного роду панелей за допомогою інтерфейсу ”IFilePanelView”.
31
Рисунок 3.5 – Mockup головного вікна інтерфейсу клієнтського ПЗ
Архітектура додатку в цілому відповідає патерну MVC.
3.5.3 Проектування мікропрограмного ПЗ
Мікропрограмне забезпечення повинно бути максимально низькорівневим,
тому його зазвичай розроблюють за допомогою таких мов програмування як
Assembler, C та C++.
Автор роботи вирішив, що для скорочення часу на розробку прототипу доцільно буде використовувати найбільш простий інструмент – мову C++. Для спрощення роботи з конкретною апаратною платформою автор використовував Arduino
SDK [15].
Мікропрограмне забезпечення не є об’єктно-орієнтованим через те, що апаратні ресурси платформи, на якій програма буде виконуватись, можуть бути сильно
обмежені. З тією ж ціллю внутрішній протокол обміну з комп’ютером розроблено
без збереження стану між передачами.
32
Узагальнену діаграму діяльності для мікропрограмного забезпечення наведено на рисунку 3.6.
Рисунок 3.6 – Узагальнена діаграма діяльності для мікропрограмного забезпечення
33
Програмне забезпечення використовує особливості розробленого протоколу:
перевіряє цільову адресу пакету, контрольну суму, порт.
Для реалізації комунікації за розробленим протоколом була розроблена бібліотека «libNetwork» [16]. Вона виконує перевірки контрольних сум та визначає
обробник, до якого будуть передані дані. Детальну діаграму діяльності реалізації
«libNetwork» наведено на рисунку 3.7.
Рисунок 3.7 – Діаграма діяльності для мережевої частини мікропрограмного ПЗ
Згідно діаграми, мікропрограмне забезпечення постійно працює в режимі очікування команди з мережі. Після одержання даних виконується виділення необхідного об’єму пам’яті (якщо є така кількість вільної пам’яті), перевірка контрольної
суми, передача пакету до належного обробника. Останній, якщо це необхідно, може
сформувати власний пакет і надіслати його у відповідь.
3.6 Проектування апаратного забезпечення
Апаратне забезпечення виконується на базі раніше обраної платформи
Arduino MEGA 2560 R3. Ця платформа має апаратну підтримку інтерфейсу SPI, його підтримку забезпечує контролер ATmega 2560 [14], а обмін даними з комп’ютером
34
може бути здійснений за допомогою USB. Остання можливість не підтримується
апаратно контролером, але реалізована за допомогою мікроконтролеру ATmega
16U2 на налагоджувальній платі [17].
Згідно до діаграми діяльності, яку наведено на рисунку 3.6, апаратне забезпечення потребує доступу до SD-карти пам’яті та з’єднання з комп’ютером для одержання команд.
Карти пам’яті SD використовують інтерфейс SPI для читання та запису даних [18] – саме для цього використовується апаратна підтримка SPI мікроконтролеру. Для зв’язку з комп’ютером будуть використовуватись можливості налагоджувальної плати.
На рисунку 3.8 зображено принципову схему розробленого пристрою.
Рисунок 3.8 – Принципова схема апаратного забезпечення
На схемі показано підключення SD-карти до налагоджувальної плати: контакти ”+3.3”, ”GND”, ”CS”, ”SCK”, ”MOSI”, ”MISO” для живлення картки, для вибору
конкретної карти (пристрій можна розширити декількома картками пам’яті), вводу
даних на картку та виводу з картки відповідно.
Для індикації стану пристрою додано декілька світлодіодів. Живлення подає-
35
ться на налагоджувальну плату через USB.
3.7 Вибір інструментальних засобів реалізації програмного забезпечення
На сьогоднішній день ринок надає широкий вибір технологій реалізації програмного забезпечення. В якості потенційних засобів розробки програмного забезпечення для дослідження операцій розглядалися наступні технології: Java, C#,
Python. Список з цих технологій був складений виходячи з знань учасника кожної з
них, дозволяє виключити з плану роботи витрати часу на вивчення нової технології.
В розділі 3.3 роботи була обрана методологія розробки RAD. Вона орієнтована
на високу швидкість розробки при низькій вартості, тому при виборі інструментарію
були сформульовані відповідні критерії:
– крос-платформеність – один і той же програмний код повинен покрити якомога більше платформ;
– доступність – розробка повинна бути максимально дешевою;
– простота розробки – час розробки має бути мінімальним;
– наявність зручного та сучасного GUI-фреймворку для швидкої розробки
графічного інтерфейсу.
Порівняння технологій за обраними критеріями наведені в таблиці 3.7.
Таблиця 3.7 – Порівняння технологій реалізації
Назва
1
Java
Крос-платформеність
Доступність
2
3
Виконується у
Ліцензія вільна,
віртуальній машині.
вихідний код
Реалізовано механізм
доступний; IDE,
just in time compilation.
компілятор і
Віртуальна машина
віртуальна
доступна на більшості
машина
ОС
безкоштовні
Простота
розробки
4
GUI
фреймворки
5
Сувора
типізація,
орієнтація на
ООП
Swing
36
Закінчення таблиці 3.7
1
C#
2
3
Виконується у
Ліцензія не
віртуальній машині.
вільна, вихідний
Реалізовано механізм
код доступний;
Сувора
just in time compilation.
IDE, компілятор і
типізація,
Віртуальна машина
віртуальна
орієнтація на
доступна на Windows,
машина
ООП
частково на Linux
пропрієтарні, але
(Mono)
безкоштовні
Виконується у
віртуальній машині.
Компілюється в
Python
байт-код або
інтерпретується.
Віртуальна машина
доступна на більшості
ОС
Ліцензія вільна,
вихідний код
доступний; IDE,
компілятор і
віртуальна
машина
безкоштовні
4
5
Windows
Forms,
WPF
Динамічна
типізація,
відсутність
орієнтації на
QT
певну
парадигму
Після аналізу зазначених технологій, автор прийшов до висновку про необхідність використання Python як єдиного інструменту розробки, однак після аналізу
ситуації на ринку GUI-фреймворків для Python вирішено використовувати C#.
37
4
ОГЛЯД ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
4.1 Вхідна і вихідна інформація програмної системи
Програмне забезпечення реалізує шифрування будь-яких файлів з робочого
каталогу. Таким чином, вхідною інформацією є множина файлів та ключ їх шифрування.
Вихідна інформація записується на з’ємний диск та представляє собою один
файл криптоконтейнеру. Ключ шифрування не зберігається, контроль правильності
вводу ключа здійснюється за контрольною сумою вихідного файлу, яка записана в
заголовку криптоконтейнеру.
4.2 Вимоги до апаратної та програмної частини користувача
Висуваються такі вимоги до апаратного забезпечення користувача:
– CPU Intel Atom N270 або будь-який інший сумісний;
– RAM 1024 МБ і більше;
– HDD 512 МБ і більше.
Вимоги до програмного забезпечення:
– операційна система Windows 7 або будь-яка інша сумісна;
– платформа .NET Framework 4 або новіша.
4.3 Процес інсталяції ПС
Для інсталяції програмної системи необхідно:
1) отримати zip-архів з файлами програмного забезпечення та апаратну частину програмної системи;
2) розпакувати вміст архіву в будь-яке зручне місце на жорсткому диску
комп’ютера;
3) під’єднати апаратний пристрій в будь-який вільний USB-порт комп’ютера.
Після виконання цих дій можна запускати файл ”FileManager.exe” – графічний
інтерфейс користувача.
38
4.4 Опис візуального інтерфейсу системи
Графічний інтерфейс системи являє собою менеджер файлів з додатковою
функцією синхронізації з безпечним накопичувачем. Інтерфейс програми після запуску наведено на рисунку 4.1.
Рисунок 4.1 – Головне вікно графічного інтерфейсу користувача
Інтерфейс представляє собою класичний двопанельний файловий менеджер. З
лівого боку знаходиться файлова система користувача, з правого – тимчасова директорія, яка може бути синхронізована з безпечним накопичувачем. В нижній частині
правої панелі знаходиться інформація про підключений накопичувач.
На знімку екрану цифрами позначено наступні елементи інтерфейсу:
1) перехід на попередню директорію;
2) перехід на директорію вище;
3) створити директорію;
4) копіювати виділений файл (файли, директорії) за активної панелі в неактивну;
5) перемістити виділений файл (файли, директоріх) за активної панелі в неактивну;
39
6) оновити активну панель;
7) видалити елементи з активної панелі;
8) порівняти зміст директорій;
9) порівняти файли;
10) новий файл;
11) пошук файлів;
12) активний диск;
13) список файлів;
14) з’єднатися з обраним пристроєм;
15) обрати пристрій з підключених до комп’ютера;
16) оновити список доступних пристроїв;
17) отримати інформацію про пристрій;
18) перевірка з’єднання з пристроєм;
19) прогрес активної операції;
20) лоґ роботи з пристроєм.
На рисунку 4.2 наведено вікно вводу пароля з’єднання.
Рисунок 4.2 – Вікно вводу ключа шифрування
Перед з’єднанням з безпечним пристроєм потрібно ввести ключ шифрування
в діалогове вікно. Якщо це не буде зроблено – буде встановлений ключ за замовчуванням.
4.5 Результат використання системи
У результаті використання ПС користувач отримує накопичувач з зашифрованими файлами, які він має змогу розшифрувати за допомогою власного ключа
шифрування. Під час роботи частина інтерфейсу користувача, що відповідає за ін-
40
дикацію з’єднання виглядає так, як показано на рисунку 4.3.
Рисунок 4.3 – Індикація процесу роботи в інтерфейсі користувача
Текстові повідомлення використовуються для додаткового інформування користувача про про хід процесу. В даному випадку користувач завантажив свої файли
на безпечний накопичувач, далі зробив зворотню операцію. Після цього він змінив
ключ шифрування та знову отримав дані з накопичувача, але контрольна сума не
збіглася з початковою. Текстовий лоґ такого сценарію наведено на рисунку 4.4.
1 [ S e c u r e M o d e l / 0 1 : 3 6 : 4 2 ] : P i n g 68ms
2 [ S e c u r e M o d e l / 0 1 : 3 6 : 4 3 ] : D e v i c e c o n n e c t e d on p o r t <COM6> , p i n g t i m e :
65ms
3 [ S e c u r e M o d e l / 0 1 : 4 2 : 1 2 ] : Sync t o d e v i c e OK
4 [ S e c u r e M o d e l / 0 1 : 4 7 : 4 7 ] : Sync from d e v i c e OK
5 [ S e c u r e M o d e l / 0 1 : 5 7 : 1 5 ] : Sync from d e v i c e OK
6 [ S e c u r e M o d e l / 0 1 : 5 7 : 1 5 ] : Wrong d a t a r e c i e v e d . I s e n c r y p t i o n key OK?
Рисунок 4.4 – Лістинг текстових повідомлень програми
4.6 Тестування системи
Тестування програмного забезпечення – це процес технічного дослідження,
призначений для виявлення інформації про якість продукту відносно контексту, в
якому він має використовуватись. Техніка тестування також включає як процес пошуку помилок або інших дефектів, так і випробування програмних складових з метою оцінки.
Може оцінюватись:
– відповідність вимогам, якими керувалися проектувальники та розробники;
– правильна відповідь для усіх можливих вхідних даних;
41
– виконання функцій за прийнятний час;
– практичність;
– сумісність з програмним забезпеченням та операційними системами;
– відповідність задачам замовника.
Тестування – це одна з технік контролю якості, що включає в себе:
1) планування робіт (Test Management);
2) проектування тестів (Test Design);
3) виконання тестування (Test Execution);
4) аналіз отриманих результатів (Test Analysis).
4.6.1 Планування робіт
Згідно до стандарту IEEE 829-1998 [19], тест-план – це документ, що описує
масштаби, підхід, ресурси і графік тестування. Він визначає тестові завдання, особливості, які будуть перевірені, завдання тестування, відповідальних осіб, які будуть робити кожну задачу, і будь-які ризики, що вимагають планування на випадок
непередбачених обставин.
Тест-план має таку структуру:
1) унікальна назва тест-плану;
2) вступ;
3) артефакти для тестування, з включенням версій;
4) список функцій ПЗ для тестування;
5) список функцій ПЗ, тестування яких необхідно уникнути;
6) список основних заходів, методів та інструментів, які використовуються
для тестування позначених груп функцій;
7) список критеріїв успіху або невдачі;
8) список критеріїв призупинення та відновлення тестування;
9) список результатів тестування: лоґи тестування, вихідні дані, звіти;
10) список завдань для підготовки тестування;
11) список вимог до середовища тестування;
12) список відповідальних осіб;
13) вимоги до рівня кваліфікації тестувальників;
14) розклад тестування;
15) ризики та план дій в надзвичайних ситуаціях;
42
16) додатки.
За цим шаблоном розроблено такий тест-план:
1 Назва: «Тестування мікропрограмного забезпечення (1)».
2 Цей тест-план призначено для тестування мікропрограмного забезпечення,
яке виконує ”прозоре” шифрування файлів та працює на мікроконтролері з архітектурою AVR. Тестування перевіряє загальну правильність роботи частини мікропрограмного забезпечення.
3 Артефакти для тестування, з включенням версій:
а) модель мікропрограмного забезпечення версії 1.
б) мікропрограмне забезпечення, версія 1.
4 Список функцій ПЗ для тестування:
а) ініціалізація ключа шифрування за замовчуванням;
б) шифрування довільного набору байтів за допомогою алгоритму RC4.
5 Уникнути тестування платформо-залежних функцій.
6 Список основних заходів, методів та інструментів, які використовуються
для тестування позначених груп функцій:
а) рівень тестування: модульне (unit-тестування), тестування продуктивності;
б) інструменти: Visual Studio 2013, Microsoft C++ Unit Test Framework.
7 Список критеріїв успіху або невдачі. Визнати невдачу, якщо хоча б одна з
умов не виконується:
а) ключ шифрування має ненульову довжину після ініціалізації;
б) лічильник довжини ключа містить вірне значення;
в) двічі зашифрована з одним і тим же ключем послідовність байт – є
початкова послідовність байт.
8 Список критеріїв призупинення та відновлення тестування:
а) призупинити тестування при знаходженні дефекту в платформозалежної частині мікропрограмного забезпечення до його виправлення;
б) якщо виправлення не торкнулися платформо-незалежної частини коду – відновити тестування.
9 Список результатів тестування:
а) звіт інструменту «Test Explorer» зі статусом unit-тестування;
43
б) абсолютні значення швидкості шифрування для моделі та прототипу
системи.
Тестування мікропрограмного забезпечення вимагає розробки низькорівневого фреймворку тестування, що збільшує кількість неперевіреного коду, тобто потенційно збільшує кількість дефектів ПЗ. Також, розробка подібного фреймворку
пов’язана зі значно більшими витратами часу ніж розробка цільового ПЗ, тому автор
прийняв рішення розробити модель тієї частини мікропрограмного забезпечення,
що відповідає за платформо-незалежні функції. Це ініціалізація початкових даних
та власне сама реалізація алгоритму RC4.
Модель створено за допомогою мови Visual C++ в середовищі Visual Studio
2013. Так як мікропрограмне забезпечення також створено за допомогою C++, в алгоритм були внесені лише незначні зміни, пов’язані з адаптацією типів даних Visual
C++ до C++.
Більшість тестів можна виконати на моделі, але тестування швидкодії буде
проходити як на моделі, так і з використанням реального апаратного забезпечення.
4.6.2 Проектування та виконання тестування
Для проектування та власне розробки тестів використано стандартний інструментарій Visual Studio 2013 – Microsoft C++ Unit Test Framework. Цей фреймворк
декларує єдиний вид всіх тестів, приклад наведено на рисунках 4.5 – 4.6.
1 # include ” stdafx . h”
2
3 u s i n g namespace M i c r o s o f t : : V i s u a l S t u d i o : : C p p U n i t T e s t F r a m e w o r k ;
4
5 namespace t e s t N a m e s p a c e
6 {
7
TEST_CLASS ( T e s t C l a s s )
8
{
9
public :
10
11
TEST_METHOD( TestMethodName )
12
{
Рисунок 4.5 – Структура класу юніт-тестування MS C++ Unit Test Framework
44
/ / some t e s t code
13
14
}
15
16
};
17 }
Рисунок 4.6 – Структура класу юніт-тестування MS C++ Unit Test Framework
Фреймворк надає декілька макросів, що спрощують розробку, це ”TEST_CLASS” та ”TEST_METHOD”. Перший визначає клас-контейнер для множини своїх
методів. Кожен з методів є юніт-тестом.
Тестування продуктивності проводиться і на моделі, і на реальному мікропрограмному забезпеченні. Для оцінки швидкодії моделі мікропрограмного забезпечення, її програмний код було модифіковано таким чином, щоб викликати Windows
API функцію ”QueryPerformanceFrequency”: вона дозволяє звернутися до високоточного системного таймеру для заміру швидкодії.
Замір швидкодії на прототипі виконується за допомогою Arduino SDK – набору допоміжних функцій для роботи з налагоджувальною платою.
Заплановані тести були розроблені за допомогою Microsoft C++ Unit Test
Framework та мови C++. Вихідний код unit-тестів наведено на рисунках А.1 – А.2 в
додатку А.
4.6.3 Аналіз отриманих результатів
Опис результатів тестування з короткою характеристикою кожного тесту наведено в таблицях 4.1 – 4.4.
Згідно до загальної схеми роботи алгоритму RC4, для роботи він потребує довільний ключ. В розробленому тестовому прикладі ключ генерується автоматично
та складається з п’яти байт, які відповідають кодам символів ”0” – ”5”. Для перевірки правильності розміщення ключа в змінній а також для перевірки внутрішньої
змінної що відповідає за довжину ключа, розроблено тест «AutoInitTest». В таблиці 4.1 наведено результати виконання тесту «AutoInitTest».
45
Таблиця 4.1 – Тест «AutoInitTest»
Показник
Значення
1
2
Перевіряється коректність
Опис тесту
ініціалізації початкових
параметрів алгоритму RC4
Початкові умови
Програма виконується
Довжина ключа RC4 буде
Очікуваний результат
складати 5 байт, значення ключа
повинно бути ”01234”.
Результат тесту
Тест пройдений п’ять
разів – помилок не виявлено
Модель мікропрограмного забезпечення повертає код виходу ”0”, якщо при
виконанні не сталося фатальної помилки. Тест «AppTest» розроблений таким чином,
щоб перевірити код виходу цього ПЗ. В таблиці 4.2 наведено результати виконання
цього тесту.
Таблиця 4.2 – Тест «AppTest»
Показник
Значення
1
2
Опис тесту
Перевіряється код виходу
програми
Програма виконується і файл
Початкові умови
”input.bin” доступний для
читання
Очікуваний результат
Результат тесту
Програма повертає код виходу
”0”
Тест пройдений п’ять
разів – помилок не виявлено
46
Алгоритм RC4 симетричний, тобто, якщо зашифрувати дані з деяким ключем, переініціалізувати S-блок та знову застосувати алгоритм до зашифрованої інформації, то програма повинна знову отримати початкову послідовність бітів. Тест
«RC4Test» розроблено для перевірки роботи такої послідовності на тестовому файлі.
Результати наведено в таблиці 4.3.
Таблиця 4.3 – Тест «RC4Test»
Показник
Значення
1
2
Перевіряється коректність
Опис тесту
роботи RC4 шифрування
Програма виконується і файл
Початкові умови
”input.bin” доступний для
читання
Зашифровані байти до
шифрування і після
Очікуваний результат
дешифрування не відрізняються
Результат тесту
Тест пройдений п’ять
разів – помилок не виявлено
Так як деякі тести спираються на читання з файлу, необхідно підтвердити, що
читання з файлу реалізовано коректно. Для цього створено тест «ReadFileTest», результати його виконання наведено в таблиці 4.4.
Таблиця 4.4 – Тест «ReadFileTest»
Показник
Значення
1
2
Перевіряється коректність
Опис тесту
читання вхідного файлу для
шифрування
47
Закінчення таблиці 4.4
1
Початкові умови
Очікуваний результат
Результат тесту
2
Програма виконується і файл
”text.txt” доступний для читання
Заздалегідь відоме значення
зчитано з файлу без помилок
Тест пройдений п’ять
разів – помилок не виявлено
Всі тести проведено в середовищі Visual Studio 2013. Згідно до показів інструменту «Test Explorer», всі тести проходять успішно, як це зображено на рисунку 4.7.
Рисунок 4.7 – Вікно «Test Explorer»
Згідно до рапорту Visual Studio 2013 ці тести покривають 81.88 % коду моделі та 100 % коду, який є кодом мікропрограмного забезпечення. Звіт наведено на
рисунку 4.8.
48
Рисунок 4.8 – Покриття коду моделі тестами
Результати тесту швидкодії наведено в таблиці 4.5.
Таблиця 4.5 – Тест швидкодії
Архітектура
Час шифрування (розшифрування),
µs B−1
x64
0.1030
AVR
8.4336
Швидкодію розробленого прототипу можна оцінити в більш зручних для порівняння одиницях. Переведемо отримані показники в kbit/s:
8.4336
· 1000
8
1
1054.2·10−6 ≈
= 1054.2 µs/kbit
948.587 kbit/s
Отримана швидкість шифрування в 0.948 587 Mbit/s без жодних оптимізацій
та на неспеціалізованому мікроконтролері – добрий показник. Деякі країни мають
середню швидкість інтернет-з’єднання таку, що близька до цієї цифри [20], наприклад Республіка Ніґер – 1.3 Mbit/s, Куба – 1.56 Mbit/s.
49
5 ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ НАУКОВО-ДОСЛІДНОЇ РОБОТИ
5.1 Вступ
Інформаційна безпека – невід’ємна частина будь-якої діяльності, особливо це
стосується обмеження доступу до інформації. Силові структури, органи внутрішніх
справ, зовнішньополітичні відомства, промисловий комплекс, приватний бізнес (в
тому числі інтернет-сервіси) складають лише невелику частину споживачів продуктів ІБ.
В лютому 2012 року хакери-любителі зламали захист серверу МВС України,
викрали дані та навіть змогли довести, що на тому сервері була встановлена неліцензована копія Microsoft Windows [21]. Інциденти подібної природи відбуваються
по всьому світу і мають найрізноманітніші масштаби [5–7].
Очевидно, що рівень захисту сучасних інформаційних систем є недостатнім.
Це обумовлює актуальність роботи.
5.2 Обґрунтування цілей і задачі дослідження
Дана науково-дослідницька робота «Розробка моделей та програмного забезпечення для криптографічного захисту файлів».
У даному розділі роботи приводиться економічне обґрунтування доцільності
проведення даного дослідження в промислових умовах. Економічна частина роботи
включає:
– розрахунок кошторисів витрат на виконання даного дослідження;
– оцінку рівня науково-технічного ефекту роботи;
– оцінку економічного й соціального ефекту НДР.
Рішення, представлене в даній науково-дослідницькій роботі, не є унікальним.
Деяка новизна роботи полягає в використанні малопотужного апаратного забезпечення з відкритою програмною та апаратною архітектурами.
5.3 Оцінка рівня науково-технічного ефекту роботи
Визначення рівня науково-технічного ефекту НДР проводиться за бальними
оцінками. За допомогою експертів установлюється перелік основних факторів, що
визначають науково-технічний рівень НДР. Кожний фактор характеризується кіль-
50
кома станами.
Експертами встановлюються оцінка кожного стану. Крім того, ними ж установлюються й коефіцієнти ваги кожного фактору. Загальну оцінку рівня науковотехнічного ефекту визначають по формулі 5.1.
UN DR
де
∑
qi · k i
= ∑i
,
Q
·
k
i
i
i
(5.1)
qi – оцінка науково-технічної значності фактору в балах;
Qi – максимальна оцінка фактору;
qi – коефіцієнт ваги даного фактору для науково-технічної ефективності
НДР.
Для оцінки науково-технічного ефекту НДР скористаємося даними, записаними у таблиці 5.1.
Таблиця 5.1 – Фактори рівня науково-технічного ефекту
Максимальний
Найменування
Характеристика факторів
Бал
1
2
3
4
5
4
10
10
2
10
22
бал
Вага
Винаходи, які
характеризуються
1.Ступінь новизни
часткової новизною, мають
прототип, що співпадає з
новим рішення по
більшості основних ознак
2.Рівень
отриманого
результату
Поліпшення незначного
числа технічних параметрів
або потенційна можливість
їх поліпшення
51
Закінчення таблиці 5.1
1
2
3.Ступінь
теоретичної
обґрунтованості
результатів НДР
3
4
5
2
10
5
4
6
20
3
8
10
5
10
10
1
10
8
Рішення задачі на основі
застосування окремих
пізнаних закономірностей
4.Ступінь експериментальної
Результати перевірені на
перевірки
незначному числі
отриманих
експериментальних даних
результатів
Отримання результатів
5.Трудомісткість
виконання НДР
супроводжувалося
проведенням нескладних
дослідів, розрахунків,
обґрунтувань
6.Перспективність
роботи
Важливі результати
сприяють задоволенню
знову виникаючих потреб
7.Рівень
досягнення
Нижче рівня світових
світових
стандартів
стандартів
Використовуючи формулу 5.2 та дані з таблиці 5.1, одержано загальну оцінку
рівня науково-технічного ефекту.
UN DR =
4 · 10 + 2 · 22 + 2 · 5 + 4 · 20 + 3 · 10 + 5 · 10 + 1 · 8
= 0.3493.
10 · 10 + 10 · 22 + 10 · 5 + 6 · 20 + 8 · 10 + 10 · 10 + 10 · 8
52
5.4 Розрахунок кошторису витрат на проведення науково-дослідної
роботи
Економічні показники науково-дослідної роботи розраховуються як показники роботи, що виконується в лабораторних умовах. Витрати на проведення науководослідних робіт відносять до виробничих витрат. До складу науково-дослідних робіт включають:
– патентний пошук;
– вивчення літератури;
– розробка програми дослідження;
– збір первинної інформації;
– налагодження машинних програм;
– розрахункові роботи;
– розробка креслень і схем;
– виготовлення дослідного зразка;
– оформлення пояснювальної записки.
Плановий кошторис витрат складається за укрупненими статтями витрат.
5.4.1 Заробітна плата персоналу
Заробітна плата персоналу, що приймають участь у виконанні науководослідної роботи, визначається на основі штатно-окладної форми оплати праці.
Вихідні й розрахункові показники зводяться в таблицю 5.2.
Таблиця 5.2 – Витрати на заробітну плату
Коефіцієнт
Склад
Кількість
Місячний
Час роботи,
виконавців
виконавців
оклад
міс.
1
2
3
4
5
6
1
4000
4
1
16000,00
1
2500
4
1
10000,00
1
3000
4
0,5
12000,00
Керівник
роботи
Інженерпрограміст
Аналітик
участі у
роботі
Сума
зарплати
53
Закінчення таблиці 5.2
1
2
3
Сума
3
9500
4
5
Преміальний
6
38000,00
2280,00
фонд
Разом
40280,00
Преміальний фонд становить 6% від фонду заробітної плати, тобто
38000.00 · 0.06 = 2280, 00 грн.
5.4.2 Відрахування в бюджет
На заробітну плату з урахуванням преміального фонду нараховуються відрахування, спрямовані в бюджет держави. До складу цих відрахувань включаються:
– відрахування в пенсійний фонд 33.2%.
– відрахування до фонду соціального страхування 1.5%.
– відрахування до фонду зайнятості 1.4%.
– відрахування до фонду страхування від нещасних випадків на виробництві
0.8%.
Відрахування в бюджет будуть наступними:
– в пенсійний фонд 40280.00 · 0.332 = 13372.96 грн.
– до фонду соціального страхування 40280.00 · 0.015 = 604.2 грн.
– до фонду зайнятості 40280.00 · 0.014 = 563.92 грн.
– до фонду страхування від нещасних випадків на виробництві 40280.00 ·
0.008 = 322.24 грн.
Відрахування складатимуть 13372.96 + 604.2 + 563.92 + 322.24 = 14863.32 грн.
5.4.3 Витрати на відрядження
Витрати на науково-дослідні відрядження плануються в розмірі 16% від фонду
заробітної плати, тобто 40280, 00 · 0.16 = 6444.8 грн.
54
5.4.4 Контрагентські витрати
До кошторису витрат включаються витрати на послуги, які здійснюються по
договорах. До таких послуг відносяться:
– надання машинного часу обчислювального центра.
– створення машинної бази даних.
– виготовлення дослідних зразків.
– розмноження оригіналів.
– виготовлення графічних матеріалів.
При аренді машинного часу на персональному комп’ютері передбачуються витрати у розмірі 10.00грн. за кожну годину роботи.
У ході виконання науково-дослідної роботи персональний комп’ютер використовувався близько 17 годин на тиждень протягом чотирьох місяців, тобто 289 годин.
Загальна сума витрат на аренду машинного часу становить 289 · 10.00 =
2890.0 грн.
Контрагентські витрати становили 2890.00 грн.
5.4.5 Витрати на матеріали
Витрати на матеріали, канцелярсько-письмові прилади розраховуються за
кількістю та їх прейскурантним цінам. Витрати на матеріали представлені в таблиці 5.3.
Таблиця 5.3 – Витрати на заробітну плату
Найменування
Одиниця
матеріалу
виміру
1
Кількість
Ціна, грн.
Сума, грн.
2
3
4
5
Шт.
1
10
10
1
60
60
3
2
6
Тека для
дипломного
проекту
Папір
Ручка
500
аркушів
Шт.
55
Закінчення таблиці 5.3
1
Картридж для
принтера
2
3
4
5
Шт.
1
400
400
Разом
476
5.4.6 Витрати на електроенергію
Витрати на електроенергію розраховуються по потужності електроустановок.
У перелік електроустановок входять:
– прилади освітлення лабораторії;
– нагрівальні установи;
– іспитові стенди;
– вимірювальні прилади.
Витрати на електроенергію по орендованій обчислювальній техніці до кошторису не включаються. Вони входять у вартість години машинного часу. Витрати на
електроенергію розраховуються за формулою 5.2.
Ze =
∑
Wh · Th · Kh · Ce ,
(5.2)
h
Wh – потужність використовуваного h-го виду обладнання, kW;
де
Th – час роботи h-го виду обладнання, h;
Kh – коефіцієнт використання обладнання;
Ce – вартість 1 kW h−1 електроенергії Ce = 0.366 грн.
В ході виконання науково-дослідної роботи використовувались такі електроустановки:
– прилади освітлення – настільні лампи 1 шт., потужністю 40 W, час роботи
лампи 300 h;
– лампи загального освітлення 5 шт., потужністю 20 W, час роботи кожної
лампи 200 h;
– оргтехніка (принтер, 1 шт.), потужністю 100 W, час роботи 3 h;
– офісна техніка (персональний комп’ютер, 1 шт.), потужністю 100 W, час ви-
56
користання 800 h годин.
Витрати на електроенергію становлять Ze = (0.04 · 300 · 1 + 0.02 · 200 · 5 + 0.1 · 3 ·
1 + 0.1 · 1 · 800) · 0.366 = 41.10 грн.
5.4.7 Витрати на воду та інші ресурси
Витрати на воду, стиснений газ, охолоджену рідину, азот і т.п. для технічний
цілей визначається аналогічно витратам на електроенергію, виходячи з добової потреби і поточних роздрібних цін. У даному дослідженні витрати на воду та інші
ресурси не передбачаються.
5.4.8 Витрати на устаткування і покупні вироби
До кошторису включається вартість тільки того устаткування, яке безпосередньо використовується для проведення даної НДР, тобто, яке має одноразове використання. Таке устаткування в НДР не передбачається.
5.4.9 Витрати на малоцінний інвентар
Витрати на малоцінний інвентар та інструменти, що швидко зношуються, приймають у розмірі 10-15% вартості використовуваного устаткування. Витрати по цьому розділу не передбачаються.
5.4.10 Амортизаційні відрахування
Амортизаційні відрахування розраховуються на основні фонду лабораторії,
що перебувають в експлуатації тривалий час. До таких елементів основних фондів
відносять приміщення та інвентар. Для трьох співробітників необхідне приміщення площею 26 m2 . Розрахунок амортизаційних відрахувань проводиться за формулою 5.3.
AM =
де
N a · T · Co
,
12 · 100
(5.3)
Na – норма амортизації основних фондів у відсотках;
T – тривалість виконання НДР в місяцях;
Co – вартість основних фондів в гривнях.
Для будинків і споруджень норму амортизації основних фондів прийняти:
– будівлі – 5%;
– обладнання – 15%.
57
Вартість приміщення оцінюється з розрахунку 1000.00 грн. за 1 m2 корисної
площі й становить C0 = 26 · 1000.00 = 26000.00 грн.
Вартість обладнання приймається в розмірі 15 % вартості приміщення й становить 26000.00 · 0.15 = 3900.00 грн.
Разом амортизаційні відрахування становлять:
AM =
5 · 4 · 26000 15 · 4 · 3900
+
= 628.35 грн.
12 · 100
12 · 100
5.4.11 Накладні витрати
Накладні загальногосподарські витрати (охорона, опалення, загальне освітлення і т.п.) приймаються в розмірі 50% від фонду заробітної плати 40280.00 · 0.50 =
20140.00 грн.
Загальна сума витрат по статтям 1-10 становить кошторисну собівартість НДР:
40280.00 + 14863.32 + 6444.8 + 2890.00 + 196.00 + 41.10 + 628.33 = 65343.55 грн.
Вартість НДР, крім собівартості, включає планові накопичення, фіксовані податки на прибуток і додану вартість, відрахування в місцевий бюджет. Загальна величина цих добавок становить 28% собівартості НДР 65343.5 · 0.28 = 18296.19 грн.
Вартість на НДР включає розрахунковий прибуток (0.8%), він становить
65343.55 · 0.08 = 5227.48 грн.
Сума ПДВ становить (65343.55 + 5227.48) · 0.20 = 14114.20 грн.
Таким чином, вартість даної НДР з урахуванням собівартості, розрахункового
прибутку, та значенням податку ПДВ становить 65343.55 + 5227.48 + 14114.21 =
84685.24 грн.
5.5 Оцінка соцiально-економічного ефекту НДР
Економічний ефект дослідницької роботи «Розробка моделей та програмного забезпечення для криптографічного захисту файлів» відбиває ступінь впливу результату на сферу захисту інформації. Характер, обсяг і напрямок такого впливу
різноманітні й можуть бути визначені для різних видів НДР з різною повнотою й
ступенем точності. У загальному виді економічний ефект (ЕНДР) пошукових і прикладних наукових досліджень визначається по формулі приведених витрат 5.4.
58
EN DR = (Cb − Cn ) − Kc · En ,
де
(5.4)
Cb – поточні витрати на виробництво до впровадження результатів НДР;
Cn – поточні витрати на виробництво після впровадження результатів
НДР;
Kc – супутні одноразові капітальні витрати, пов’язані із впровадженням
НДР;
En – нормативний коефіцієнт ефективності капітальних вкладень, приймається En = 0.15.
Для оцінювання соціально-економічного ефекту використовують два підходи:
перший – це кількісна оцінка соціально-економічного ефекту, другий – якісна оцінка. Зважаючи на те, що дана робота є науково-дослідницькою, то для неї не може
бути розраховане чисельне значення оцінки соціально-економічного ефекту. Отже,
використаємо якісну оцінку для визначення соціального ефекту науково-дослідної
роботи.
Суть економічного ефекту полягає в отриманні додаткових економічних результатів: зростання національного доходу, продуктивності праці, ресурсозбереження, зростання рівня інформаційної безпеки. Впровадження результатів даної
науково-дослідницької роботи дозволило б розробити більш досконалий пристрій
”прозорого” шифрування з відкритою апаратною та програмною архітектурами, що
дозволило б автоматизувати захист інформації для будь-яких цілей.
Соціальний ефект від впровадження НДР може мати такі позитивні сторони,
як:
– підвищення інформаційної безпеки;
– автоматизація процесу шифрування даних;
– зниження витрат на спеціальне обладнання та пропрієтарне ПЗ.
59
6
ЗАГАЛЬНІ ПИТАННЯ ОХОРОНИ ПРАЦІ ТА НАВКОЛИШНЬОГО
СЕРЕДОВИЩА
6.1 Загальні питання охорони праці
Охорона праці – це система законодавчих, організаційно-технічних,
соціально-економічних, санітарно-гігієнічних і лікувально-профілактичних мір
і засобів, спрямованих на збереження життя, здоров’я й працездатності людини
в процесі праці. Завдання охорони праці полягає в тому, щоб звести до мінімуму
ймовірність поразки працюючого під дією небезпечного виробничого фактора або
захворювання під дією шкідливого виробничого фактора з одночасним забезпеченням комфортних умов при максимальній продуктивності праці. Закон України «Про
охорону праці» визначає основні положення по реалізації конституційного права
громадян на охорону їх життя і здоров’я в процесі трудової діяльності; регулює
взаємини між адміністрацією і працівником в незалежності від форм власності;
встановлює єдиний порядок організації охорони праці в Україні [22].
Завданням законодавства про охорону навколишнього природного середовища є регулювання відносин у галузі охорони, використання і відтворення природних ресурсів, забезпечення екологічної безпеки, запобігання і ліквідації негативного впливу господарської та іншої діяльності на навколишнє природне середовище, збереження природних ресурсів, генетичного фонду живої природи, ландшафтів та інших природних комплексів, унікальних територій та природних об’єктів,
пов’язаних з історико-культурною спадщиною [23]. Згідно закону України «Про підприємства в Україні» усі роботодавці повинні турбуватись про дотримання у своєї
діяльності вимог законів України стосовно охорони праці та навколишнього природного середовища.
У даній дипломній роботі питання охорони праці розглядаються стосовно підприємства, де виконується безпосередньо робота за напрямом диплому та за умовами праці які визначені завданням.
6.2 Структура управління охороною праці на підприємстві
Система управління охороною праці (СУОП) є комплексом дій з підготовки, прийняття та реалізації рішень з метою виконання організаційних, технічних,
60
санітарно-гігієнічних і лікувально-профілактичних заходів.
Головна мета введення СУОП на підприємстві «ВІРТ» – забезпечення безпеки,
збереження життя, здоров’я та працездатності працівників під час трудового процесу. Підприємство має склад, наведений в таблиці 6.1.
Таблиця 6.1 – Структура підприємства
Номер за
журналом
Структурні підрозділи
групи
Кількість
Директор, заступник директора,
7
Примітка
працівників
технічний відділ, відділ реалізації
продукції, бухгалтерія, виробнича
Є інженер з
5
ділянка
охорони
праці
Згідно таблиці 6.1 запропонована схема СУОПП для даного підприємства, її
наведено в додатку Б «Схема СУОПП для підприємства ”ВІРТ”» на рисунку Б.1.
Управління охороною праці здійснюється на підприємстві у цілому – директором підприємства безпосередньо та через заступника. У підрозділах та відділах – керівниками підрозділів. Контроль за дотриманням вимог із питань охорони праці та
навколишнього середовища, підготовка звітності, рішень та пропозицій щодо покращення умов праці, виконує інженер із охорони праці.
6.3 Загальна характеристика приміщення та робочого місця
Приміщення лабораторії, в якій проводяться дослідження та випробування за
завданням наведені у таблиці Г.1 в додатку Г.
Згідно з НПАОП 0.00-1.28-2010 [24] в лабораторії може перебувати 7 працівників. Мінімальна припустима площа приміщення на 1 людину повинна складати не
менш 6 m2 . За умовами завдання це не виконується – в лабораторії працює 7 чоловік
та площа приміщення на 1 людину складає 5 m2 (площа – 35 m2 ) та буде виконуватися тільки у випадку зменшення кількості робітників у лабораторії. В приміщенні відсутні умови, які можуть створювати підвищену або особливо підвищену небезпеку,
тому воно відноситься до класу звичайних приміщень (згідно ПУЕ [25]). Джерелом
живлення є трифазна мережа напруги 380/220 V з глухо заземленою нейтраллю, з
61
частотою 50 Hz (згідно НПАОП 0.00-1.28.2010 [26]). За пожежо-вибухонебезпекою
приміщення лабораторії відноситься до класу В. У таблиці В.1, яка знаходиться в
додатку В «Загальна характеристика приміщення щодо вибухо-пожежної небезпеки
та за важкістю робіт», наведена загальна характеристика приміщення щодо вибухопожежної небезпеки та за важкістю робіт.
6.4 Метеорологічні параметри робочої зони
Під час роботи з ПЕОМ необхідно дотримувати оптимальні метеорологічні
умови. Оптимальні метеорологічні умови – сполучення параметрів, які при тривалому й систематичному впливі на людину забезпечують збереження нормального
функціонального й теплового стану організму без напруження реакцій терморегуляції. Параметри мікроклімату в приміщенні повинні відповідати ГОСТ 12.1.00588 [27] та ГН 3.3.5-8.6.6.1-2002 [28]. Із урахуванням категорії роботи за енерговитратами повинні дотримуватися параметри мікроклімату, наведені в таблиці 6.2.
Таблиця 6.2 – Оптимальні параметри мікроклімату
Категорія
робіт
Період року
Температура,
Відносна
Швидкість руху
C
вологість, %
повітря, m s−1
◦
Легка (Іб)
холодний
21-23
40-60
не більше 0.1
Легка (Іб)
теплий
22-24
40-60
не більше 0.2
Для підтримки в приміщенні оптимального температурного режиму відповідно до вимоги ДБН.В.2.5 – 67:2013 [29] є централізоване опалювання і вентиляція. У
теплий період року використовується кондиціювання.
6.5 Освітлення
Особливістю роботи за дисплеєм ЕОМ є постійна й значна напруга функцій зорового аналізатора, обумовленого необхідністю розходження самосвітних об’єктів
(символів, знаків і т.п.) при наявності відблисків на екрані, рядковій структурі екрана, мерехтіння зображення, недостатньою чіткістю об’єктів розходження. Для забезпечення нормального освітлення застосовуються природне бокове одностороннє й
штучне освітлення, які нормуються ДБН В.2.5-28-2006 [30] та НПАОП 0.00-1.282010 [26]. По характеру зорової роботи, робота відноситься до високої точності,
62
розряд зорової роботи III, підрозряд г. Раціональне освітлення приміщення сприяє кращому виконанню виробничого завдання і забезпеченню комфорту при роботі.
Для забезпечення нормального освітлення застосовуються природне, однобічне, бічне і штучне освітлення, а також сполучене, які нормуються санітарними нормами
й правилами ДБН В.2.5-28-2006 [30]. Дані по нормах освітлення наведені в таблиці 6.3.
Таблиця 6.3 – Норми природного й штучного освітлення
Мінімальний
Розряд,
розмір
підро-
об’єкта розрі- Фон Контраст
Нормоване значення
зряд
знювання,
зорової
мм
праці
Середній
Світлий
Від 0.3 до 0.5
Природне
освітленІІІг
ня КПО,
Штучне освітлення
%
1.5
Емін, lx
Тип ламп
300
Газорозрядні
Приміщення з постійним перебуванням людей повинно мати, як правило, природне освітлення. При виконанні роботи використовувалося природне одностороннє бокове й штучне освітлення. Нормативне значення КПО повинно бути не менш
1,5% при роботі з ПЕОМ, тому потрібно застосовувати штучне освітлення (згідно
ДБН В.2.5-28-2006 [30]).
6.6 Шум та вібрація у робочому приміщенні
У приміщенні технічного відділу причиною шуму і вібрації є апарати, прилади і устаткування: друкуючі пристрої, комп’ютери, вентилятори, кондиціонер та
ін. При їхній роботі рівень вібрації не вище 33 дБ, рівень шуму не повинен перевищувати 50 дБА, що є нормою для даного виду діяльності відповідно до ГОСТ
12.1.003-83* [31] та НПАОП 0.00-1.28-2010 [26]. Заходи по забезпеченню встановлених норм: використання спеціальних шумопоглинаючих перегородок, застосува-
63
ння меблів, які сприяють зменшенню шуму і вібрації, установка апаратів і приладів
на спеціальні амортизуючи підкладки.
6.7 Електробезпека
Для живлення устаткування (ПЕОМ, освітлювальні прилади) які є однофазними споживачами використовується трифазна мережа 380/220 V частотою 50 Hz
з глухо заземленою нейтраллю. Із цієї причини при роботі з електроприладами
існує потенційна небезпека ураження людини електричним струмом, тому в правилах устрою електроустановок (згідно ПУЕ [25]) передбачені наступні заходи електробезпеки: конструктивні, схемно-конструктивні й експлуатаційні. Конструктивні – вимоги що забезпечують захист від доторкання персоналу до струмоведучих
частин. ПЕОМ мають ступінь захисту ІР-44. Прилади освітлення ІР-23. Схемноконструктивним заходом захисту є занулення електрообладнання у приміщенні. Для
користувача ПЕОМ важливим є дотримання правил безпеки експлуатації електрообладнання. Так, заборонено доторкатися до дротів та з’єднань при наявності напруги в мережі, а також самостійно проводити ремонт електрообладнання. Усі питання
щодо ремонту налагодження та інше, можуть виконувати тільки електрики та відповідні фахівці, які мають допуск до роботи із електрообладнанням певної категорії.
6.8 Ергономічні вимоги до робочого місця
Робоче місце оператора ЕОМ обладнується робочим столом, кріслом і підставкою для ніг. Висота робочого стола регулюється в межах 0.68 – 0.80 m, а при
відсутності такої можливості має складати 0.72 m. Мінімальна ширина стола 0.6 m,
поверхня стола не блискуча. Робоче крісло оператора забезпечується підіймальноповоротним пристроєм з регулюванням висоти сидіння та спинки. Розміри підставки для ніг довжина 0.4 m, ширина не менше 0.30 m. На одного працюючого з урахуванням роботи з ПЕОМ має відводитись не менше 6.0 m2 та не менше 20 m3 об’єму
приміщення згідно (НПАОП 0.00-1.28-2010 [26]).
6.9 Охорона навколишнього середовища
Закон України «Про охорону навколишнього середовища» [23] визначає правові, економічні, соціальні основи охорони навколишнього середовища. Завдання
64
Закону полягає в регулюванні відносин у галузі охорони праці, використанні та відновленню природних ресурсів, забезпеченні екологічної безпеки, попередженню та
ліквідації наслідків негативної дії на навколишнє середовище діяльності людини,
збереження природних ресурсів, генетичного фонду нації, ландшафтів й інших природних об’єктів. Під час науково-дослідницької роботи у лабораторії утворюються
відходи у вигляді зношених й відпрацьованих деталей, відходів паперу, люмінесцентні лампи та інші. Всі відходи здаються в господарський блок для подальшої утилізації. Жорсткість вимог до виробництва й матеріалів, а також розробка нових виробничих й утилізаційних технологій дозволяє зменшити антропогенне навантаження
на навколишнє середовище. На рисунку 6.1 наведено Модель системи управління
оточуючим природним середовищем на підприємстві (згідно ДСТУ 14001 [32]).
Рисунок 6.1 – Модель системи управління оточуючим природним середовищем на
підприємстві (згідно ДСТУ 14001)
65
ВИСНОВКИ
У ході роботи була досліджена предметна область, розглянуті сучасні засоби забезпечення інформаційної безпеки, алгоритм шифрування RC4, модель оцінки
рівня вразливості інформаційної системи.
В результаті роботи запропонована програмна та апаратна архітектура для засобу ”прозорого” шифрування даних на з’ємних носіях з використанням поточного
алгоритму шифрування RC4. За допомогою мови моделювання UML побудовано
ряд діаграм, що формалізують запропоновану архітектуру. На їх основі розроблено
працездатний прототип.
Для тестування низькорівневого програмного коду розроблена модель мікропрограмного забезпечення, для якої проводилося модульне тестування, та тестування швидкодії. Проведене порівняння швидкодії однакового програмного коду на
різних апаратних платформах. Висунуто припущення, що розробка та підтримка
моделі мікропрограмного забезпечення в цілях тестування може бути більш доцільною, ніж тестування безпосередньо на пристрої, що розроблюється.
66
СПИСОК ДЖЕРЕЛ ІНФОРМАЦІЇ
1 Гафнер,
В.В.
Информационная
[Текст] / В.В. Гафнер. —
безопасность:
учебное
Екатеринубрг : Феникс плюс, 2010. —
пособие
324 с. —
ISBN: 9785222173893.
2 Information security [Electronic resource]. — [S. l. : s. n.]. — URL: https://
en.wikipedia.org/w/index.php?title=Information_security&oldid=660081755 (online; accessed: 05.06.2015).
3 Про Основні засади розвитку інформаційного суспільства [Електронний ресурс]. — [S. l. : s. n.]. — URL: http://zakon4.rada.gov.ua/laws/show/537-16 (дата звернення: 09.05.2015).
4 Малюк, А.А. Информационная безопасность. Концептуальные и методологические основы защиты информации [Текст] / А.А. Малюк. — M. : Горячая Линия
- Телеком, 2004. — ISBN: 5-93517-197-Х.
5 Стакснет [Електронний ресурс]. — [S. l. : s. n.]. — URL: https://uk.wikipedia.
org/wiki/Стакснет (дата звернення: 13.04.2015).
6 В Бразилии раскрыта банда сетевых мошенников [Электронный ресурс]. —
[Б. м. : б. и.]. — URL: http://www.securitylab.ru/news/215150.php (дата обращения:
13.04.2015).
7 В інтернеті з’явилися комерційні секрети “Mіcrosoft” - Korrespondent.net
[Електронний ресурс]. —
[S. l. : s. n.]. —
URL: http://ua.korrespondent.net/
tech/247370-v-interneti-zyavilisya-komercijni-sekreti-microsoft
(дата
звернення:
13.04.2015).
8 Белокопытов, А.В. Современные информационные технологии: учебное
пособие [Текст] / А.В. Белокопытов. — Смоленск : ФГОУ ВПО «Смоленская сельскохозяйственная академия», 2013. — ISBN: 9785457413658.
9 Бабичев, С.Г. Основы современной криптографии [Текст] / С.Г. Бабичев. —
М. : ДИАЛОГ-МИФИ, 2011. — ISBN: 9785991201827.
10 Сингх, C. Книга шифров: тайная история шифров и их расшифровки
[Текст] / C. Сингх. — [Б. м.] : Астрель, 2006. — ISBN: 9785170384778.
11 Скляров, Д.В. Искусство защиты и взлома информации [Текст] / Д.В. Скляров. — СПб. : БХВ-Петербург, 2004. — ISBN: 9785941573318.
67
12 Kruchten, P. The Rational Unified Process: An Introduction [Text] / P. Kruchten.
— [S. l.] : Addison-Wesley Professional, 2003. — 336 p. — ISBN: 0321197704.
13 Postel, J. User Datagram Protocol [Електронний ресурс]. — [S. l. : s. n.]. —
URL: https://tools.ietf.org/html/rfc768 (дата звернення: 10.05.2015).
14 ATmega640/1280/1281/2560/2561 [Electronic resource]. — [S. l. : s. n.], 2012.
— URL: http://www.atmel.com/images/doc2549.pdf (online; accessed: 26.05.2015).
15 Arduino - Home [Electronic resource]. — [S. l. : s. n.]. — URL: http://www.
arduino.cc/ (online; accessed: 17.05.2015).
16 Livich/Arduino-libNetwork [Electronic resource]. — [S. l. : s. n.]. — URL:
https://github.com/Livich/Arduino-libNetwork (online; accessed: 05.06.2015).
17 Arduino - ArduinoBoardMega2560 [Electronic resource]. — [S. l. : s. n.].
—
URL: http://www.arduino.cc/en/Main/ArduinoBoardMega2560 (online; accessed:
26.05.2015).
18 Part 1: Physical Layer. Simplified Specification [Text] // SD Specifications. —
2013. — URL: https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf
(online; accessed: 26.05.2015).
19 IEEE Standard for Software and System Test Documentation [Text] // IEEE Std
829-2008. — P. 150.
20 Download Speed by Country | Net Index from Ookla [Electronic resource]. —
[S. l. : s. n.]. — URL: http://www.netindex.com/download/allcountries/ (online; accessed:
26.05.2015).
21 Хакеры взломали сервер МВД: данные свободно разгуливают по
Интернету [Электронный ресурс]. — [Б. м. : б. и.]. — URL: http://censor.net.ua/news/
196307/hakery_vzlomali_server_mvd_dannye_svobodno_razgulivayut_po_internetu
(дата обращения: 17.05.2015).
22 Закон України ”Про охорону праці” – Введ. з 14.10.92. ( з усіма редакціями
до 2015 року).
23 Закон України ”Про охорону навколишнього природного середовища” – К.:
Україна. – 1991. - 59 с. ( з усіма редакціями до 2015 року).
24 НПАОП
40.1
–
1.32
–
01
Правила
будови
електроустановок.
Електрообладнання спеціальних установок. – Введ. з 01.01.02.
25 Правила улаштування електроустановок. ПУЕ.– Харків.: «Форт» – 2011 –
68
736 с.
26 НПАОП 0.00-1.28-10 Правила охорони праці під час експлуатації
електронно-обчислювальних машин / Зареєстровано в Міністерстві юстиції України
19 квітня 2010 р. за N 293/17588.
27 ГОСТ 12.1.005 – 88*. ССБТ. Общие санитарно-гигиенические требования
к воздуху рабочей зоны. – Введ. 01.01.89.
28 ГН 3.3.5-8.6.6.1-2002. Гігієнічна класифікація праці за показниками
шкідливості та небезпечності факторів виробничого середовища, важкості та
напруженості трудового процесу. Наказ №528 від 27.12.2001.
29 ДБН.В.2.5 – 67:2013. Опалення, вентиляція та кондиціонування. – К.:
Мінрегіон України, – 2013 – 147 с.
30 ДБН.В.2.5 – 28-2006 . Природне і штучне освітлення. – К.: Мінбуд України,
- 2008 – 74 с.
31 ГОСТ 12.1.030 – 81*. ССБТ. Электробезопасность. Защитное заземление.
Зануление. – Введ. 01.01.82.
32 ДСТУ ISO14001 - 97 – 14012-97. Система управления окружающей средой
– К.:Держстандарт України – 225 с.
69
ДОДАТОК А
Артефакти, що були отримані в ході виконання роботи
1 namespace r c 4 u n i t
2 {
3
TEST_CLASS ( R c 4 U n i t T e s t )
4
{
5
public :
6
TEST_METHOD( A u t o I n i t T e s t )
7
{
8
unsigned i n t e x c e p t e d _ l e n g t h = 5;
9
unsigned char * e x c e p t e d _ k e y = ( unsigned char *) malloc (
excepted_length ) ;
10
f o r ( i n t i = 0 ; i < 5 ; i ++) {
11
excepted_key [ i ] = i ;
12
}
13
rc4_auto_init () ;
14
A s s e r t : : AreEqual ( 0 ,
15
memcmp ( e x c e p t e d _ k e y ,
16
&r c 4 _ k e y [ 0 ] , e x c e p t e d _ l e n g t h ) ,
17
L” r c 4 _ a u t o _ i n i t ␣ key ␣ v a l u e ␣ i n v a l i d ” ,
18
LINE_INFO ( ) ) ;
19
A s s e r t : : AreEqual ( e x c e p t e d _ l e n g t h ,
20
rc4_key_length ,
21
L” r c 4 _ a u t o _ i n i t ␣ l e n g t h ␣ f a i l e d ” ,
22
LINE_INFO ( ) ) ;
23
free ( excepted_key ) ;
24
}
25
TEST_METHOD( R e a d F i l e T e s t )
26
{
27
unsigned char t e s t l e n = 4 ;
28
unsigned char * b u f f e r = ( unsigned char *) malloc ( t e s t l e n * 2) ;
29
unsigned char * e x c e p t e d = b u f f e r + t e s t l e n ;
Рисунок А.1 – Unit-тестування роботи реалізації алгоритму RC4
70
30
memset ( b u f f e r , ’ 1 ’ , t e s t l e n * 2 ) ; / / f i l l memory w i t h a v a l u e
31
read_file ( ” . / t e s t . txt ” , buffer , t e s t l e n ) ;
32
A s s e r t : : AreEqual ( 0 ,
33
memcmp ( e x c e p t e d , b u f f e r , t e s t l e n ) ,
34
L” r e a d _ f i l e ␣ f a i l e d ” ,
35
LINE_INFO ( ) ) ;
36
free ( buffer ) ;
37
}
38
TEST_METHOD( AppTest )
39
{
40
unsigned i n t excepted = 0;
41
u n s i g n e d i n t r e s u l t = _ t m a i n ( 0 , NULL) ;
42
A s s e r t : : A r e E q u a l ( e x c e p t e d , r e s u l t , L” app ␣ r u n ␣ f a i l e d ” ,
LINE_INFO ( ) ) ;
43
}
44
TEST_METHOD( RC4Test ) {
45
unsigned char t e s t l e n = 4 ;
46
unsigned char * b u f f e r = ( unsigned char *) malloc ( t e s t l e n *2) ;
47
unsigned char * e x c e p t e d = b u f f e r + t e s t l e n ;
48
memset ( b u f f e r , 1 , t e s t l e n * 2 ) ; / / f i l l memory w i t h a v a l u e
49
/ / encoding
rc4_auto_init () ;
r c 4 _ s b l o c k _ i n i t ( rc4_S , r c 4 _ k e y , r c 4 _ k e y _ l e n g t h ) ;
r c 4 (& r c 4 _ S [ 0 ] , b u f f e r , t e s t l e n ) ;
/ / re − i n i t and d e c o d i n g w i t h t h e same key
r c 4 _ s b l o c k _ i n i t ( rc4_S , r c 4 _ k e y , r c 4 _ k e y _ l e n g t h ) ;
r c 4 (& r c 4 _ S [ 0 ] , b u f f e r , t e s t l e n ) ;
A s s e r t : : AreEqual ( 0 ,
memcmp ( b u f f e r , e x c e p t e d , t e s t l e n ) ,
L” r c 4 ␣ f a i l e d ” ,
LINE_INFO ( ) ) ;
free ( buffer ) ;
50
51
52
53
54
55
56
57
58
59
60
61
62
}
};
63 }
Рисунок А.2 – Unit-тестування роботи реалізації алгоритму RC4
Рисунок А.3 – Модель процесів роботи в нотації IDEF0 (декомпозиція, початок)
71
Рисунок А.4 – Модель процесів роботи в нотації IDEF0 (декомпозиція, продовження)
72
73
ДОДАТОК Б
Схема СУОПП для підприємства «ВІРТ»
Рисунок Б.1 – Схема СУОПП для підприємства «ВІРТ»
74
ДОДАТОК В
Загальна характеристика приміщення щодо вибухо-пожежної небезпеки та за
важкістю робіт
Таблиця В.1 – Загальна характеристика приміщення щодо вибухопожежної
небезпеки та за важкістю робіт
небезпеки
вибухопожежної
приміщення щодо
Показники важкості роботи згідно ГН 3.3.5-8.6.6.1-2002
Характеристика
Звичайне, без ознак хімічного
Загальна характеристика
забруднення та нормальної
приміщення
вологості за санітарними
вимогами
Характеристика приміщень за
вибухопожежною категорією та
класом зони
Класи умов праці за показником
В–пожежонебезпечна,
Клас П-ІІ
– 1а – до 139 W m−2 ;
ТНС-індексу
– 1б – 140 – 174 W m−2 .
Клас умов праці
Оптимальний
Ступінь ризику для власного
Окремі показники напруженості
життя – виключений; Ступінь
трудового процесу
відповідальності за безпеку
інших осіб – виключена.
Значущість
помилки – допустимий:
(напруженість праці середнього
ступеня); Несе відповідальність
Ступінь відповідальності за
за функціональну якість
результат своєї діяльності
допоміжних завдань; Вимагає
додаткових зусиль з боку
керівництва; Спостереження за
екраном відеотерміналу 2-3
години на зміну.
75
ДОДАТОК Г
Загальна характеристика умов праці
Таблиця Г.1 – Загальна характеристика умов праці
Номер за
журна-
Шкідливі та небезпечні фактори
лом
на робочому місці
групи
Джерела
утворювання
небезпек
Примітка (данні
наведені для
технічного
відділу)
Електрична напруга вище 127 V,
7
шум; Випромінювання –
Кондиціонер,
Розміри
електромагнітні, радіаційні,
5 ПЕОМ,
приміщення
теплові; Статична електрика;
папір,
(Д·Ш·В, м): 7·5·3.
Пожежна небезпека у
світильники
Кількість
приміщенні; Неякісне
(лампи)
працівників – 7.
освітлення.