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-ს ველი არსებობს; ის არ არემონტებს დაკარგულ ნდობის საყრდენს. იგივე ეხება ნებისმიერი სერვერის სერტიფიკატის მიღებას იმიტომ, რომ კავშირი მის გარეშეც მუშაობს.
შემდეგ შეამოწმეთ სწორ ადგილას: დააიმპორტეთ მასალა, დაუკავშირდით ერთხელ და კავშირის დეტალებში დაადასტურეთ, რომ კარიბჭის იდენტობა მოსალოდნელია და პროფილი თქვენ მიერ განზრახულ მეთოდს აცხადებს. არასწორი მეთოდით წარმატებული კავშირი ისეთი კონფიგურაციაა, რომელსაც ჯერ არ იცნობთ, და ის ვარდება, როცა ოპერატორი პოლიტიკას გაამკაცრებს.