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 ಕ್ಷೇತ್ರ ಯಾವ ಪರಿಶೀಲನೆಗಾಗಿ ಇದೆಯೋ ಅದನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ; ಕಾಣೆಯಾದ ನಂಬಿಕೆಯ ಆಧಾರವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಸಂಪರ್ಕ ಅದಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಯಾವುದೇ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ ಸ್ವೀಕರಿಸುವುದಕ್ಕೂ ಅದೇ ಅನ್ವಯ.
ನಂತರ ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ: ಸಾಮಗ್ರಿ ಆಮದು ಮಾಡಿ, ಒಮ್ಮೆ ಸಂಪರ್ಕಿಸಿ, ಮತ್ತು ಸಂಪರ್ಕ ವಿವರಗಳಲ್ಲಿ ಗೇಟ್‌ವೇ ಗುರುತು ನೀವು ನಿರೀಕ್ಷಿಸಿದ್ದೇ ಎಂದು ಹಾಗೂ ಪ್ರೊಫೈಲ್ ನೀವು ಉದ್ದೇಶಿಸಿದ ವಿಧಾನವನ್ನೇ ವರದಿ ಮಾಡುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ತಪ್ಪು ವಿಧಾನದೊಂದಿಗೆ ಯಶಸ್ವಿ ಸಂಪರ್ಕ ನೀವು ಇನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳದ ಸಂರಚನೆ, ಮತ್ತು ನಿರ್ವಾಹಕರು ನೀತಿ ಕಟ್ಟುನಿಟ್ಟು ಮಾಡಿದಾಗ ಅದು ವಿಫಲವಾಗುತ್ತದೆ.