Android IKEv2: сертифікат користувача й CA виконують різні завдання
Одне поле доводить, ким є телефон, інше вирішує, якому шлюзу довіряти. Профіль Android IKEv2 тримає їх окремо, бо рукостискання робить саме так.
Екран Android IKEv2, який просить і сертифікат користувача, і сертифікат CA, виглядає так, ніби хоче того самого двічі. Це не так. IKEv2 автентифікує обидві сторони, в обох напрямках, у межах одного обміну, і телефон відіграє різну роль у кожному напрямку: він має довести, ким є, і має вирішити, якому шлюзу вірить. Сертифікат користувача відповідає на перше питання, довірений CA на друге, і жоден не може замінити інший.
Два напрямки автентифікації в одному обміні
IKEv2 встановлює керівний канал у дві фази. Перший обмін узгоджує алгоритми й ключі; другий, IKE_AUTH, несе по одному AUTH-навантаженню з кожного боку разом з ідентичністю кожного боку. Навантаження це підпис або MAC, обчислений над обміном, і він перевіряється щодо чогось, чому отримувач уже довіряє.
Шлюз доводить свою ідентичність власним сертифікатом, а телефон перевіряє ланцюг цього сертифіката до кореня, якому готовий довіряти, потім перевіряє, що ідентичність у сертифікаті збігається зі шлюзом, якого він мав намір досягти. Телефон доводить свою ідентичність власним обліковим даним, а шлюз перевіряє його щодо CA, який видав сертифікат клієнта.
Це весь механізм за двома полями. Сертифікат користувача це твердження, яке телефон робить про себе; поле CA це твердження про те, кому телефон віритиме. Профіль, що має одне без іншого, не може завершити взаємну автентифікацію, і жодна кількість повторів це не змінить. Ці дві невдачі навіть виглядають по-різному: відсутній ключ користувача не дає телефону створити підпис узагалі, а відсутній якір довіри не дає прийняти сертифікат шлюзу.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Що вимагає конструктор профілю в Android
Конструктор профілю IKEv2 від Google показує кожен метод автентифікації окремо, а не як єдиний режим сертифіката. Метод цифрового підпису бере сертифікат користувача, приватний ключ і кореневий CA сервера. Інші методи беруть ім'я користувача й пароль або заздалегідь спільний ключ.
Читайте цей підпис уважно, бо він кодує механізм вище. Немає поля для приватного ключа користувача в методі з іменем користувача й паролем, і немає поля для якоря довіри шлюзу в методі PSK, з простої причини: ці методи доводять різні речі. Їх змішування вставленням пароля в поле сертифіката дає профіль, який падає на IKE_AUTH із повідомленням, що не називає жодного з них.
Документований тип приватного ключа для методу цифрового підпису це RSA. Меню з позначкою IPsec або сертифікат не означає підтримку ECDSA, і профіль, зібраний на припущенні, що вона є, зазнає невдачі в API платформи ще до того, як мережа буде задіяна.
Чому самого публічного сертифіката користувача недостатньо
AUTH-навантаження це підпис над обміном, зроблений приватним ключем клієнта. Наявність публічного сертифіката дає шлюзу змогу перевірити підпис; для телефона це нічого не робить, бо йому потрібен ключ, щоб створити підпис. Імпорт лише .crt і залишення ключа позаду найпоширеніша версія цієї невдачі.
Інфраструктура ключів Android це відображає. Вибір ідентичності клієнта відбувається через KeyChain, що потребує доступу до відповідного приватного ключа, а не лише запису сертифіката. Пакет реєстрації або робочий процес керування пристроєм, який встановлює пару разом, звичайний спосіб отримати придатну ідентичність; ручне копіювання файлу сертифіката зазвичай ні.
Отже, два елементи в профілі це не набір сертифікатів і його копія. Один це пара ключів, якою платформа має вміти підписувати, другий якір довіри, з яким платформа порівнює. Перевіряйте їх як два окремі факти: чи може цей профіль підписувати і чи знає він, кому довіряти?
Якорі довіри належать застосунку, а не телефону
Встановлення кореневого сертифіката в сховище користувача не змушує кожен застосунок Android довіряти йому: від Android 7 застосунок має долучитися через свою конфігурацію мережевої безпеки, а до цього випуску CA, встановлені користувачем, приймалися значно ширше. Конфігурація довіри застосунків може відрізнятися, і VPN-клієнт, що керує власним матеріалом довіри, може взагалі не заглядати в сховище користувача. Ось чому той самий файл CA може працювати в одному клієнті й виглядати знехтуваним в іншому.
Звідси дві моделі володіння. Профіль VPN, яким керує система, використовує встановлення сертифікатів пристрою або процес реєстрації адміністратора, і профіль потім посилається на передбачений CA. VPN, яким керує застосунок, тримає власний матеріал довіри й використовує власний документований імпорт, який може бути цілком окремим від екрана налаштувань Android. Там же ви ремонтуєте розірваний ланцюг: у сховищі CA і виборі профілю для випадку з керуванням системою, на власному екрані імпорту клієнта для випадку з керуванням застосунком.
Вирішіть, у якій моделі ви перебуваєте, перш ніж щось імпортувати, потім підтвердьте вибір довіри активного профілю. Якщо інструкції оператора й меню клієнта розходяться, для цієї інсталяції переважає документована поведінка клієнта, але CA все одно має надходити від оператора через канал, який ви можете перевірити. Назва файлу не є доказом того, хто його видав.
Спершу виберіть режим, потім файли
Режим сертифіката потребує пари ключів клієнта, CA, що видає, на боці шлюзу, якоря довіри для сертифіката шлюзу й очікування, яку ідентичність цей сертифікат має нести. Режим імені користувача й пароля замінює пару ключів клієнта обліковими даними, але зберігає вимогу довіри до шлюзу. Режим PSK замінює обидва спільним секретом і змінює модель довіри, а не спрощує її.
Хоч би що ви обрали, залишайте звичайну перевірку ввімкненою. Опція не перевіряти, де клієнт її пропонує, прибирає перевірку, для якої існує поле CA; вона не виправляє відсутній якір довіри. Те саме стосується прийняття будь-якого серверного сертифіката лише тому, що з'єднання працює без нього.
Потім перевірте в правильному місці: імпортуйте матеріал, підключіться один раз і в подробицях з'єднання клієнта підтвердьте, що ідентичність шлюзу саме та, яку ви очікували, і що профіль повідомляє метод автентифікації, який ви мали намір використати. Успішне з'єднання з неправильно вибраним режимом це конфігурація, якої ви ще не розумієте, і вона зазнає невдачі наступного разу, коли оператор посилить політику.