Новости

Статті та публікації

Сучасна операційна система це складний ієрархічної процес обробки і управління інформацією. Актуальні версії ОС Windows в цьому питанні не є винятком. Для того, щоб інтегрувати засіб захисту в середу ОС Windows, найчастіше вистачає вбудовування на прикладному рівні. Однак, якщо мова заходить про шифрування інформації в середовищі ОС Windows, все стає набагато складніше.

Основний "головним болем" розробника засобів шифрування в цьому процесі є забезпечення "прозорості шифрування", тобто необхідно гармонійно вбудуватися в структуру процесів операційної системи і при цьому забезпечити незалученість користувачів в процес шифрування і вже тим більше його обслуговування. Вимоги до сучасних засобів захисту все більше і більше виключають користувача з процесу захисту інформації. Таким чином, для цього самого користувача створюються комфортні умови, які не потребують прийняття "незрозумілих" рішень щодо захисту інформації.

У даній статті будуть розкриті ідеї ефективної інтеграції засоби шифрування інформації на диску з процесами файлової системи ОС Windows.

Перед розробниками ставилося за мету створити механізм шифрування інформації на диску, що відповідає вимогам максимальної прозорості для користувачів. Вимоги повинні будуть виконуватися за рахунок ефективної взаємодії цього механізму шифрування з процесами операційної системи Windows, які відповідають за управління файловою системою. Ефективність механізму шифрування повинна також підтверджуватися високою продуктивністю процесів шифрування і раціональним використанням ресурсів операційної системи.

Спочатку була поставлена ​​задача надавати одночасний доступ до зашифрованого і розшифрувати вмісту, а також шифрувати імена файлів. Це і породжує основні складності, тому що така вимога йде в розріз зі сформованою архітектурою Windows. Щоб зрозуміти суть проблеми, для початку нам слід розібрати деякі основні моменти даної операційної системи.

У Windows все файлові системи покладаються на такі підсистеми, як менеджер пам'яті і кеш менеджер, а менеджер пам'яті, в свою чергу, покладається на файлові системи. Здавалося б, замкнуте коло, але все стане ясно далі. Нижче, на малюнку 1, зображені перераховані компоненти, а також менеджер введення / виведення, який приймає запити від підсистем (наприклад Win32) і від інших драйверів системи. Також на малюнку використовуються терміни "фільтр" і "стек файлової системи", про що докладніше йтиметься нижче.

Малюнок 1

Сучасна операційна система це складний ієрархічної процес обробки і управління інформацією

Розберемо такий механізм, як відображення файлу на пам'ять. Суть його полягає в тому, що при доступі до віртуальної пам'яті в реальності читається частина файлу. Реалізується це за допомогою апаратних механізмів процесорів і безпосередньо самого менеджера пам'яті. Будь-які діапазони віртуальної пам'яті процесу описуються дескрипторами. Якщо для якогось діапазону немає дескриптора, значить, на цій ділянці віртуальної пам'яті нічого немає, і доступ до такого діапазону неминуче веде до краху процесу. У разі, якщо для будь-якого діапазону закріплена фізична пам'ять, доступ до цих віртуальним адресами веде до звичайного доступу до фізичної пам'яті, таку пам'ять ще називають анонімною. У разі, якщо файл відображений на віртуальну пам'ять, то при доступі за цими адресами зчитується частина файлу з диска в фізичну пам'ять, після чого доступ до неї буде виконуватися звичайним чином. Тобто ці два випадки дуже схожі, різниця лише в тому, що для останнього в відповідну фізичну пам'ять попередньо буде зчитана частина файлу. Про всі такі типи доступів дескриптор і містить інформацію. Ці дескриптори є структурами менеджера пам'яті, якими він управляє для того, щоб виконувати необхідні завдання. Як не важко здогадатися, для того, щоб вважати частину файлу в сторінку фізичної пам'яті, менеджер пам'яті повинен надіслати запит файлової системи. На малюнку 2 зображений приклад віртуальної пам'яті процесу з двома діапазонами, А і В, доступ до яких ще жодного разу не виконувався.

малюнок 2

На діапазон А відображений виконуваний файл самого процесу, а на діапазон В відображена фізична пам'ять. Тепер, коли процес виконає перший доступ до діапазону А, управління отримає менеджер пам'яті і перше, що він зробить - оцінить тип діапазону. Оскільки на діапазон А відображений файл, менеджер пам'яті спочатку вважає з файлу відповідну його частину в фізичну пам'ять, після чого відобразить її на діапазон А процесу, таким чином подальший доступ до рахувати вміст буде виконуватися вже без менеджера пам'яті. Для діапазону В менеджер пам'яті виконає таку ж послідовність, єдина різниця в тому, що замість зчитувань даних з файлу він просто відобразить вільні фізичні сторінки пам'яті на діапазон В, після чого доступ до цього діапазону буде виконуватися вже без участі менеджера пам'яті. На малюнку 3 зображено приклад віртуальної пам'яті процесу після першого доступу до діапазонів А і В.

малюнок 3

Як видно з малюнка, при доступі до обох діапазонах доступ до фізичної пам'яті виконується без участі менеджера пам'яті, тому що раніше при першому доступі він відобразив на діапазони А і В фізичну пам'ять, а в фізичну пам'ять діапазону А попередньо вважав частина відповідного файлу.

Кеш менеджер є центральним механізмом для всіх відкритих файлів в системі на всіх дисках. Використання цього механізму дозволяє не тільки прискорювати доступ до файлів, але і економити фізичну пам'ять. Кеш менеджер не працює сам по собі, на відміну від менеджера пам'яті. Він повністю управляється файловими системами, і вся необхідна інформація про файлах (наприклад, розмір) надається ними. Всякий раз, коли до файлової системи приходить запит на читання / запис, файлову систему не читає файл з диска, замість цього вона викликає сервіси кеш менеджера. Кеш менеджер, в свою чергу, користуючись сервісами менеджера пам'яті, відображає файл на віртуальну пам'ять і копіює його з пам'яті в буфер запитувача. Відповідно, при доступі до цієї пам'яті менеджер пам'яті пошле запит файлової системи. І це буде особливий запит, який буде говорити, що файл треба вважати безпосередньо з диска. Якщо виконується доступ до файлу, який раніше вже був відображений кеш менеджером, то повторно відображений на віртуальну пам'ять він не буде. Замість цього кеш менеджер буде використовувати віртуальну пам'ять, куди файл був відображений раніше. Щоб відобразити файл відстежується за допомогою структур, які файлові системи передають кеш менеджеру при виклику його сервісів. Про ці структурах трохи докладніше йтиметься нижче. На малюнку 4 наведено приклад читання файлу процесом.

малюнок 4

малюнок 4

Як показано на малюнку вище, процес виконує читання файлу в буфер В. Щоб виконати читання, процес звертається до менеджера введення / виведення, який формує і посилає запит файлової системи. Файлова система, отримавши запит, чи не зчитує файл з диска, а викликає кеш менеджер. Далі кеш менеджер оцінює, відображений чи файл на його віртуальну пам'ять, і якщо немає, то він викликає менеджер пам'яті для того щоб відобразити файл / частина файлу. В даному прикладі файл вже відображений, а доступ до нього жодного разу не виконувався. Далі кеш менеджер копіює в буфер В процесу файл, відображений на діапазон віртуальної пам'яті А. Оскільки доступ до діапазону А виконується перший раз, управління отримає менеджер пам'яті, потім він оцінить діапазон, і, оскільки це відображений на пам'ять файл, вважає його частина в фізичну пам'ять, після чого відобразить її на діапазон віртуальної пам'яті А. після цього, як вже було описано раніше, доступ до діапазону А буде виконуватися, минаючи менеджер пам'яті.

Ніщо не заважає одночасно кешувати файл і відображати його на пам'ять скільки завгодно разів. Навіть якщо файл буде закешовану і відображений на пам'ять десятків процесів, фізична пам'ять, яка використовується для цього файлу, буде одна і та ж. В цьому і полягає суть економії фізичної пам'яті. На малюнку 5 наведено приклад, де один процес читає файл звичайним чином, а інший процес відображає цей же файл на свою віртуальну пам'ять.

малюнок 5

малюнок 5

Як видно з малюнка вище, фізична пам'ять відображається на віртуальну пам'ять процесу В і віртуальну пам'ять кеш менеджера. Коли процес А виконуватиме читання файлу в буфер D, він звернеться до менеджера введення / виведення, який сформує і пошле запит файлової системи. Файлова система, в свою чергу, звернеться до кеш менеджеру, який просто скопіює файл, відображений на діапазон віртуальної пам'яті З кеш менеджера, в буфер D процесу А. Оскільки в момент звернення до кеш менеджеру файл вже був не тільки відображений, але і раніше виконувався доступ до діапазону С, на яку відображений файл, то операція буде виконана без участі менеджера пам'яті. Процес В при читанні / запису діапазону Е по суті отримає доступ до тих же самим фізичним сторінок пам'яті, до якому при копіюванні файлу отримував доступ кеш менеджер.

Файлові системи приймають запити від призначеного для користувача ПО або інших драйверів. Перед доступом файл повинен бути відкритий. У разі успішного виконання запитів відкриття / створення файлів файлова система сформує структури пам'яті, які використовуються кеш менеджером і менеджером пам'яті. Також слід зазначити, що ці структури унікальні для файлу. Тобто якщо конкретний файл диска був відкритий на той момент, коли прийшов такий же запит на цей же файл, файлова система буде використовувати раніше сформовані структури пам'яті. По суті, вони є програмним поданням файлу диска в пам'яті. На малюнку 6 наведено приклад відповідності відкритих примірників файлів і їх структур.

малюнок 6

малюнок 6

На малюнку процес А відкрив файл С і файл D, а процес B відкрив файл З два рази. Таким чином, є три відкритих примірника файлу С, коли структура, сформована файлової системою, всього одна. Файл D був відкритий один раз, отже, є один відкритий екземпляр, якому відповідав би структура, сформована файлової системою.

Будь-які запити, спрямовані до файлової системи, не відразу обробляються нею. Запити спочатку проходять по ланцюжку драйверів, які бажають відстежувати такі запити. Такі драйвера називають фільтрами. Вони мають можливість переглядати запити до того, як вони досягнуть файлової системи, а також після того, як файлова система обробить їх. Наприклад, фільтр шифрування файлів може відстежувати запити читання / запису для того, щоб розшифрувати / зашифрувати дані. Таким чином, не допрацьовує самі файлові системи, ми можемо зашифрувати дані файлу. Фільтри можуть прив'язувати свої унікальні дані до структур файлів, які формує файлова система. Разом драйвера фільтрів і драйвер файлової системи формують стек файлової системи. Кількість фільтрів може бути різним, також можуть бути різними і самі фільтри. Теоретично їх може і не бути зовсім, але практично так не буває. На малюнку 7 зображений стек файлової системи, до складу якого входять три фільтра.

малюнок 7

малюнок 7

До того, як запит досягне файлової системи, він проходить послідовно через фільтри 1, 2 і 3. Коли запит буде оброблений файлової системою, то фільтрами він видно в зворотному порядку, тобто запит проходить послідовно через фільтри 3, 2 і 1. Також, на прикладі вище фільтр 1 і фільтр 3 прив'язали свої структури до структури файлу, яку сформувала файлова система після виконання запиту відкривання / створення файлу.

Переважна більшість завдань вирішується за допомогою фільтрації, але наш випадок унікальний. Як було зазначено раніше, унікальний він тим, що потрібно надавати одночасний доступ до зашифрованого і розшифрувати вмісту, а також шифрувати імена файлів. Проте, ми спробуємо розробити фільтр, який дозволить вирішити таке завдання.

На малюнку 8 зображена ситуація, коли файл раніше був відкритий розшифрованим.

малюнок 8

Це означає, що фільтри бачили розшифроване ім'я, і ​​вони, як це зображено на малюнку, можуть прив'язати це ім'я до структури, яку сформує файлова система (як було раніше сказано, ця структура є унікальною для конкретного файлу диска) для подальших маніпуляцій з файлом. І в цей момент файл відкривається зашифрованим, що означає, що фільтри бачили зашифроване ім'я. Як вони поведуть себе в такій ситуації, коли до структури файлу вже прив'язане розшифроване ім'я? Очевидно, що поведінка не передбачувано, хоча і не обов'язково, що наслідки будуть фатальними.

В продовження описаного вище можна додати, що при доступі до вмісту файлу також виникають проблеми, і набагато більш серйозні. Повернемося до ситуації, коли файл був відкритий одночасно розшифрованих і зашифрованим. Ця ситуація зображена на малюнку 9, читання / запис файлу ще жодного разу не виконувалися.

малюнок 9

малюнок 9

Тепер уявімо собі, що прийшов запит на читання розшифрованого вмісту. Файлова система скористається послугами кеш менеджера і передасть йому структуру файлу, до якої і кеш менеджер, і менеджер пам'яті прив'яжуть свої унікальні дані для подальшого управління відображенням і кешуванням файлу. Ця ситуація зображена на малюнку 10.

малюнок 10

Далі приходить запит на читання зашифрованого вмісту, і файлову систему знову передає структуру файлу кеш менеджеру, а оскільки кеш менеджер і менеджер пам'яті раніше до цієї структури прив'язали унікальні дані для цього файлу, вони просто скористаються ними для виконання запиту. Тобто тепер в цих структурах буде вказано, куди був відображений файл, і кеш менеджер просто скопіює дані файлу з віртуальної пам'яті в буфер запитувача. Ми пам'ятаємо, що файл при першому доступі до нього був закешовану розшифрованим, таким чином при зашифрованому доступі в буфері запитувача виявляться розшифровані дані.

Ми тільки що розібрали дві фундаментальні проблеми. На практиці їх було більше. Наприклад, в рамках поставленого завдання до кожного зашифрованого файлу необхідно додавати заголовну інформацію, що теж не вирішується за допомогою фільтрації. Щоб обійти всі ці проблеми разом, було знайдено рішення - віртуальна файлова система.

Віртуальна файлова система, за своєю суттю, мало чим відрізняється від звичайної. Радикальна відмінність полягає в тому, що звичайна файлова система працює з диском, а віртуальна працює з файлами інших файлових систем, тобто є звичайним споживачем сервісів файлових систем. На малюнку 11 зображено концепція віртуальної файлової системи.

малюнок 11

На відміну від звичайних файлових систем, віртуальна файлова система не реєструє себе в системі (про це не було сказано вище, але для того щоб операційна система могла користуватися сервісами конкретної файлової системи, вона повинна зареєструватися), а раз так, то запити до неї прямувати не будуть. Щоб вирішити цю проблему, ми використовуємо фільтр для звичайної файлової системи, але на цей раз його функції будуть дуже простими і обмеженими, одна з них (і головна) - це відстеження доступу до зашифрованих файлів. Як тільки фільтр побачить такий запит, він просто перенаправляє його до віртуальної файлової системи. Якщо ж буде виконуватися доступ до звичайного файлу, запит буде переданий оригінальної файлової системи.

Тепер давайте ще раз розберемо розшифрований і зашифрований доступи, але вже в контексті віртуальної файлової системи. На малюнку 12 наведено приклад, коли виконувався доступ до розшифрувати і зашифрованого змісту конкретного файлу.

малюнок 12

малюнок 12

Ще раз представимо сітуацію, коли файл БУВ Відкритий розшифрованих. Це означає, что в процесі Виконання запиту Відкривання файлу, наш фільтр Побачив его и перенаправивши на віртуальну файлову систему. Віртуальна файлової системи, получил запит, оцінює тип доступу (розшифрованих або зашифрований), и оскількі віконується розшифрованих доступ, Віртуальна файлової системи спочатку перетворює розшифрованих имя в зашифрованістю, а после спробує Відкрити файл через рідну файлову систему з цього імені (тобто ім ' я файлу на рідній файлової системи буде зашифрованістю). У разі успіху Віртуальна файлової системи сформує Структури пам'яті, Які пізніше будут використовуват кеш менеджер и менеджер пам'яті. Тепер уявімо Собі, что файл відкрівається зашифрованістю, фільтр знову перенаправляє запит віртуальної файлової системи, що не роблячі ніякіх оцінок. Віртуальна файлова система оцінює тип доступу, а оскількі доступ зашифрований, вона просто спробує Відкрити файл через рідну файлову систему з цього імені. І знову, в разі успіху, Віртуальна файлової системи сформує Структури пам'яті для кеш менеджера и менеджера пам'яті. Альо На Відміну Від розшифрованих доступу, це будут Вже інші структури. Тепер, если файл знову буде Відкритий розшифрованих, Віртуальна файлової системи вікорістовує ті ж структури, Які сформувала при Першому розшифрованих доступі. У разі якщо файл знову буде відкриватися зашифрованим, файлова система використовує структури, які сформувала при першому зашифрованому доступі. Таким чином, ми розділили доступ до розшифрувати і зашифрованого змісту.

На малюнку 13 зображено ситуацію, коли доступ на читання / запис до розшифрувати і зашифрованого вмісту файлу жодного разу не виконувався.

малюнок 13

малюнок 13

Тепер якщо буде виконуватися розшифроване читання, віртуальна файлова система, користуючись сервісами кеш менеджера, як показано на малюнку 14, передасть йому структури пам'яті, які вона повернула при відкриванні файлу розшифрованим.

малюнок 14

Кеш менеджер відобразить файл на віртуальну пам'ять і скопіює дані в буфер запитувача. Відповідно, в процесі копіювання менеджер пам'яті пошле запит на читання віртуальної файлової системи, яка в свою чергу пошле запит на читання рідною файлової системи, а оскільки кеш менеджеру були передані структури пам'яті для розшифрованого файлу, віртуальна файлова система розшифрує дані і повідомить про завершення менеджеру пам'яті , так закешіруется розшифроване вміст. У разі якщо буде виконуватися зашифроване читання, віртуальна файлова система передасть, як зображено на малюнку 15, кеш менеджеру структури пам'яті, які вона сформувала при відкриванні файлу зашифрованим.

малюнок 15 малюнок 15

Кеш менеджер знову відобразить файл на віртуальну пам'ять (оскільки в цих структурах файл ще не відображався) і скопіює дані в буфер запитувача. І знову в процесі копіювання менеджер пам'яті пошле запит на читання віртуальної файлової системи, яка знову пошле запит на читання рідною файлової системи, а оскільки кеш менеджеру були передані структури пам'яті для зашифрованого файлу, то, що не розшифровуючи даних, віртуальна файлова система повідомить менеджеру пам'яті про завершенні. Так файл закешіруется зашифрованим.

Як ми бачимо, віртуальна файлова система вирішує фундаментальні проблеми, що не дозволяють мати одночасний доступ до розшифрувати і зашифрованого вмісту файлу, через що доводиться відмовлятися від класичних механізмів операційної системи. В процесі фільтрації ми можемо тільки додавати дані до структур пам'яті файлів, які повертає файлову систему, і, оскільки ми не формуємо ці структури, ми не можемо втручатися в них і управляти ними. А за допомогою віртуальної файлової системи ми їх повністю формуємо, і, отже, маємо повний контроль над ними, що необхідно в рамках вирішення даного завдання. Наприклад, нам потрібно забезпечувати узгодженість розшифрованого і зашифрованого умістів файлів. Уявіть собі ситуацію, коли були записані дані в розшифрований файл і дані знаходяться ще в кеші, а не на диску. І в цей момент приходить запит на читання зашифрованого вмісту файлу. У відповідь на це віртуальна файлова система вивантажить розшифроване вміст на диск і скине зашифрований кеш, що змусить кеш менеджер заново послати запит на читання віртуальної файлової системи для зашифрованого читання. В рамках фільтрації подібна завдання не вирішується в принципі.

При розробці віртуальної файлової системи доводилося стикатися з незвичайними проблемами. Почасти це викликано тим, що ми працюємо з файлами файлових систем, коли звичайні файлові системи працюють з диском. Так, наприклад, була знайдена помилка в файлової системі NTFS. Виявлялася вона в тому, що доступ до файлу X: \ $ mft \ приводив до повісанію всього доступу до диска X. В результаті дослідження було встановлено, що NTFS не звільняє механізми синхронізації для файлу $ mft, який є перечіслітеля всіх файлів диска. І відповідно, щоб знайти якийсь файл на диску, спочатку потрібно прочитати $ mft файл, доступ до якого повис. Інший приклад, який не можна назвати незвичайним, це знайдена помилка в ядрі Windows 8, в результаті якої менеджер пам'яті вважає, що структури пам'яті файлу завжди останньої версії. Через це він намагається використовувати деякі частини цієї структури, яких в дійсності може не бути. І це призводило до BSOD.

Реалізація віртуальної файлової системи значно складніше реалізації фільтра, але наявність такого механізму дає більшу гнучкість при маніпуляціях з файлами. У тому числі таку, про яку ми тільки що говорили. Хоча, на перший погляд, може здатися, що завдання тривіальна.

В результаті застосування даного підходу до шифрування були успішно реалізовані функції надання одночасного доступу програмних процесів до зашифрованого і розшифрувати вмісту, а також реалізовано шифрування імен файлів, що дозволяє забезпечити високу ступінь прозорості при реалізації криптографічного захисту інформації.

Треба відзначити, що даний підхід щодо забезпечення "прозорості" шифрування файлів в ОС Windows успішно реалізований в корпоративному продукті Secret Disk Enterprise ( "Аладдін Р.Д."), який застосовується багатьма організаціями в Росії. Це в свою чергу доводить життєздатність і перспективність застосування даної ідеї в процесі створення програм шифрування файлів на диску.

Як висновок варто відзначити, що технологічна складність файлової системи ОС Windows і відсутність стандартних механізмів вирішення завдань, подібних описуваної в даній статті, будуть завжди бути на заваді створення зручних і простих програм, що забезпечують захист інформації. В такому випадку єдиним вірним рішенням є самостійна реалізація оригінального механізму, що дозволяє обійти ці обмеження без втрати функціональності ПО.

Як вони поведуть себе в такій ситуації, коли до структури файлу вже прив'язане розшифроване ім'я?

Уважаемые партнеры, если Вас заинтересовала наша продукция, мы готовы с Вами сотрудничать. Вам необходимо заполнить эту форму и отправить нам. Наши менеджеры в оперативном режиме обработают Вашу заявку, свяжутся с Вами и ответят на все интересующее Вас вопросы.

Или позвоните нам по телефонам: (048) 823-25-64

Организация (обязательно) *

Адрес доставки

Объем

Как с вами связаться:

Имя

Телефон (обязательно) *

Мобильный телефон

Ваш E-Mail

Дополнительная информация: