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 പ്രൊഫൈൽ ബിൽഡർ എന്താണ് ആവശ്യപ്പെടുന്നത്
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 ഫീൽഡ് ഉള്ളതിന്റെ കാരണമായ പരിശോധന നീക്കുന്നു; കാണാത്ത വിശ്വാസ അടിത്തറ അത് നന്നാക്കുന്നില്ല. കണക്ഷൻ അതില്ലാതെ പ്രവർത്തിക്കുന്നു എന്ന കാരണത്താൽ ഏതെങ്കിലും സെർവർ സർട്ടിഫിക്കറ്റ് സ്വീകരിക്കുന്നതിനും ഇതേ മറുപടി.
പിന്നീട് ശരിയായ സ്ഥലത്ത് പരിശോധിക്കുക: വസ്തുക്കൾ ഇറക്കുമതി ചെയ്യുക, ഒരിക്കൽ കണക്ട് ചെയ്യുക, കണക്ഷൻ വിശദാംശങ്ങളിൽ ഗേറ്റ്‌വേ ഐഡന്റിറ്റി നിങ്ങൾ പ്രതീക്ഷിച്ചതാണെന്നും പ്രൊഫൈൽ നിങ്ങൾ ഉദ്ദേശിച്ച രീതി റിപ്പോർട്ട് ചെയ്യുന്നുവെന്നും സ്ഥിരീകരിക്കുക. തെറ്റായ രീതിയിൽ വിജയിച്ച കണക്ഷൻ നിങ്ങൾ ഇനിയും മനസ്സിലാക്കാത്ത കോൺഫിഗറേഷനാണ്, ഓപ്പറേറ്റർ നയം കർശനമാക്കുമ്പോൾ അത് പരാജയപ്പെടും.