Канонічне пояснення шифрування Android та вразливості

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

Я деякий час намагаюся зрозуміти процес шифрування Android та його вразливості

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

• Що захищає шифрування зефіру?
• Чи повне шифрування пристрою захищає мої дані від Google та уряду?
• /android/137334/if-we-encrypt-our-device-can-user-connecting-to-adb-get-it
• Питання, що стосуються шифрування SD-карти
• андроїд-шифрування, коли телефон увімкнено
• android-cyanogenmod-encryption-vs-gnu
• є-там-криптографічний матеріал-в-телефонах-sim-карта-що-можна використовувати-з-rsa
• андроїд-пристрій-шифрування

Моє розуміння (чи непорозуміння?)

1. Пароль шифрування генерується за допомогою комбінації PIN-коду екрану блокування користувача та алгоритму шифрування (в ньому полягає вроджена слабкість через обмежену довжину PIN-коду)
2. Це солоне і зберігається в кореневому розташуванні, недоступному для користувачів
3. Він використовується для створення фактичного пароля для шифрування / дешифрування, а фактичний пароль зберігається в оперативній пам'яті
4. Це було посилено шляхом підключення крок 1 до пристрою SoC ( яка версія Android? Який апаратний елемент, який однозначно ідентифікує пристрій? Чи можна його замінити на підробку? )
5. Отже, неможливо розшифрувати дані без ключа шифрування та пристрою (справедливо і для зовнішньої SD)
6. Можливі методи відновлення - груба сила, захоплення інформації про ОЗУ (крок 3) для отримання ключа
7. Укорінені пристрої здаються більш чутливими до доступу до даних кроку 2 через користувальницьке відновлення / можливо ПЗУ та мигання ядра ?? ( якщо це правда, чому це не сприймається як великий ризик? )
8. Навіть якщо ця інформація отримана, я здогадуюсь, що генерувати фактичний пароль потрібно нетривіально
9. Зефір може розглядати зовнішній SD як "внутрішній накопичувач" або "портативний накопичувач". За логікою, це не повинно змінити значення, але я не впевнений

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

Отже, я шукаю канонічне пояснення для розуміння з точки зору користувача

• Весь процес шифрування (включаючи зовнішній SD)

• Варіант впровадження для всіх версій Android - від KitKat до Marshmallow (включаючи подвійні варіанти зовнішньої SD у Marshmallow)

• Уразливості на рівні користувача

Примітка

• Мені відомо про ризик того, що питання вважається занадто широким, але ІМО вимагає комплексного лікування

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

• Можливою перевагою може бути «дублювання» майбутніх питань щодо пов'язаних аспектів

• Ціною повторення відповіді мають бути насамперед на рівні користувача , але з адекватним поясненням для глибшого розуміння. Розбиття відповіді на дві частини може бути підходящим способом.

• Я б сказав про те, щоб відмовитись від тривіальних / випадкових / латкових відповідей на роботу, щоб заохотити вичерпні відповіді

Я припускаю, що це працює так:

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

Велика хитрість тут полягає в тому, що асинхронне шифрування головного ключа. Після того, як Android має головний ключ, він має можливість обмінюватися даними зі сховищем даних. Тільки після входу користувача цей головний ключ відомий. Асинхронне шифрування - це те, що називається шифруванням відкритого ключа. Що відбувається - відкритий ключ шифрує дані (головний ключ у цьому випадку), а приватний ключ дешифрує дані. Тут не слід плутати шифрування пам’яті. Зберігання - це просто синхронне шифрування. Там той самий ключ використовується для шифрування та дешифрування. Але пошук / пошук цього "головного" ключа - це biggie. Це означає, що якщо в один момент у вас є слабкий метод входу, як, наприклад, intance "1234" як пінкод, і ви передумаєте, і pincode зміниться на "5364", що важче здогадатися, якщо це не раніше "1234 " його вкрали, прокрали, у будь-який момент безпека просто покращилася. Те ж саме, коли змінюється метод входу на повний пароль, який неможливо здогадатися або атакувати словник. Сам сховище взагалі не потрібно перешифровувати. Вся справа в тому, щоб приховати цей головний ключ - внутрішньо. Користувач ніколи не бачить цього головного ключа, оскільки це, швидше за все, просто випадковий хеш-код сортів - нічого не знайде і не вгадає цей хеш-код. Навіть АНБ або будь-який інший орган безпеки на планеті ніколи не міг знайти відповідний ключ. Єдиний вектор атаки сподівається на слабкість з боку користувача. Можливо, користувач обрав логін для пінкоду. Якщо це 4 цифри, то це максимум 10000 можливих пінкодів. ОС може «заблокувати» пристрій після декількох спробу за короткий час. Вирішення полягає в тому, щоб "зламати" ОС, так що стає можливим спробувати всі можливі пінкоди, не втручаючи і не блокуючи пристрій ОС. Я вважаю, що саме таким чином ФБР отримало доступ до телефону злочинця. Стосовно третьої компанії (якась ізраїльська компанія, наскільки я пам’ятаю) зробила хакерство для ФБР, я думаю. Вони обійшли цю межу спробувати pincode. Якщо логін - це повний пароль, і якщо користувач вибрав надійний пароль, ви вирішите. Ні в один із життєвих часів з усією потужністю процесора на планеті не зламається це через мільйон років. Я не купую жоден з АНБ, може розшифрувати будь-які чутки. Я думаю, що ці люди дивилися один занадто багато фільмів, що перебувають у чорному. Все, що потрібно зробити, - це подивитися наукові документи про різні алгоритми шифрування (наприклад, AES), і ви будете знати, що злому просто не відбудеться, за винятком старих часів, коли було 40 бітових ключів. Ті дні давно минули. Я думаю, що AES128 вже не працює, і якщо когось це хвилює, стрибок на AES256 робить його більш безпечним на величину до розміру Всесвіту. Можливо, одного дня квантові комп'ютери можуть це розшифрувати, але я скептично ставлюсь. Не впевнені, чи можна мати систему ймовірностей, просто виділіть рішення. Про це ми зрештою побачимо. Можливо, це все одно за кілька днів життя. Зараз нема про що турбуватися.

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

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

Як правило, після того, як ваш пристрій розшифрує файли (файли), до них можна отримати прямий доступ за допомогою процесу з привілеями Super User. Цей процес може отримати доступ до вашого пристрою, використовуючи слабкість у самому ПЗУ (ОС Android). (Це було нещодавно в новинах, оскільки деякі недоліки були викриті WikiLeaks)

Укорінені пристрої здаються більш чутливими до доступу до даних кроку 2 через користувальницьке відновлення / можливо ПЗУ та мигання ядра ?? (якщо це правда, чому це не сприймається як великий ризик?)

Перед початком роботи root : для кореневого використання пристрою ви повинні використовувати зовнішні інструменти, всі з яких мають глибокий доступ до внутрішньої структури пристрою. Деякі з цих інструментів попередньо складені та не є відкритим кодом. У них є "офіційні" веб-сайти, але хто ці люди? (twrp.me, supersu.com, наприклад, але є такі, як KingoRoot) Чи можемо ми їм справді довіряти? Я довіряю деяким більше, ніж іншим. Наприклад, KingoRoot встановив програму на моєму ПК, яка вела себе вірусоподібно (для її видалення довелося використовувати подвійний завантажувач).

Після того, як ви отримаєте корінь : надання компільованій програмі (APK) доступу до СУ означає, що він може робити все, що завгодно, без обмежень або вказуючи, який Намір він буде використовувати. (Цілі є способом доступу APK до таких речей, як WiFi, камера тощо). Отже, "надійний додаток" після доступу до кореневого доступу може легко отримати доступ до будь-якої інформації та відправити її назад на свій сервер.

Чи повне шифрування пристрою захищає мої дані від Google та уряду?

Google - так. У ньому немає ключа для розблокування.

Уряд (або хакер) - ні. тому що уряд чи хакер можуть по суті використовувати подвиг, який перехопить файли (файли), як я вже згадував вище.

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

Редагувати: Варто зазначити, що Google насправді має можливість завантажувати та встановлювати / оновлювати додатки на ваш Android-пристрій, не запитуючи дозволу або навіть сповіщати про те, що оновлення відбулося. І навіть на вкоріненому пристрої, здається, не існує способу блокувати це, не втрачаючи ключових функцій (Play Store, Maps, Sync тощо).