Android IKEv2: گواهی کاربر و CA دو کار متفاوت انجام می‌دهند
یک فیلد ثابت می‌کند گوشی کیست و دیگری تعیین می‌کند به کدام دروازه می‌توان اعتماد کرد. نمایه IKEv2 اندروید این دو را جدا نگه می‌دارد.
صفحه 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 |
سازنده نمایه اندروید چه می‌خواهد
سازنده نمایه IKEv2 در اندروید هر روش تأیید را جداگانه عرضه می‌کند، نه به‌صورت یک حالت گواهی. روش امضای دیجیتال گواهی کاربر، کلید خصوصی و CA ریشه سرور را می‌گیرد؛ روش‌های دیگر نام کاربری و گذرواژه یا کلید از پیش هم‌رسانی‌شده را.
آن امضا را دقیق بخوانید، چون همان سازوکار بالاست. در روش نام کاربری و گذرواژه هیچ فیلدی برای کلید خصوصی نیست و در روش PSK هیچ فیلدی برای لنگر اعتماد دروازه، چون این روش‌ها چیزهای متفاوتی را ثابت می‌کنند. چسباندن گذرواژه در فیلد گواهی نمایه‌ای می‌سازد که در IKE_AUTH شکست می‌خورد و پیام هیچ‌یک از آن دو را نام نمی‌برد.
نوع کلید خصوصی مستند برای روش امضای دیجیتال RSA است. منویی با برچسب IPsec یا گواهی به معنای پشتیبانی از ECDSA نیست و نمایه‌ای که بر این گمان ساخته شود پیش از ورود شبکه در API سکو شکست می‌خورد.
چرا گواهی کاربر عمومی کافی نیست
بار AUTH امضایی روی تبادل است که با کلید خصوصی کارخواه ساخته می‌شود. گواهی عمومی به دروازه اجازه проверه امضا را می‌دهد، اما برای گوشی کاری نمی‌کند، چون گوشی برای ساختن امضا به کلید نیاز دارد. وارد کردن تنها .crt و جا گذاشتن کلید رایج‌ترین شکل این خطاست.
زیرساخت کلید اندروید همین را بازمی‌تاباند: انتخاب هویت کارخواه از KeyChain می‌گذرد که به کلید خصوصی متناظر نیاز دارد، نه فقط یک ورودی گواهی. بسته ثبت‌نام یا گردش کار مدیریت دستگاه که این جفت را با هم نصب می‌کند راه معمول رسیدن به هویتی قابل استفاده است؛ رونوشت دستی فایل معمولاً نه.
پس دو قلم درون نمایه یک بسته گواهی و رونوشت آن نیستند. یکی جفت کلیدی است که سکو باید با آن امضا کند و دیگری لنگر اعتمادی است که با آن مقایسه می‌کند. آن‌ها را دو واقعیت جدا بدانید: آیا این نمایه می‌تواند امضا کند و آیا می‌داند به چه کسی اعتماد کند؟
لنگرهای اعتماد از آن برنامه‌اند، نه گوشی
نصب یک ریشه در مخزن کاربر باعث نمی‌شود هر برنامه اندروید به آن اعتماد کند: از Android 7 به بعد برنامه باید این را از طریق پیکربندی امنیت شبکه خود انتخاب کند و پیش از آن نسخه، CA های نصب‌شده توسط کاربر بسیار گسترده‌تر پذیرفته می‌شدند. پیکربندی اعتماد می‌تواند میان برنامه‌ها متفاوت باشد و کارخواه VPN که مواد اعتماد خود را خودش مدیریت می‌کند شاید هرگز به مخزن کاربر نگاه نکند. به همین دلیل یک فایل CA می‌تواند در یک کارخواه کار کند و در دیگری نادیده گرفته شود.
دو الگوی مالکیت از این‌جا برمی‌آید. نمایه‌ای که سیستم مدیریت می‌کند از نصب گواهی دستگاه یا ثبت‌نام مدیر استفاده می‌کند و سپس به CA مورد نظر ارجاع می‌دهد. VPN ای که برنامه مدیریت می‌کند مواد اعتماد و ورود مستند خودش را نگه می‌دارد که می‌تواند کاملاً از صفحه تنظیمات اندروید جدا باشد. همان‌جا هم زنجیره شکسته تعمیر می‌شود.
پیش از وارد کردن هر چیز، تصمیم بگیرید در کدام الگو هستید و سپس انتخاب اعتماد نمایه فعال را تأیید کنید. اگر دستورهای اپراتور و منوی کارخواه هم‌خوان نباشند، برای آن نصب رفتار مستند کارخواه برنده است، اما CA باید همچنان از اپراتور و از مسیری بیاید که بتوانید آن را بررسی کنید. نام فایل مدرکی بر صادرکننده آن نیست.
نخست حالت، سپس فایل‌ها
حالت گواهی به جفت کلید کارخواه، CA صادرکننده در سمت دروازه، لنگر اعتماد برای گواهی دروازه و انتظاری از هویتی که آن گواهی باید داشته باشد نیاز دارد. نام کاربری و گذرواژه جفت کلید را با اعتبارنامه جایگزین می‌کند اما شرط اعتماد به دروازه را نگه می‌دارد. PSK هر دو را با یک راز مشترک جایگزین می‌کند و الگوی اعتماد را تغییر می‌دهد، نه ساده‌تر.
هر کدام را برگزینید، اعتبارسنجی معمول را روشن بگذارید. گزینه بدون بررسی همان کنترلی را برمی‌دارد که فیلد CA برای آن وجود دارد؛ لنگر اعتماد غایب را درست نمی‌کند. همین برای پذیرفتن هر گواهی سرور صادق است، چون اتصال بدون آن هم کار می‌کند.
سپس در جای درست بررسی کنید: مواد را وارد کنید، یک بار وصل شوید و در جزئیات اتصال تأیید کنید که هویت دروازه همان است که انتظار داشتید و نمایه همان روشی را گزارش می‌دهد که در نظر داشتید. اتصال موفق با روش نادرست پیکربندی‌ای است که هنوز نمی‌فهمید و هنگامی که اپراتور سیاستی را سخت‌تر کند شکست می‌خورد.