Файлова система NTFS Механізм EFS

Зміст

Вступ 2

Файлова система NTFS 3
Структура NTFS на диску 3
Головна таблиця файлів 5
Захист та шифрування 7

Механізм EFS 9
Реєстрація функцій зворотного виклику 12
Перше шифрування файлу 13
Створення зв'язок ключів 14
Шифрування файлових даних 16
Схема процесу шифрування файлу через EFS 18
Процес розшифровки 19
Резервне копіювання зашифрованих файлів 21

Висновок 23

Додаток. Скорочення. 24

Список використаної літератури 25

Введення

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

Файлова система NTFS15 розроблялася спеціально для Windows 2000 іє системою корпоративного класу. Для шифрування файлів NTFSвикористовує механізм EFS7. Огляд файлової системи NTFS і механізму EFS іє метою моєї курсової роботи.

Файлова система NTFS

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

NTFS-вбудована файлова система Windows 2000. NTFS використовує
64-розрядні індекси кластерів. Це дозволяє їй адресувати томи розміромдо 16 мільярдів Гб. Однак Windows 2000 обмежує розміри томів NTFS дозначень, за яких можлива адресація 32-розрядними кластерами, тобто до
128 Тб (з використанням кластерів по 64 Кб).

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

Структура NTFS на диску

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

Розмір кластера на томі NTFS, або кластерний множник, встановлюєтьсяпри форматуванні томи командою format. Розмір кластера за умовчаннямвизначається розміром томи, але завжди містить ціле число фізичнихсекторів з дискретністю N2. Кластерний множник виражається числом байт вкластері, наприклад 512 байт, 1Кб або 2Кб.

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

NTFS адресується до конкретних місць на диску, використовуючи логічні номеракластерів (logical cluster numbers, LCN10) для цього всі кластери на томіпросто нумеруються по порядку - від початку до кінця. Для перетворення LCN вфізичну адресу на диску NTFS примножує LCN на кластерний множник іотримує байтове зсув від початку томи, сприймається інтерфейсомдрайвера диска. На дані всередині файла NTFS посилається по віртуальнимномерами кластерів (VCN17), нумеруя кластери які належать конкретномуфайлу (від 0 до m). Віртуальні номери не обов'язково повинні бути фізичнобезперервними.

Головна таблиця файлів

У NTFS всі дані, що зберігаються на томі, містяться у файлах. Зберігання всіхвидів даних у файлах дозволяє файловій системі легко знаходити іпідтримувати дані, а кожен файл може бути захищений дескриптором захисту.
Крім того, при появі поганих секторів на диску, NTFS може переміститифайли метаданих.

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

Головна таблиця файлів (MFT14) займає центральне місце в структурі
NTFS-томи. MFT реалізована як масив записів про файли. Розмір кожноїзапису фіксований і дорівнює 1 Кб. Логічно MFT містить по одному рядку накожен файл томи, включаючи рядок для самої MFT. Крім MFT на кожному томі
NTFS є набір файлів метаданих за інформацією, необхідною дляреалізації структури файлової системи.

Імена всіх файлів метаданих NTFS починаються зі знаку $, хоча ці знакиприховані. Так назва файлу MFT - $ Mft. Інші файли NTFS-томи єзвичайними файлами та каталогами.

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

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

Знайшовши запис для MFT, NTFS отримує з її атрибуту даних інформацію прозіставленні VCN і LCN і зберігає її в пам'яті. У кожній групі зберігаєтьсязіставлення VCN-LCN і довжина цієї групи - ось і вся інформація,необхідна для того, щоб знайти LCN по VCN. Ця інформація повідомляє NTFS,де на диску шукати групи, що утворюють MFT. Потім NTFS обробляє запису
MFT ще для декількох файлів метаданих і відкриває ці файли. Нарешті,
NTFS виконує операцію відновлення файлової системи і відкриваєрешту файлів метаданих. З цього моменту користувач може звертатися доданого дискового тому.

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

Ще один елемент MFT зарезервований для кореневого каталогу, що позначаєтьсяяк «». Його запис містить індекс файлів і каталогів, що зберігаються в кореніструктури каталогів NTFS. Коли NTFS вперше отримує запит на відкриттяфайлу, вона починає його пошук з запису кореневого каталогу. Відкривши файл,
NTFS зберігає файлову посилання MFT для цього файлу і тому в наступнийраз, коли знадобиться вважати або записати той же файл, зможе прямозвернутися до його записи в MFT.

NTFS реєструє розподіл дискового простору у файлі бітовоїкартки з ім'ям $ Bitmap. Атрибут даних для файлу бітової картки міститьбітову карту, кожен біт якої представляє кластер томи і повідомляє,вільний кластер або виділено.

Захист та шифрування

Захист в NTFS побудована на моделі об'єктів Windows 2000. Файли такаталоги захищені від доступу користувачів, що не мають відповіднихправ. Відкритий файл реалізується у вигляді об'єкта «файл» з дескрипторомзахисту, що зберігаються на диску як частину файлу. Перш ніж процес зможевідкрити описувач будь-якого об'єкта, у тому числі і об'єкта «файл»,система захисту Windows 2000 має переконатися, що у цього процесу євідповідні повноваження. Дескриптор захисту в поєднанні з вимогоюреєстрації користувача при вході в систему гарантує, що жоденпроцес не отримає доступу до файлу без дозволу системного адміністратораабо власника файлу.

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

NTFS підтримує механізм Encrypting File System (EFS), за допомогоюякого користувачі можуть шифрувати конфіденційні дані. EFSповністю прозорий для додатків. Це означає, що дані автоматичнорозшифровуються при читанні їх додатком, що працює під обліковим записомкористувача, який має права на перегляд цих даних, і автоматичношифруються при зміні їх авторизованим додатком.

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

EFS використовує криптографічні сервіси, що надаються Windows 2000у режимі користувача, і складається з драйвера режиму ядра,тісно інтегрованого з NTFS і DLL5-модулями режиму користувача,які взаємодіють з подсістемой1 локальної аутентифікації ікриптографічними DLL.

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

Механізм EFS

EFS використовує засоби підтримки шифрування, введені Microsoft ще в
Windows NT 4. При першому шифрування файлу EFS призначає профілюкористувача, шифрувального цей файл, криптографічну пару - закритий івідкритий ключі. Користувачі можуть шифрувати файли за допомогою Windows
Explorer; для цього потрібно відкрити діалогове вікно Властивості стосовнопотрібного файлу, натиснути кнопку Інші та встановити прапорець Шифрувативміст для захисту даних. Користувачі також можуть шифрувати файли здопомогою утиліти командного рядка cipber.Windows 2000 автоматично шифруєфайли в каталогах, позначених зашифрованими. При шифрування файлу EFSгенерує випадкове число, зване шифрувальним ключем файлу (fileencryption key, FEK8). EFS використовує FEK для шифрування вмісту файлуза більш стійкого варіанту DES3 (Data Encryption Standard) - DESX4. EFSзберігає FEK разом з самим файлом, але FEK шифрується за алгоритмом RSA -шифрування на основі відкритого ключа. Після виконання EFS цих дійфайл захищений: інші користувачі не зможуть розшифрувати дані безрозшифроване FEK файлу, а FEK вони не зможуть розшифрувати без закритогоключа користувача - власника файлу.

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

Захист FEK складна проблема, для розв'язання якої EFS використовує тучастину своєї криптографічного архітектури, яка спирається на технологіїшифрування з відкритим ключем. Шифрування FEK на індивідуальній основідозволяє кільком особам спільно використовувати зашифрований файл. EFSможе зашифрувати FEK файлу за допомогою відкритого ключа кожного користувачаі зберігати їх FEK разом з файлом. Кожен може отримати доступ до відкритогоключа користувача, але ніхто не зможе розшифрувати з його допомогою дані,зашифровані з цього ключа. Єдиний спосіб розшифровки файлаполягає у використанні операційною системою закритого ключа, якийвона. Як правило, зберігає в безпечному місці. Закритий ключ допомагаєрозшифрувати потрібний FEK файлу. Windows 2000 зберігає закриті ключі нажорсткому диску, що не дуже безпечно, але в наступних випускахопераційної системи користувачі зможуть зберігати закриті ключі накомпактних носіях на зразок смарт-карт. Алгоритми на основі відкритого ключазвичайно досить повільні. Тому вони використовується EFS тільки дляшифрування FEK. Поділ ключів на відкритий і закритий трохи спрощуєуправління ключами в порівнянні з таким в алгоритмах симетричногошифрування і вирішує дилему, пов'язану із захистом FEK.

Функціональність EFS спирається на кілька компонентів, як видно насхемою архітектури EFS (див. малюнок).

користувача режим

LPC

Режим ядра

| |
| |
| |
| |
| |
| |
| |
| |
| |

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

Підсистема локальної автентифікації (Local Security Authentication
Subsystem, Lsass13) (WinntSystem32Lsass.exe) не тільки керує сеансамиреєстрації, а й виконує рутинні операції, пов'язані з управліннямключами EFS. Наприклад, коли драйверу EFS потрібно розшифрувати FEK длярозшифровки даних файлу, до якого звертається користувач, драйвер EFSнадсилає запит Lsass через виклик локальної процедури (local procedure callабо LPC11).

Драйвер пристрою KsecDD9 (WinntSystem32DriversKsecdd.sys)експортує функції, необхідні драйверів для посилки Lpc-повідомлень
Lsass. Компонент Lsass, сервер локальної автентифікації (Local Security
Authentication Server, Lsasrv12) (WinntSystem32Lsasrv.dll), чекаєзапити на розшифровку FEK через виклик віддаленій процедури (remoteprocedure call або RPC16); розшифровка виконується відповідним
EFS. Яка також знаходиться в Lsasrv. Для розшифровки FEK, що отримується віддрайвера EFS в зашифрованому вигляді, Lsasrv використовує функції Microsoft
CryptoAPI, або скорочено CAPI1.

CAPI складається з DLL компонентів доступу до криптографічних сервісів
(шифрування, дешифруванню і хешування). Наприклад, ці DLL управляютьотриманням відкритого та закритого ключів користувача, що дозволяє Lsasrvне піклуватися про деталі захисту ключів і про осоособливостями роботи алгоритмівшифрування. Розшифрувавши FEK, Lsasrv повертає його драйверу EFS у відповідному
LPC-повідомленні. Отримавши Розшифрований FEK, EFS за допомогою DESXрозшифровує дані файлу для NTFS.

Реєстрація функцій зворотного виклику

Присутність драйвера EFS (WinntSystem32DriversEFS.sys) не єнеобхідною умовою для роботи NTFS, але без нього зашифровані файли будутьнедоступні. NTFS передбачає інтерфейс для підключення драйвера EFS,тому при ініціалізації драйвер EFS може сам підключиться до NTFS. Драйвер
NTFS експортує декілька функцій, що використовуються драйвером EFS, включаючиті, які EFS викликає для повідомлення NTFS про свою присутність іпов'язаних з ним API-функції.

Перше шифрування файлу

Виявивши незашифрований файл, драйвер NTFS викликає функції,зареєстровані EFS. Про стан шифрування файлу повідомляють його атрибути.
NTFS і EFS мають спеціальні інтерфейси для перетворення файлу знезашифрованому в зашифровану форму, але цей процес протікає в основномупід керуванням компонентів користувацького режиму. Windows 2000дозволяє шифрувати файли двома способами: утилітою командного рядка cipberабо за допомогою Windows Explorer. Windows Explorer і cipber використовують Win32 -функцію EncryptFile експортовану Advapi32.dll (Advance Win32 API DLL).
Щоб отримати доступ до API, який потрібний для LPC-виклику інтерфейсів EFS в
Lsasrv, Advapi32 завантажує іншу DLL, Feclient.dll (File Encryption Client
DLL).

Отримавши LPC-повідомлення c запитом на шифрування файлу від Feclient,
Lsasrv використовує механізм уособлення Windows 2000 для підміни собоюкористувача, що запустив програму, шифруючу файл (cipber або Windows
Explorer). Це змушує Windows 2000 сприймати файлові операції,виконувані Lsasrv, як операції, що виконуються користувачем, бажаючимзашифрувати файл. Lsasrv зазвичай працює під обліковим записом System. Якщоб Lsasrv не уособлював користувача, то не отримав би прав на доступ дошіфруемому файлу.

Далі Lsasrv створює файл журналу в каталозі System Volume Information,де реєструє хід процесу шифрування. Файл журналу, звичайно
EFS0.log, але, якщо шифрується декілька файлів, 0 замінюється числом,яке послідовно збільшується на 1, до тих пір, поки не будеотримано унікальне ім'я журналу для поточного шіфруемого файлу.

CryptoAPI покладається на інформацію для користувача профілю,що зберігається в реєстрі, тому наступний крок Lsasrv - завантаження до реєструпрофілю уособлює користувача викликом функції LoadUserProfile з
Userenv.dll (User Environment DLL). Зазвичай профіль користувача до цьогомоменту вже завантажений, оскільки Winlogon завантажує його при входікористувача в систему. Але якщо користувач реєструється під іншийобліковим записом за допомогою команди RunAS, то при спробі звернення дозашифрованого файлу під цією обліковим записом відповідний профіль можебути не завантажений.

Після цього Lsasrv генерує для файла FEK, звертаючись до засобівшифрування RSA, реалізованих в Microsoft Base Cryptographic Provider 1.0.

Створення зв'язок ключів

До цього моменту Lsasrv вже отримав FEK і може згенерувати інформацію
EFS, що зберігається разом з файлом, включаючи зашифровану версію FEK. Lsasrvзчитує з параметра реєстру HKEY_CURRENT
_USERSoftwareMicrosoftWindows
NTCurrentVersionEFSCurrentKeysCertificateHash значення, присвоєнекористувачеві, який зажадав операцію шифрування, і отримує сигнатурувідкритого ключа цього користувача. Цей розділ не з'являється в реєстрі,якщо жоден файл або каталог не зашифрований. Lsasrv використовує цюсигнатуру для доступу до відкритого ключа користувача та для шифрування FEK.

Тепер Lsasrv може створити інформацію, яку EFS збереже разом зфайлом. EFS зберігає в зашифрованому файлі тільки один блок інформації, вякому містяться записи для всіх користувачів цього файлу. Данізаписи називаються елементами ключів (key entries); вони зберігаються в областізіставлених з файлом даних EFS, яка називається Data Decryption
Field (DDF2). Сукупність декількох елементів ключів називається зв'язкоюключів (key ring), оскільки EFS дозволяє кільком особам спільновикористовувати зашифровані файл.

Формат даних EFS, зіставлених з файлом, і формат елемента ключапоказано на малюнку. У першій частині елемента ключа EFS зберігає інформацію,достатню для точного опису відкритого ключа користувача. До неї входитькористувальницький ідентифікатор захисту (SID), ім'я контейнера, в якомузберігається ключ, ім'я компонента доступу до криптографічних сервісів і хешсертифіката криптографічного пари. У другій частині елемента ключаміститься шифрована версія FEK. Lsasrv шифрує FEK через CryptoAPI поалгоритму RSA з застосуванням відкритого ключа даного користувача.

Далі Lsasrv створює ще одну в'язку ключів, що містить елементи ключіввідновлення (recovery key entries). EFS зберігає інформацію про ціелементах в полі файлу DRF6. Формат елементів DRF ідентичний формату DDF.
DRF служить для розшифровки даних користувача за певними обліковимизаписів (агентів відновлення) в тих випадках, коли адміністратору потрібендоступ до користувача даних.

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

Агенти відновлення (Recovery Agents) визначаються в політицібезпеки Encrypted Data Recovery Agents (Агенти відновленняшифрованих даних) на локальному комп'ютері або в домені. Ця політикадоступна через оснащення Group Policy (Групова політика) консолі ММС.
Можна додати агенти відновлення і вказати, які криптографічніпари (позначені їх сертифікатами) можуть використовувати ці агенти длявідновлення зашифрованих даних. Lsasrv інтерпретує політикувідновлення в процесі своєї ініціалізації або при одержанні повідомленняпро зміну політики відновлення. EFS створює DRF-елементи ключів длякожного агента відновлення, використовуючи компонент доступу докриптографічних сервісів, зареєстрований для EFS-відновлення.
Компонентом за умовчанням служить Base Cryptographic Provider 1.0.

На завершальному етапі створення інформації EFS для файлу Lsasrv обчислюєконтрольну суму для DDF і DRF за механізмом хешування MD5 з Base
Cryptographic Provider 1.0. Lsasrv зберігає обчислену контрольну суму взаголовку даних EFS. EFS посилається на цю суму при розшифровці, щобпереконатися в тому, що зіставлені з файлом дані EFS не пошкоджені і незламані.

Шифрування файлових даних

Після створення всіх даних, необхідних для шіфруемого користувачемфайлу, Lsasrv приступає до шифрування файлу і створює його резервну копію,
Efs0.tmp (якщо є інші резервні копії, Lsasrv просто збільшує номерв імені резервного файлу). Резервна копія міститься у той каталог, дезнаходиться шіфруемий файл. Lsasrv застосовує до резервної копії обмежуєдескриптор захисту, так що доступ до цього файлу можна одержати тільки пообліковий запис System. Далі Lsasrv ініціалізує файл журналу, створенийїм на першому етапі процесу шифрування і реєструє в ньому факт створеннярезервного файлу. Lsasrv шифрує вихідний файл тільки після йогорезервування.

Далі, Lsasrv посилає через NTFS драйверу пристрою EFS команду надодавання до вихідного файлу створеної інформації EFS. NTFS отримує цюкоманду, але оскільки вона не розуміє команд EFS, то просто викликаєдрайвер EFS. Драйвер EFS приймає послані Lsasrv дані EFS і застосовуєїх до файлу через функції, що експортуються NTFS. Ці функції дозволяють EFSдодати до NTFS-файлу атрибут $ LOGGED_UTILITY_STREAM. Після цьогоуправління повертається до Lsasrv, який копіює вміст шіфруемогофайлу в резервний. Закінчивши створення резервної копії (у тому числіскопіювавши всі додаткові потоки даних), Lsasrv відзначає у файліжурналу, що резервний файл знаходиться в актуальному стані. Потім Lsasrvпосилає NTFS іншу команду, вимагаючи зашифрувати вміст вихідногофайлу.

Отримавши від EFS команду на шифрування файлу, NTFS видаляє вмістпочаткового файлу і копіює в нього дані резервного. У міру копіюваннякожного розділу файлу NTFS скидає дані розділу з кеша файловоїсистеми, і вони записуються на диск. Так як файл позначений як зашифровані,
NTFS викликає EFS для шифрування розділу даних перед записом на диск. EFSвикористовує незашифрований FEK, переданий NTFS, щоб шифрувати файловідані по алгоритму DESX порціями, рівними за розміром одному сектору (512байт).

У версіях Windows 2000, дозволених до експорту за межі США, драйвер
EFS реалізує 56-бітний ключ шифрування DESX, тоді як у версії,що підлягає використанню тільки в США, довжина ключа DESX дорівнює 128 бітам.

Після того як файл зашифрований, Lsasrv реєструє у файлі журналу, щошифрування успішно завершено, і видаляє резервну копію файлу. У висновку
Lsasrv видаляє файл журналу і повертає управління з додатком,запросила шифрування файлу.

Схема процесу шифрування файлу через EFS

1. Завантажується профіль користувача, якщо це необхідно.

2. У каталозі System Volume Information створюється файл журналу з ім'ям

EFSx.log, де х - унікальне ціле число від 0. По мірі виконання наступних етапів в журнал заносяться записи, що дозволяють відновити файл після збою системи в процесі шифрування.

3. Base Cryptographic Provider 1.0 генерує для файла випадкове 128 - бітне число, що використовується як FEK.

4. Генерується або зчитується криптографічний пара ключів користувача. Вона ідентифікується в HKEY_CURRENT_USER Software

MicrosoftWindows NTCurrentVersion EFSCurrentKeys

CertificateHash.

5. Для файлу створюється зв'язка ключів DDF з елементом для даного користувача. Цей елемент містить копію FEK, закодовані за допомогою відкритого EFS-ключа користувача.

6. Для файлу створюється зв'язка ключів DRF. У ньому є елементи для кожного агента відновлення в системі, і при цьому в кожному елементі міститься копія FEK, зашифрована за допомогою відкритого EFS-ключа користувача.

7. Створюється резервний файл з ім'ям виду EFS0.tmp в тому каталозі, де знаходиться шіфруемий файл.

8. Зв'язка ключів DDF і DRFдобавляются до заголовка і зіставляються з файлом як атрибут EFS.

9. Резервний файл позначається як зашифровані, і в нього копіюється вміст вихідного файлу.

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

11. Видаляється резервний файл.

12. Видаляється файл журналу.

13. Вивантажується профіль користувача, завантажений на кроці 1.

При збої системи під час шифрування узгоджені дані неодміннозберігаються в одному з файлів - вихідному або резервному. Коли Lsasrvініціалізується після збою системи, він шукає файли журналу в каталозі
System Volume Information на кожному NTFS-томі в системі. Якщо Lsasrvзнаходить один або декілька файлів журналу, він вивчає їх вміст івизначає порядок відновлення. Якщо вихідний файл не був модифікованийна момент аварії, Lsasrv видаляє файл журналу і відповідний резервнийфайл; інакше він копіює резервний файл поверх вихідного (частковошифрованого) файлу, після чого видаляє журнал і резервну копію. Післятого як Lsasrv обробить файли журналів, файлова система повертається вцілісне стан без втрати даних користувача.

Процес розшифровки

Процес розшифровки починається, коли користувач відкриває шифрованийфайл. При відкритті файлу NTFS аналізує його атрибути і виконує функціюзворотного дзвінка, в драйвері EFS. Драйвер EFS зчитує атрибут
$ LOGGED_UTILITY_STREAM, співставлений з шифрованих файлом. Щобпрочитати цей атрибут, драйвер викликає функції підтримки EFS, які
NTFS експортує для EFS. NTFS виконує всі необхідні дії, щобвідкрити файл. Драйвер EFS перевіряє наявність у користувача, що відкриваєфайл, прав доступу до даних шифрованого файлу, тобто зашифрований FEK взв'язки ключів DDF і DRF повинен відповідати криптографічного паріключів, зіставлення з користувачем. Після такої перевірки EFS отримуєРозшифрований FEK файлу, який застосовується для обробки даних в операціях,які користувач може виконувати над файлом.

EFS не може розшифрувати FEK самостійно і покладається в цьому на
Lsasrv, який може використовувати CryptoAPI. За допомогою драйвера KsecDD.sys
EFS посилає LPC-повідомлення Lsasrv, щоб той витягнув з атрибуту
$ LOGGED_UTILITY_STREAM FEK користувача, що відкриває файл, і розшифрувавйого.

Отримавши LPC-повідомлення, Lsasrv викликає функцію LoadUserProfile з
Userenv.dll для завантаження до реєстру профілю користувача, якщо він ще незавантажений. Lsasrv перебирає всі поля ключів в даних EFS, пробуючирозшифрувати кожен FEK на основі закритого ключа користувача; з цієюметою Lsasrv намагається розшифрувати FEK в DDF або DRF елементі ключа. Якщохеш сертифіката в поле ключа не підходить до ключа користувача, Lsasrvпереходить до наступного полю ключа. Якщо Lsasrv не вдасться розшифрувати ніодного FEK в DDF або DRF, користувач не отримає FEK файлу, і EFS заборонитьдоступ до файлу з додатком, що намагалося відкрити цей файл. А якщо
Lsasrv знайде якийсь хеш, який відповідає ключу користувача,він розшифрує FEK по закритому ключу користувача через CryproAPI.

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

Шлях від драйвера EFS до Lsasrv і назад вимагає досить багато часу --в процесі розшифровки FEK в типовій системі CryptoAPI використовуєрезультати більш 2000 викликів API-функцій реєстру і 400 звернень дофайлової системи. Щоб скоротити витрати від усіх цих викликів, драйвер
EFS використовує кеш в парі з NTFS.

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

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

Резервне копіювання зашифрованих файлів

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

Для доступу до шифрованому вмісту файлів утиліти резервногокопіювання в Windows 2000 використовують новий EFS API: функції
OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw і
CloseEncryptedFileRaw. Ці функції, що надаються Advapi32.dll, викликаютьвідповідні функції Lsasrv за механізмом LPC. Наприклад, після того якутиліта резервного копіювання відкриває файл, вона викликає
ReadEncryptedFileRaw, щоб отримати дані. Lsasrv-функція EfsReadFileRawвидає керуючі команди, шіфруемие за алгоритмом DESX за допомогоюсеансового ключа EFS, драйвера NTFS для читання спочатку атрибуту EFS файлу,а потім його шифрованого вмісту.

EfsReadFileRaw може знадобитися кілька операцій читання, щобвважати великий файл. У міру того як EfsReadFileRaw зчитує черговупорцію файлу, Lsasrv посилає Advapi32.dll RPC-повідомлення, в результатіякого виконується функція зворотного виклику, зазначена програмоюрезервного копіювання при виклику ReadEncryptedFileRaw. Функція
EfsReadFileRaw передає лічені зашифровані дані функції зворотноговиклику, яка записує їх на архівний носій.

Відновлюються зашифровані файли аналогічним чином. Програмарезервного копіювання викликає API-функцію WriteEncryptedFileRaw, якаактивізує функцію зворотного виклику програми резервного копіювання дляотримання нешифрованих даних з архівного носія, у той час як Lsasrv -функція EfsWriteFileRaw відновлює вміст файлу.

Висновок

Шифрована файлова система захищає конфіденційні дані у файлах натомах NTFS. EFS - основна технологія шифрування і розшифровки файлів натомах NTFS. Відкривати файл і працювати з ним може тільки користувач, йогозашифрований. Це надзвичайно важливо для користувачів переноснихкомп'ютерів: навіть якщо зломщик дістане доступ до втраченого абовкраденому комп'ютера, він не зможе відкрити зашифровані файли. У Windows
XP шифрована файлова система також підтримує автономні файли та папки
(Offline Files and Folders).

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

Додаток. Скорочення.

Список використовуваної літератури
1. Д. Соломон, М. Руссіновіч. Внутрішній пристрій Microsoft Windows 2000.
Майстер-клас./Пер. з англ. - СПб.: Питер; М.: Видавничо-торговий дім
«Русская Редакция», 2001.
2. В. Столлінгс. Криптографія та захист мереж: принципи та практика (2-евидання)./Пер. з англ. - М.: Видавничий дім «Вільямс», 2001.
3. Баричев С. Г., Гончаров В. В., Серов Р. Е. Основи сучасноїкриптографії. - М.: Горячая линия - Телеком, 2001.
-----------------------

Компоненти доступу до криптографічних сервісів

Lsass

Lsasr

Опції EFS

Microsoft Base

Cryptographic

Provider 1.0

Додаток

KSecDD

EFS

NTFS

EFS-виклики зовнішніх функцій

Доступ до зашифрованого файлу

Поле розшифровки даних (DDF)

Поле відновлення даних (DRF)

Інформація EFS

Заголовок