Файловая система 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 генерує випадкове число, зване шифрувальним ключем файла (file encryption 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 через виклик віддаленій процедури (remote procedure 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 АПІ DLL). Щоб самому отримати доступом до АПІ, потрібного для LPC-вызова інтерфейсів EFS в Lsasrv, Advapi32 завантажує іншу DLL, Feclient. dll (File Encryption Client DLL).

Отримавши LPC-сообщение з запитом на шифрування файла від 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 служить для розшифровки користувальних даних із певним облікованим записів (агентів відновлення) у випадках, коли адміністратору потрібен доступом до користувальницьким данным.

|Пользовательский SID | |(S-1−5-21-…) | |Ім'я контейнера | |(ее341−2144−55ba…) | |Ім'я компонента доступу | |(Microsoft Base | |Cryptographic Provider | |1.0) | |Хэш сертифіката EFS | |(cb3e4e…) | |Зашифрований FEK | |(03fe4f3c…) | |Версія | |Контрольна сума | |Кількість елементів ключів | |DDF | |DDF-элемент ключа 1 | |DDF-элемент ключа 2 | |Кількість елементів ключів | |DRF | |DRF-элемент ключа 1 |.

Припустимо, співробітник компанії використовував 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, де x — унікальне ціла кількість від 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 використовує результати понад 2.000 викликів API-функций реєстру і 400 інтерпретацій файлової системі. Щоб скоротити витрати від цих викликів, драйвер EFS використовує кеш разом з NTFS.

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

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

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

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

Для доступу до шифрованному вмісту файлів утиліти резервного копіювання в Windows 2000 використовують новий EFS АПІ: функції 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 надає нові можливості спільного використання зашифрованих файлів чи відключення агентів відновлення даних, і навіть полегшує управління у вигляді груповий політики і службових програм командної строки.

Додаток. Скорочення. [pic] Список використовуваної літератури 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.

Заголовок.