په Android کې د IKEv2 سکرین چې یو ځای د کارن سند او د CA سند غواړي، داسې ښکاري چې یو شی دوه ځله غواړي. خو داسې نه ده. IKEv2 په یوه تبادله کې دواړه خواوې په دواړو لورو تصدیقوي، او ټیلیفون په هر لوري کې بېلابېل رول لري: باید ثابت کړي چې څوک دی او پرېکړه وکړي چې کوم ګېټوې ته باور لري. د کارن سند لومړي پوښتنې ته ځواب وایي، باوري CA دویمې ته، او هیڅ یو بل نه بدلوي.

په یوه تبادله کې د تصدیق دوه لوري

IKEv2 د کنټرول چینل په دوو پړاوونو کې جوړوي. لومړی پړاو د الګوریتمونو او کیليو په اړه خبرې کوي؛ دویم، IKE_AUTH، له هرې خوا څخه یو AUTH بار د هغې د هویت سره راوړي. بار د تبادلې پر سر جوړ شوی لاسلیک یا MAC دی او د هغه شي په وړاندې ګوري چې ترلاسه کوونکی لا باور لري.

ګېټوې ځان په خپل سند ثابتوي، او ټیلیفون لړۍ تر هغې ریښې پورې ګوري چې مني یې او کتنه کوي چې په سند کې هویت له هغې ګېټوې سره سمون لري چې رسېدل ورته غوښتل؛ ټیلیفون ځان په خپلو اسنادو ثابتوي، او ګېټوې هغه د هغې CA په وړاندې ګوري چې د مراجع سند یې صادر کړی.

دا د دوو ډګرونو شاته ټول میکانیزم دی. د کارن سند د ټیلیفون خپله اعلامیه ده؛ د CA ډګر اعلامیه ده چې پر چا به باور وکړي. پروفایل چې یو یې لري او بل نه، متقابل تصدیق نه شي بشپړولای، او بیا هڅه کول یې نه بدلوي. حتی ناکامۍ بېلابېلې ښکاري: پرته له کارن کیلي ټیلیفون لاسلیک نه شي کولای، او پرته له باور لنګر د ګېټوې سند نه شي منلای.

MaterialRoleWhat it cannot do
User certificate plus its private keyProves possession of the enrolled client identityEstablish that the gateway is the right one
Trusted CA certificateValidates the gateway chain under the intended identity checksProve the client's identity to the gateway
Expected gateway identityPins which server the phone acceptsGrant that user access to every private resource

د Android د پروفایل جوړوونکی څه غواړي

په Android کې د IKEv2 د پروفایل جوړوونکی هره تصدیق طریقه جلا وړاندې کوي، نه د یو سند د حالت په توګه. د ډیجیټل لاسلیک طریقه د کارن سند، خصوصي کیلي او د سرور ریښه 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 ډګر د هغې لپاره دی؛ نیمګړی باور لنګر نه جوړوي. همدا د هر سرور سند منلو لپاره هم صدق کوي، ځکه اړیکه پرته له هغه کار کوي.

بیا په سم ځای کې تایید کړئ: توکي دننه کړئ، یو ځل وصل شئ، او د اړیکې په تفصیلاتو کې تایید کړئ چې د ګېټوې هویت هغه دی چې تمه یې لرله او پروفایل هغه طریقه ښیي چې تاسو یې نیت درلود. په ناسمه طریقه بریالۍ اړیکه هغه ترتیب دی چې لا یې نه پوهېږئ، او کله چې چلونکی تګلاره کلکه کړي ناکامېږي.

اړوندې مقالې