Android IKEv2: кориснички сертификат и CA имају различите улоге
Једно поље доказује ко је телефон, друго одлучује ком гејтвеју веровати. Android IKEv2 профил их држи одвојено јер руковање то чини.
Екран Android IKEv2 који тражи и кориснички сертификат и CA сертификат изгледа као да исту ствар тражи двапут. Не тражи. IKEv2 проверава идентитет обе стране, у оба смера, унутар исте размене, а телефон има различиту улогу у сваком смеру: мора да докаже ко је и мора да одлучи ком гејтвеју верује. Кориснички сертификат одговара на прво питање, поуздан CA на друго, и ниједно не може заменити оно друго.
Два смера провере идентитета у једној размени
IKEv2 успоставља контролни канал у две фазе. Прва размена преговара алгоритме и кључеве; друга, IKE_AUTH, носи по један AUTH payload са сваке стране заједно са идентитетом сваке стране. Payload је потпис или 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-у
Google-ов градитељ IKEv2 профила излаже сваки метод провере одвојено, а не као један режим сертификата. Метод дигиталног потписа узима кориснички сертификат, приватни кључ и коренски CA сервера. Остали методи узимају корисничко име и лозинку или унапред дељени кључ.
Прочитајте тај потпис пажљиво, јер кодира горњи механизам. Нема поља за корисников приватни кључ у методу корисничко име и лозинка, ни поља за гејтвејову сидрену тачку поверења у PSK методу, из простог разлога што ти методи доказују различите ствари. Њихово мешање убацивањем лозинке у поље сертификата даје профил који пада на IKE_AUTH са поруком која не именује ниједан.
Документовани тип приватног кључа за метод дигиталног потписа је RSA. Мени означен као IPsec или сертификат не подразумева подршку за ECDSA, а профил састављен на претпоставци да је има пашће на API-ју платформе пре него што мрежа уопште буде укључена.
Зашто само јавни кориснички сертификат није довољан
AUTH payload је потпис над разменом, направљен клијентовим приватним кључем. Поседовање јавног сертификата омогућава гејтвеју да провери потпис; телефону не помаже, јер му је кључ потребан да би потпис направио. Увоз само .crt и остављање кључа за собом најчешћа је верзија ове грешке.
Инфраструктура кључева у Android-у то одражава. Избор клијентског идентитета иде кроз KeyChain, који захтева приступ одговарајућем приватном кључу, не само ставци сертификата. Пакет за упис или ток управљања уређајима који пар инсталира заједно уобичајен је начин да се добије употребљив идентитет; ручно копирање датотеке сертификата то обично није.
Две ставке у профилу нису дакле свежањ сертификата и његов дупликат. Једна је пар кључева којим платформа мора да уме да потписује, друга је сидрена тачка поверења са којом платформа пореди. Проверите их као две одвојене чињенице: може ли овај профил да потпише и зна ли коме да верује?
Сидрене тачке поверења припадају апликацији, не телефону
Инсталирање коренског сертификата у корисничко складиште не чини да му свака Android апликација верује: од Android 7 апликација мора да се пријави кроз конфигурацију мрежне безбедности, а пре тог издања CA инсталирани од корисника прихватани су много шире. Конфигурација поверења апликација може да се разликује, а VPN клијент који управља сопственим материјалом поверења можда никада не погледа корисничко складиште. Зато исти CA фајл може да ради у једном клијенту, а у другом изгледа занемарен.
Следе два модела власништва. VPN профил којим управља систем користи инсталацију сертификата уређаја или ток уписа администратора, а профил затим референцира предвиђени CA. VPN којим управља апликација чува сопствени материјал поверења и користи сопствени документовани увоз, који може бити потпуно одвојен од екрана подешавања Android-а. Ту се и поправља прекинут ланац: у CA складишту и избору профила за случај који управља систем, на сопственом екрану за увоз клијента за случај који управља апликација.
Одлучите у ком моделу сте пре него што било шта увезете, затим потврдите избор поверења активног профила. Ако се упутства оператера и мени клијента не слажу, за ту инсталацију важи документовано понашање клијента, али CA и даље мора доћи од оператера кроз канал који можете проверити. Име датотеке није доказ о томе ко ју је издао.
Изаберите режим, затим датотеке
Режим сертификата захтева пар кључева клијента, CA која издаје на страни гејтвеја, сидрену тачку поверења за гејтвејов сертификат и очекивање који идентитет тај сертификат мора да носи. Режим корисничко име и лозинка замењује пар кључева клијента акредитивима, али задржава захтев за поверењем у гејтвеј. PSK режим замењује оба заједничком тајном и мења модел поверења уместо да га поједностави.
Шта год да изаберете, оставите нормалну проверу укључену. Опција не верификуј, где је клијент нуди, уклања проверу због које поље CA постоји; не поправља недостајућу сидрену тачку поверења. Исто важи за прихватање било ког серверског сертификата зато што веза ради без њега.
Затим проверите на правом месту: увезите материјал, повежите се једном и у детаљима везе клијента потврдите да је идентитет гејтвеја онај који сте очекивали и да профил пријављује метод провере који сте намеравали да користите. Успешна веза са погрешно изабраним режимом је конфигурација коју још не разумете и пашће када оператер следећи пут заоштри политику.