Android IKEv2: сертыфікат карыстальніка і CA выконваюць розныя задачы
Адно поле даказвае, хто такі тэлефон, другое вырашае, якому шлюзу давяраць. Профіль IKEv2 у Android трымае іх асобна, бо так працуе рукапоціск.
Экран IKEv2 у Android, які просіць адначасова сертыфікат карыстальніка і сертыфікат 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 у Android прапануе кожны метад аўтэнтыфікацыі асобна, а не як адзін рэжым сертыфіката. Метад лічбавага подпісу прымае сертыфікат карыстальніка, прыватны ключ і карэнны CA сервера; іншыя прымаюць імя карыстальніка і пароль або загадзя агучаны ключ.
Чытайце гэты подпіс уважліва, бо ён і ёсць механізм вышэй. У метадзе імя/пароль няма поля для прыватнага ключа карыстальніка, а ў метадзе PSK няма поля для якара даверу шлюза, бо гэтыя метады даказваюць рознае. Устаўлены ў поле сертыфіката пароль дае профіль, які падае на IKE_AUTH з паведамленнем, што не называе ні аднаго з іх.
Дакументаваны тып прыватнага ключа для метаду лічбавага подпісу — RSA. Меню з назвай IPsec або сертыфікат не азначае падтрымку ECDSA, і профіль, пабудаваны на гэтым меркаванні, падае на API платформы яшчэ да сеткі.
Чаму аднаго публічнага сертыфіката недастаткова
Груз AUTH — подпіс над абменам, зроблены прыватным ключом кліента. Публічны сертыфікат дазваляе шлюзу праверыць подпіс, але тэлефону ён нічога не дае, бо для подпісу патрэбны ключ. Імпарт толькі .crt і пакінуты ззаду ключ — самая распаўсюджаная форма гэтага збою.
Ключавая інфраструктура Android гэта адлюстроўвае. Выбар ідэнтычнасці кліента ідзе праз KeyChain, якому патрэбны доступ да адпаведнага прыватнага ключа, а не толькі запіс сертыфіката. Пакет рэгістрацыі або працэс кіравання прыладай, што ставіць пару разам, — звычайны шлях да прыдатнай ідэнтычнасці; капіраванне файла сертыфіката ўручную звычайна не.
Такім чынам, два элементы ў профілі — гэта не набор сертыфікатаў і яго копія. Адзін — пара ключоў, якой платформа павінна ўмець падпісваць, другі — якар даверу, з якім яна параўноўвае. Правярайце іх як два асобныя факты: ці можа гэты профіль падпісваць і ці ведае ён, каму давяраць?
Якары даверу належаць праграме, а не тэлефону
Усталяваны ў сховішчы карыстальніка корань не прымушае кожную праграму Android яму давяраць: з Android 7 праграма павінна выбраць гэта праз канфігурацыю сеткавай бяспекі, а да таго выпуску ўсталяваныя карыстальнікам CA прымаліся значна шырэй. Канфігурацыя даверу можа адрознівацца ад праграмы да праграмы, і кліент VPN, які сам кіруе матэрыялам даверу, можа зусім не звяртацца да сховішча карыстальніка. Таму адзін і той жа файл CA можа працаваць у адным кліенце і выглядаць праігнараваным у другім.
Адсюль дзве мадэлі ўладання. Кіраваны сістэмай профіль выкарыстоўвае ўсталяванне сертыфікатаў прылады або рэгістрацыю адміністратара, і профіль спасылаецца на патрэбны CA. VPN, якім кіруе праграма, трымае ўласны матэрыял даверу і ўласны дакументаваны імпарт, што можа быць цалкам асобна ад экрана налад Android. Там жа рамантуюць і пашкоджаны ланцуг.
Вызначце, у якой мадэлі вы знаходзіцеся, перш чым нешта імпартаваць, а затым пацвердзіце выбар даверу актыўнага профілю. Калі інструкцыі аператара і меню кліента супярэчаць, для гэтай устаноўкі перамагае дакументаваныя паводзіны кліента, але CA ўсё адно павінен паступаць ад аператара праз канал, які вы можаце праверыць. Назва файла не доказ таго, хто яго выдаў.
Спачатку рэжым, потым файлы
Рэжым сертыфіката патрабуе пары ключоў кліента, CA-выдаўцы на баку шлюза, якара даверу для сертыфіката шлюза і чакання, якую ідэнтычнасць гэты сертыфікат павінен несці. Імя/пароль замяняе пару ключоў уліковымі данымі, але захоўвае патрабаванне даверу да шлюза. PSK замяняе абодва агульным сакрэтам і змяняе мадэль даверу, а не спрашчае яе.
Што б вы ні абралі, пакідайце звычайную праверку ўключанай. Опцыя не правяраць прыбірае тую праверку, дзеля якой існуе поле CA; яна не выпраўляе адсутны якар даверу. Тое ж датычыцца прыняцця любога сертыфіката сервера толькі таму, што злучэнне працуе і без яго.
Потым правярайце ў правільным месцы: імпартуйце матэрыял, падключыцеся адзін раз і ў дэталях злучэння пераканайцеся, што ідэнтычнасць шлюза тая, якую вы чакалі, і што профіль паведамляе менавіта той метад, які вы мелі на ўвазе. Паспяховае злучэнне з няправільным метадам — гэта канфігурацыя, якую вы яшчэ не разумееце, і яна адмовіць, калі аператар узмацніць палітыку.