|
|
Скачати 171.45 Kb.
|
|
Лекція 5 ПАКУВАННЯ, АРХІВАЦІЯ І ШИФРУВАННЯ ДАНИХ В ОПЕРАЦІЙНИХ СИСТЕМАХ План лекції:
1. Історичні відомості У ті далекі часи, коли обсяг жорстких дисків (вінчестерів) вимірювався мегабайтами – цих мегабайт завжди не вистачало, і більшість файлів (особливо рідко використовуваних) зберігали в упакованому вигляді. Перед запуском файл розпаковували, а після завершення роботи – упаковували знову, щоб звільнити місце для розпакування інших. Коли ці махінації всім остаточно набридли, програмісти (згадавши, що комп'ютер повинен служити людині, а не навпаки), додумалися до автоматичного розпакування файлів, що виконуються "на льоту". Ідея полягає в дописуванні до стиснутого файла крихітного розпаковщика, якому передається керування при запуску файла, і який розпаковує код, що виконується, не на диск, а безпосередньо в оперативну пам'ять. Звичайно, час завантаження при цьому відчутно збільшувався (особливо на машинах з повільними процесорами), але це з надлишком виправдовувалося простотою запуску й економією дискового простору. Незабаром пакувальників розвелося сила-силенна (їх тоді писали всі, кому хотілося) – AINEXE, DIET, EXEPACK, LZEXE, PKLITE і інших – усіх не перелічити! І не дивно: процесори з дня у день ставали усе продуктивнішими – уже на "трійці" розпакування займало настільки незначний час, що їм можна було зневажити. До того ж приємним побічним ефектом виявився захист від дизасемблювання. Дійсно, безпосередньо дизасемблювати упакований файл неможливо – колись його необхідно розпакувати. Звичайно, на кожен щит знайдеться свій меч – з-під пера хакерів вийшло чимало чудових універсальних розпаковщиків (UNP, Intruder, UUP, а вершиною усьому став CPU386 з вбудованим емулятором реального режиму процесора 80386), але якість автоматичного розпакування залишала бажати кращого (часом розпаковані файли зависали при запуску чи в процесі роботи), а ручним трасуванням володіли далеко не всі. Словом, при усіх своїх достоїнствах, пакування виконуваних файлів не мало ніяких недоліків і не збиралося здавати позиції навіть із приходом ємних (на той час) одно-, двогігабайтних дисків і CD-ROM. 2. Стискання файлів під Windows 9x\NT Пройшов невеликий час і світ повільно, але неминуче переходив на нову операційну систему – Windows 95. Користувачі обережно освоювали мишу і графічний інтерфейс, а програмісти тим часом гарячково переносили старе програмне забезпечення на нову платформу. Обсяги вінчестерів на той час виросли настільки, що розробники могли забути слово "оптимізація", так вони, судячи з розміру сучасних додатків, його і забули. Сто мегабайт туди, триста сюди, – запросто. Тоді і згадали про розпакування виконуваних файлів "на льоту". Стискання виконуваних файлів. На ринку з'явилося декілька програм-компресорів, з яких найбільшу популярність завоювала програма ASPack, що вміє стискати і розтискати не тільки "екзешники", але і динамічні бібліотеки. А до складу самої Windows 95 увійшла динамічна бібліотека LZEXPAND.DLL, яка підтримувала базові операції пакування-розпакування і "прозору" роботу зі стиснутими файлами. Користувачі і програмісти швидко скористалися новими засобами, але... На відміну від MS-DOS, у Windows 9x\NT за автоматичне розпакування приходиться платити більше, ніж одержувати. Згадаємо, як у MS-DOS відбувалося завантаження виконуваних модулів. Файл цілком зчитувався з диска і копіювався в оперативну пам'ять, причому найбільш вузьким місцем була саме операція читання з диска. Пакування навіть прискорювало завантаження, оскільки фізично читався менший обсяг даних, а їх розпакування займало дуже короткий час. У Windows же завантажник читає лише заголовок і таблицю імпорту файла, а потім проектує його на адресний простір процесу так, ніби-то файл є частиною віртуальної пам'яті, що зберігається на диску (взагалі ж, все відбувається набагато складніше). Підкачування з диска відбуваються динамічно – у міру звернення до відповідних сторінок пам'яті, причому завантажуються тільки ті з них, що дійсно потрібні. Наприклад, якщо в текстовому редакторі є модуль роботи з таблицями, він не буде завантажений з диска доти, поки користувач не захоче створити (чи відобразити) свою таблицю. Причому неважливо – чи знаходиться цей модуль у динамічній бібліотеці, чи в основному файлі. Завантаження таких "монстрів", як Microsoft Visual Studio і Word, ніби "розмазується" у часі, і до роботи з додатком можна приступати практично відразу ж після його запуску. А що ж відбудеться, якщо файл упакувати? Він повинен буде зчитуватися з диска цілком (!) і потім – знову-таки, цілком – розпакуватися в оперативну пам'ять. Але ж нашої оперативної пам’яті явно не вистачить і розпаковані сторінки прийдеться знову скидати на диск. Причому, якщо при проектуванні не упакованого exe-файла оперативна пам'ять не виділяється (у всякому разі, доти, поки в ній не виникне необхідність), розпаковщику без пам'яті ніяк не обійтися. А оскільки оперативної пам'яті ніколи не буває занадто, вона може бути виділена лише за рахунок інших додатків. Відзначимо також, що в силу конструктивних особливостей заліза й архітектури операційної системи, операція записування на диск є помітно повільнішою за операцію зчитування. Важливо зрозуміти: Windows ніколи не скидає на диск не модифіковані сторінки файла, що проектуються. Навіщо це? Адже в будь-який момент їх можна знову зчитати з оригінального файла. Але при розпакуванні модифікуються всі сторінки файла! Виходить, система буде змушена "ганяти" їх між диском і пам'яттю, що істотно знизить загальну продуктивність усіх додатків у цілому. Стискання динамічних бібліотек Ще більші накладні витрати спричиняє стискання динамічних бібліотек. Для економії пам'яті сторінки, зайняті динамічною бібліотекою, спільно використовуються всіма процесами, що завантажили цю DLL. Але як тільки один із процесів намагається щось записати в пам'ять, зайняту DLL, система миттєво створює копію сторінки, що модифікується, і надає її в "монопольне" розпорядження процесу - “письменнику”. Оскільки розпакування динамічної бібліотеки відбувається в контексті процесу, що завантажив її, система змушена багаторазово дублювати всі сторінки пам'яті, виділені бібліотеці, фактично надаючи кожному процесору свій власний екземпляр DLL. Припустимо, одна DLL розміром у 1 Мегабайт, була завантажена десятьма процесами – порахуємо, скільки пам'яті буде дарма втрачено, якщо вона стиснута! Таким чином, під Windows 9x\NT стискати виконувані файли недоцільно – ми платимо набагато більше, ніж отримуємо. Що ж стосується захисту від дизасемблювання, то, коли ASPack тільки з'явився, він віднадив від зламу дуже багатьох некваліфікованих хакерів, але ненадовго. Сьогодні в мережі легко можна знайти посібники з так званого ручного зняття ASPack. Існує і маса готового інструментарію – від автоматичних роз пакувальників до плагінів для дизасемблера IDA Pro, що дозволяють йому дизасемблювати стиснуті файли. Тому сподіватися, що ASPack цілком врятує нашу програму від зламу, не слід. 3. Продуктивність пакування файлів Стосовно вимірювання зменшення продуктивності від пакування файлів, то тут, здавалося б, немає нічого складного – беремо не упакований файл, запускаємо його, заміримо час завантаження, записуємо результат на папірці, упаковуємо, запускаємо ще раз, і... Перший камінь спотикання – що розуміти під "часом завантаження"? Якщо проектування – так воно виконується практично миттєво, і їм можна взагалі зневажити. Момент часу, починаючи з якого з програмою можна повноцінно працювати? Так це від самої програми залежить більше, ніж від його упакування. До того ж, на час завантаження упакованих файлів дуже сильно впливає кількість вільної на момент запуску фізичної оперативної пам'яті (не слід плутати з загальним обсягом пам'яті, установленої на машині). Якщо перед запуском упакованого файла ми завершимо один-два великих програмних додатки-"монстри", то зайнята ними пам'ять виявиться вільною, і зможе безперешкодно використовуватися розпаковщиком. Але якщо вільної пам'яті немає, її прийдеться по крихтах відривати від інших додатків... Навіть якщо ми оцінимо зміну часу завантаження (що, до речі, зробити дуже проблематично – серія вимірів на одній і тій самій машині, з тим самим набором додатків дає розкид результатів більш ніж на порядок), як вимірювати падіння продуктивності інших додатків? Адже, при недостачі пам'яті Windows у першу чергу рятується від не модифікованих сторінок, які немає необхідності зберігати на диску! У результаті пакування виконуваного файла можна дещо підвищити продуктивність роботи самого цього файла, але значно погіршити стан інших, не упакованих додатків. Тому ніяких конкретних цифр навести не можна. Наближені оцінки, виконані "на око", показують, що при наявності практично необмеженої кількості оперативної пам'яті втрати продуктивності складають менше 10%, але при її недостачі швидкість усіх додатків падає від двох до десяти разів! В експерименті брали участь файли, що виконуються, MS Word 2000, Visual Studio 6.0, Free Pascal 1.04, IDA Pro 4.17, Adobe Acrobat Reader 3.4, машина з процесором CLERION-300A, оснащена 256 МБ ОЗУ, для імітації недостачі пам'яті її обсяг зменшувався до 64 МБ; використовувалися операційні системи Windows 2000 і Windows 98. Таким чином, можна зробити такі висновки та рекомендації: 1) Файли, що виконуються під Windows, краще не пакувати. У крайньому випадку – використовувати для пакування/розпакування функції операційної системи (LZInit, LZOpenFile, LZRead, LZSeek, LZClose, LZCopy), динамічно розпаковуючи в спеціально виділений буфер тільки ті частини файла, що дійсно потрібні в даний момент для роботи. 2) Динамічні бібліотеки взагалі не слід пакувати, оскільки це веде до дивовижної витрати і фізичної, і віртуальної пам'яті і псує саму концепцію DLL: один модуль – усім процесам. 3) Не слід прагнути базувати свій додаток на безлічі DLL, – сторінки виконуваного файла не вимагають фізичної пам'яті доти, поки до них не відбувається звернення. Тому сміливо можна поміщати весь код програми в один файл. 4. Принципи роботи програм-архіваторів Принцип роботи архіваторів заснований на пошуку у файлі "надлишкової" інформації і наступному її кодуванні з метою одержання мінімального обсягу. Стискання послідовностей однакових символів – найвідоміший метод архівації файлів. Наприклад, усередині нашого файла знаходяться послідовності байтів, що часто повторюються. Замість того, щоб зберігати кожен байт, фіксується кількість повторюваних символів і їхня позиція. Наприклад, файл, що буде архівуватися, займає 15 байт і складається з наступних символів: B B B B B L L L L L A A A A A або у шістнадцятковій системі 42 42 42 42 42 4C 4C 4C 4C 4C 41 41 41 41 41 . Архіватор може представити цей файл у такому вигляді (шістнадцятковому): 01 05 42 06 05 4C 0A 05 41 . Це означає: з першої позиції п'ять разів повторюється символ "B", з позиції 6 п'ять разів повторюється символ "L" і з позиції 11 п'ять разів повторюється символ "A". Для збереження файла в такій формі буде потрібно всього 9 байт, що на 6 байт менше вихідного. Описаний метод є простим і дуже ефективним способом стискання файлів. Однак він не забезпечує великої економії обсягу, якщо текст містить невелику кількість послідовностей повторюваних символів. Більш витончений метод стискання даних, використовуваний у тому чи іншому вигляді практично будь-яким архіватором, – це так званий оптимальний префіксний код і, зокрема, кодування символами змінної довжини (алгоритм Хаффмана). Код змінної довжини дозволяє записувати символи і групи символів, що найбільш часто зустрічаються, усього лише декількома бітами, у той час як рідкі символи і фрази будуть записані більш довгими бітовими рядками. Наприклад, у будь-якому англійському тексті буква E зустрічається частіше, ніж Z, а X і Q відносяться до тих, що найменш зустрічаються. Таким чином, використовуючи спеціальну таблицю відповідності, можна закодувати кожну букву Е меншим числом біт і використовувати більш довгий код для більш рідких букв. Популярні архіватори ARJ, PAK, PKZIP працюють на основі алгоритму Лемпела-Зіва. Ці архіватори класифікуються як адаптивні словникові кодувальники, у яких текстові рядки заміняються покажчиками на ідентичні їм рядки, що зустрічаються раніше в тексті. Наприклад, усі слова якої-небудь книги можуть бути представлені у вигляді номерів сторінок і номерів рядків деякого словника. Найважливішою відмінною рисою цього алгоритму є використання граматичного розбору попереднього тексту з розбиттям його на фрази, що записуються у словник. Покажчики дозволяють зробити посилання на будь-яку фразу у вікні встановленого розміру, що передує поточній фразі. Якщо відповідність знайдена, то текст фрази заміняється покажчиком на свого попереднього двійника. При архівації, як і при компресуванні, ступінь стискання файлів сильно залежить від формату файла. Графічні файли типу TIFF і GIF уже заздалегідь скомпресовані (хоча існує різновид формату TIFF і без компресії) і тут навіть найкращий архіватор мало що знайде для пакування. Зовсім інша картина спостерігається при архівації текстових файлів, файлів PostScript, файлів .ВМР і їм подібних. Програми архівації файлів Архівний файл являє собою набір з одного або декількох файлів, розміщених у стисненому вигляді в одному файлі, з якого при необхідності їх можна дістати у первісному вигляді. Архівний файл містить зміст, який дозволяє побачити, які саме файли знаходяться в архіві. Для кожного стисненого і поміщеного в архів файла зберігається така інформація:
Найбільш популярні архіватори – WinZip і WinRAR – дозволяють задавати пароль на відкриття архіва. Але існують програми, за допомогою яких можна зламати архівні файли. Ці програми-зламщики архівів можна умовно розбити на дві групи:
Більшість сучасних програм пакування даних мають вбудовану підтримку шифрування. Якщо користувач бажає захистити від чужих очей свою інформацію в архіві, йому необхідно при пакування ввести пароль, і архіватор далі сам виконає необхідні дії. При спробі видобути зашифрований файл архіватор вимагатиме у користувача пароль і розпакує файл лише тоді, коли пароль вказано правильно. Слід зауважити, що шифрування відбувається завжди після компресування, оскільки зашифровані дані не повинні відрізнятися від випадкової послідовності і, як наслідок, архіватор не зможе знайти в них надлишковість, за рахунок видалення якої і відбувається пакування. ZIP Одним з найпопулярніших форматів стискання даних серед користувачів операційної системи Windows був і залишається ZIP, розроблений компанією PKWARE, Inc. Широкого розповсюдження цей формат набув зовсім не через технічні особливості – швидке стискання, висока ступень упаковки. Існують архівні формати, що переважають ZIP за багатьма характеристиками. Скоріш за все, формат ZIP завдячує своїй популярності умовно безкоштовній програмі WinZIP. WinZIP є умовно безкоштовним продуктом. Будь-який користувач має право установити WinZIP і використовувати його на протязі 30 днів у тестових і ознайомлювальних цілях. При цьому програма є повнофункціональною, але іноді з’являється вікно повідомлення з пропозицією купити WinZIP. По завершенні тестового періоду необхідно отримати ліцензію або видалити програму з комп’ютера. Після оплати користувач отримує реєстраційний код, що відповідає його імені. Після введення правильного коду у відповідному вікні WinZIP програма вважається зареєстрованою і припиняє турбувати користувача пропозиціями про купівлю програми. Для шифрування архівів формату ZIP використовується потоковий алгоритм шифрування, розроблений Роджером Шлафлай. Але у 1994 році Елі Біхем і Пол Кошер опублікували статтю, присвячену атаці на алгоритм шифрування формату ZIP, в якому для знаходження ключа шифрування досить знати 13 послідовних байтів відкритого тексту і виконати певну операцію 238 разів. Для архівів, що містять 5 і більше файлів і створених на основі бібліотеки InfoZIP, можлива атака, що використовує в якості відкритого тексту дані з заголовків зашифрованих файлів. Цій атаці підлягли архіви, створені за допомогою програми WinZIP, але в останніх версіях цього архіватора проблема була дещо виправлена. Не дивлячись на те, що недоліки алгоритму шифрування ZIP давно відомі, він до цих пір лишається одним з найчастіше використовуваних для архівів формату ZIP. Деякий час тому а в архіваторах РКZIP і WinZIP з’явилась підтримка інших, більш стійких алгоритмів шифрування, але нове шифрування не дуже популярне з деяких причин. По-перше, нові формати зашифрованих даних в РКZIP і WinZIP не сумісні між собою, що не дозволяє прочитати одним архіватором те, що створено іншим. По-друге, компанія PKWARE, що створила РКZIP, звинувачує авторів WinZIP у тому, що, реалізувавши своє шифрування, вони порушують патенти, що належать корпорації PKWARE. У 2002 році компанія РКWARE випустила версію архіватора РКZIP, яка підтримувала більш стійкі алгоритми шифрування. Але через те, що РКZIP був розрахований на корпоративних користувачів, нове шифрування не отримало достатньої популярності. Отже, алгоритм, що використовується в WinZIP для перевірки відповідності реєстраційного коду імені користувача, давно відкритий, і в Інтернеті можна без особливих зусиль знайти початкові тексти і готові програми для обчислення цього коду. Малоймовірно, що в WinZIP Computing не знають про існування генератора кодів до їх програми, але на протязі багатьох версій схема реєстрації не змінювалась і, схоже, змінюватись не буде. Не зважаючи на порівняну простоту отримання повністю дієздатної копії WinZIP без оплати вартості ліцензії, утруднення схеми реєстрації навряд чи викличе різке збільшення об’ємів продаж. А от витрати на оновлення реєстраційних номерів у всіх легальних користувачів можуть виявитись зовсім не маленькими. ARJ Популярний з часів DOS, але рідко використовуваний в даний час архіватор, розроблений Робертом Янгом, базується на такому алгоритмі. З пароля, за дуже простим циклічним алгоритмом отримувалась гама за довжиною рівна паролю. Ця гама накладалась на дані методом додавання за модулем 2 (операція ХОR). Таким чином, наявність відкритого тексту, рівного довжині пароля, дозволяла миттєво визначити гаму і використовуваний пароль. Більш того, на самому початку упакованих даних містилась інформація компресора така, як таблиці Хаффмана, і частина цієї інформації могла бути передбачена, що дозволяло значно підвищити швидкість пошуку пароля перебором. Починаючи з версії 2.60 (листопад1997 року), ARJ підтримує шифрування за алгоритмом ГОСТ 28147-89. RAR Архіватор, розроблений Євгеном Рошалем, є непоганим прикладом того, як можна підходити до шифрування даних. В алгоритмі шифрування, використаному у RAR версії 1.5, є деякі недоліки. Так, ефективна довжина ключа шифрування складає всього 64 біти, тобто перебором 264 варіантів ключа можна гарантовано розшифрувати пароль. Більш того, наявність відкритого тексту дозволяє зменшити кількість варіантів перебору до 240. Отже, атака успішно може бути виконана навіть на одному комп’ютері (швидкість перебору на комп’ютері з процесором Intel Pentium III 333 МГц складає приблизно 600 000 паролів в секунду). У версії 2.0, вочевидь, була проведена серйозна робота над помилками. Злам нового алгоритму шифрування перебором вимагав вже приблизно 21023 операцій, що більше, ніж це можна було б здійснити на сучасній техніці. Про ефективні атаки, що використовують відкритий текст, офіційно нічого не відомо. Швидкість перебору паролів знизилась приблизно до 2000 штук за секунду (в 300 разів). Але розробники RAR продовжили роботу. У версії RAR 3.0 (травень 2002 року) для шифрування став використовуватись алгоритм AES з ключем довжиною 128 бітів. Таке рішення було викликано двома причинами. По-перше, безпечніше використовувати перевірений і добре себе зарекомендувавший алгоритм, ніж дещо саморобне, а у AES тут немає конкурентів. По-друге, у AES швидкість шифрування вища, ніж у алгоритма, використовуваного в RAR 2.0. Окрім заміни алгоритму шифрування, в RAR 3.0 використовується і інша процедура отримання ключа шифрування з пароля. Ця процедура вимагає обчислення кеш-функції SHA1 262144 рази, що дозволяє перебирати лише до 3-х паролів в секунду, тобто в 600 разів менше, ніж для RAR 2.0. Шифрування файлів у програмах Microsoft На протязі багатьох років програми, що входять у Microsoft Office, дозволяють шифрувати документи за паролем, який вводить користувач. Але не завжди файли виявляються захищеними надійно. Microsoft Word і Mirosoft Excel. Шифрування файлів було реалізоване вже в Microsoft Word 2.0. З пароля за допомогою простого циклічного алгоритму отримувалась 16-байтова гама, яка накладалась на вміст документа. Але обчислення гами баз пароля не складало труднощів, оскільки гама накладалась на службові області, які мали фіксоване значення у всіх документах. У Word 6.0/95 та Excel 5.0/95 алгоритм шифрування не змінився, а змінився лише формат файлів – він став базуватися на OLE Structered Storage. Для відновлення пароля також треба було знайти 16-байтову гаму, використану для шифрування. А знайти цю гаму можна було, базуючись на статистичному аналізі. У будь-якому тексті найчастіше зустрічається символ“ “ (пробіл). Таким чином, досить визначити код найчастіше використовуваного у тексті символа в кожній з 16 позицій, що відповідають різним байтам гами. Виконавши операцію XOR кожного знайденого значення з кодом пробілу (0х20), отримуємо байт гами. В програмах Word 97/2000 та Excel 97/2000 дані шифруються за допомогою алгоритму RC4 з ключем довжиною 40 байтів. Таке шифрування вже не дозволяє миттєво знайти пароль. Можливості обчислювальної техніки за останні роки виросли на стільки сильно, що єдиний можливий ключ шифрування документів Word (з 240 можливих) може бути знайдений максимум за чотири доби на комп’ютері з двома процесорами AMD Athlon 2600+. Починаючи з Office XP, нарешті з’явилась підтримка шифрування документів ключами довжиною більше 40 бітів. Але більшість користувачів до цих пір використовують 40-бітове шифрування, оскільки воно дозволяє відкривати захищені документи у попередніх версіях офісних програм. Та й зміна налаштувань шифрування вимагає додаткових дій з боку користувача (відкриття діалогу налаштувань і вибору потрібного криптопровайдера), тоді як за замовчуванням використовуються 40-бітові ключі. Microsoft Access. Бази даних Microsoft Access можуть мати два типи паролів: паролі на відкриття і паролі для розмежування прав доступу на рівні користувачів. Пароль на відкриття, як правило, ніколи не був серйозним захистом, оскільки, починаючи з Access версії 2.0, він зберігався у заголовку бази даних. Правда, сам заголовок був зашифрований алгоритмом RC4, але це не дуже посилювало стійкість, оскільки в рамках однієї версії формату завжди використовувався один і той самий 32-бітовий ключ шифрування, прошитий у динамічно завантажувальну бібліотеку, що відповідає за роботу з файлом бази даних. А враховуючи те, що RC4 – синхронний потоковий шифр, достатньо було один раз знайти гаму, що породжується RC4 з відомим ключем, і після цього пароль можна було визначити, виконавши додавання за модулем 2 гами і потрібних байтів заголовку. Починаючи з Access 2000, звичайне накладання гами вже не дозволяє відразу ж визначити пароль, оскільки необхідно виконати ще декілька додаткових нескладних дій. Але пароль все одно зберігається у заголовку, а отже, може бути звідти прочитаний. Слід зауважити, що установлення пароля на відкриття бази даних не приводить до шифрування її вмісту. Однак, Access підтримує таку операцію, як шифрування бази даних, але сам пароль у цьому шифруванні ніяк не приймає участі, а ключ шифрування зберігається у заголовку бази. Інший тип паролів, підтримуваних Microsoft Access, використовується не для забезпечення секретності, а для розмежування доступу. Але виявилось, що при проектуванні було допущено декілька помилок, пов’язаних з цими паролями. Правильнішим було б зберігати не самі паролі, а їх кеш-значення. Але через незрозумілі причини в системній базі даних, що містить імена, паролі та інші атрибути всіх користувачів, можна знайти самі паролі, зашифровані потрійним використанням DES з двома ключами в режимі EDE (Encrypt-Decrypt-Encrypt), коли перший ключ застосовується двічі, на першому і третьому кроці. Ключі зазвичай є константами і зберігаються у динамічно завантажуваній бібліотеці. Такий захист дозволяє швидко визначити пароль будь-якого користувача, хоча Microsoft й стверджує, що втрачені паролі користувачів не можуть бути відновлені. В системній базі даних для кожного користувача зберігається унікальний ідентифікатор, що є функцією від імені користувача і деякого довільного рядка, що вводиться при створенні облікового запису. Саме цей ідентифікатор і ключем, за яким ідентифікуються користувачі в основній базі даних. Так, наприклад, у кожної таблиці в основній базі даних є власник, який має максимальні права. Але в основній базі даних зберігається лише ідентифікатор користувача-власника, а ім’я і вся додаткова інформація для аутентифікації користувача зберігається у системній базі. І створюється враження, що якщо системна база даних буде втрачена, то доступ до вмісту основної бази даних отримати не вдасться. Але функція обчислення ідентифікатора користувача є обертаємою, що дозволяє визначити ім’я власника і рядок, введений при створенні облікового запису. Після цього лишається тільки створити нову системну базу даних і додати в неї користувача з відомими атрибутами, але взагалі без пароля. Encrypted File System. Починаючи з Windows 2000 операційні системи, які базуються на ядрі NT, підтримують Encrypted File System (EFS) – розширення файлової системи NTFS (New Technology File System), що дозволяє зберігати файли користувачів у зашифрованому вигляді. При цьому шифрування виконується цілком прозоро і не вимагає від користувача додаткових зусиль, окрім одноразової вказівки на те, що файл має бути зашифрований. Навіть якщо зловмисник зможе отримати фізичний доступ до файлової системи і прочитати захищений файл, йому не вистачатиме ключа шифрування для доступу до вмісту файла. Симетричний ключ, яким зашифровується файл (File Encryption Key, FEK), сам зашифрований на відкритому ключі, що належить користувачу, який має право доступу до файла. Ключ зберігається разом із зашифрованим файлом, і для його розшифрування використовується секретний ключ користувача. З кожним файлом може бути асоційовано декілька копій ключа, зашифрованих на відкритих ключах так званих агентів відновлення даних (Recovery Agents). Процедура отримання усієї необхідної для розшифрування інформації включає в себе багато етапів. Але у Windows 2000 реалізація EFS є такою, що в більшості випадків усі зашифровані файли можуть бути добуті без знання пароля власника або агента відновлення. Контрольні питання до Лекції 5
|
|
План-конспект лекції Тема: Передача файлів за допомогою електронної пошти Нерідко, крім повідомлення необхідно переслати, або отримати файли по електронній пошті. Розглянемо основні принципи пересилки та... |
Уроку: Навчальна Тема уроку: Поняття про стиснення даних. Архівація файлів. Програми для роботи з архівами. Створення архіву. Додавання файлів до... |
|
План лекції «Добро пожаловать в Windows 7 (Руководство по продукту Windows 7)». Microsoft, 2010. – 140 с |
ТЕМА: Операційні системи Windows. Технологія роботи з файловою системою. Програма Сформувати навички виконання основних операцій: перегляду, копіювання, перейменування, створення папок і документів, переміщення,... |
|
Лекція: Робота з файлами: версія для друку і PDA Лекція присвячена... Розглянуті особливості вікон для роботи з файловою системою. Показані способи створення нових документів на основі шаблонів, що у... |
Заняття: «Відео-технології мультимедіа. Формати відео файлів. Програмне... Мета: Ознайомити учнів з відео-технологіями мультимедіа, форматами відео файлів та програмним забезпеченням відеомонтажу |
|
Аудіо-технології, мультимедіа. Формати аудіо файлів. Програмне забезпечення... Мета: ознайомити учнів з аудіо технологіями, форматами аудіо файлів та програмним забезпеченням для роботи |
Тема. Виконання операцій з файлами та папками. Пошук файлів. Інсталювання програм Основним інструментом у Windows’98 є миша. Натискування на ліву клавішу означає вибір або підтвердження, а на праву – відміна або... |
|
Тема: Спільне використання файлів, папок, принтерів, доступ до Інтернету Навчальна мета: ввести поняття «Права доступу до ресурсів», засвоїти способи спільного використання файлів і папок, спільного використання... |
Обмін даними між графічним редактором, тестовим і табличним процесором,... За необхідності обміну даними між текстовим і табличним процесором, системою керування базами даних, засобом для розробки комп'ютерних... |