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 ક્ષેત્ર જે તપાસ માટે છે તેને દૂર કરે છે; ગુમ થયેલું વિશ્વાસ એન્કર સુધારતો નથી. જોડાણ તેના વગર ચાલે છે એટલે કોઈપણ સર્વર પ્રમાણપત્ર સ્વીકારવા વિશે પણ એ જ વાત લાગુ પડે છે.
પછી યોગ્ય જગ્યાએ ચકાસો: સામગ્રી આયાત કરો, એક વાર જોડાઓ, અને ક્લાયન્ટની જોડાણ વિગતોમાં ખાતરી કરો કે ગેટવેની ઓળખ તમે અપેક્ષા રાખતા હતા તે જ છે અને પ્રોફાઇલ તમે ઇચ્છતા હતા તે પદ્ધતિ જ બતાવે છે. ખોટી પદ્ધતિ સાથે સફળ જોડાણ એ એવી રૂપરેખા છે જે તમે હજી સમજતા નથી, અને ઓપરેટર નીતિ કડક કરે ત્યારે તે નિષ્ફળ જશે.